[PATCH 1/8] PM: Add suspend block api.

[PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

Adds /sys/power/policy that selects the behaviour of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/opportunistic-suspend.txt |  129 +++++++++++
 include/linux/suspend.h                       |    1 +
 include/linux/suspend_blocker.h               |   74 +++++++
 kernel/power/Kconfig                          |   16 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/main.c                           |  128 +++++++++++-
 kernel/power/opportunistic_suspend.c          |  284 +++++++++++++++++++++++++
 kernel/power/power.h                          |    9 +
 kernel/power/suspend.c                        |    3 +-
 9 files changed, 637 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/power/opportunistic-suspend.txt
 create mode 100755 include/linux/suspend_blocker.h
 create mode 100644 kernel/power/opportunistic_suspend.c

diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
new file mode 100644
index 0000000..4bee7bc
--- /dev/null
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -0,0 +1,129 @@
+Opportunistic Suspend
+=====================
+
+Opportunistic suspend is a feature allowing the system to be suspended (ie. put
+into one of the available sleep states) automatically whenever it is regarded
+as idle.  The suspend blockers framework described below is used to determine
+when that happens.
+
+The /sys/power/policy sysfs attribute is used to switch the system between the
+opportunistic and "forced" suspend behavior, where in the latter case the
+system is only suspended if a specific value, corresponding to one of the
+available system sleep states, is written into /sys/power/state.  However, in
+the former, opportunistic, case the system is put into the sleep state
+corresponding to the value written to /sys/power/state whenever there are no
+active suspend blockers. The default policy is "forced". Also, suspend blockers
+do not affect sleep states entered from idle.
+
+When the policy is "opportunisic", there is a special value, "on", that can be
+written to /sys/power/state. This will block the automatic sleep request, as if
+a suspend blocker was used by a device driver. This way the opportunistic
+suspend may be blocked by user space whithout switching back to the "forced"
+mode.
+
+A suspend blocker is an object used to inform the PM subsystem when the system
+can or cannot be suspended in the "opportunistic" mode (the "forced" mode
+ignores suspend blockers).  To use it, a device driver creates a struct
+suspend_blocker that must be initialized with suspend_blocker_init(). Before
+freeing the suspend_blocker structure or its name, suspend_blocker_unregister()
+must be called on it.
+
+A suspend blocker is activated using suspend_block(), which prevents the PM
+subsystem from putting the system into the requested sleep state in the
+"opportunistic" mode until the suspend blocker is deactivated with
+suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
+the system will not suspend as long as at least one of them is active.
+
+If opportunistic suspend is already in progress when suspend_block() is called,
+it will abort the suspend, unless suspend_ops->enter has already been
+executed. If suspend is aborted this way, the system is usually not fully
+operational at that point. The suspend callbacks of some drivers may still be
+running and it usually takes time to restore the system to the fully operational
+state.
+
+Here's an example showing how a cell phone or other embedded system can handle
+keystrokes (or other input events) in the presence of suspend blockers. 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 calls suspend_block on the
+  keypad-scan suspend_blocker 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 calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should be ignored, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.
+
+If the key that was pressed instead should preform a simple action (for example,
+adjusting the volume), this action can be performed right before calling
+suspend_unblock on the process_input_events suspend_blocker. However, if the key
+triggers a longer-running action, that action needs its own suspend_blocker and
+suspend_block must be called on that suspend blocker before calling
+suspend_unblock on the process_input_events suspend_blocker.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block API by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init(). For instance:
+
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, name);
+}
+
+If the suspend_blocker variable is allocated statically,
+DEFINE_SUSPEND_BLOCKER() should be used to initialize it, for example:
+
+static DEFINE_SUSPEND_BLOCKER(blocker, name);
+
+and suspend_blocker_register(&blocker) has to be called to make the suspend
+blocker usable.
+
+Before freeing the memory in which a suspend_blocker variable is located,
+suspend_blocker_unregister() must be called, for instance:
+
+uninit() {
+	suspend_blocker_unregister(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block():
+
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock():
+
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block() when the suspend blocker is active or suspend_unblock()
+when it is not active has no effect (i.e., these functions don't nest). This
+allows drivers to update their state and call suspend suspend_block() or
+suspend_unblock() based on the result. For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..07023d3 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -6,6 +6,7 @@
 #include <linux/init.h>
 #include <linux/pm.h>
 #include <linux/mm.h>
+#include <linux/suspend_blocker.h>
 #include <asm/errno.h>
 
 #if defined(CONFIG_PM_SLEEP) && defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE)
diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
new file mode 100755
index 0000000..8788302
--- /dev/null
+++ b/include/linux/suspend_blocker.h
@@ -0,0 +1,74 @@
+/* include/linux/suspend_blocker.h
+ *
+ * Copyright (C) 2007-2010 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_SUSPEND_BLOCKER_H
+#define _LINUX_SUSPEND_BLOCKER_H
+
+#include <linux/list.h>
+
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @link: List entry for active or inactive list.
+ * @flags: Tracks initialized and active state.
+ * @name: Suspend blocker name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * opportunistic suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
+ */
+struct suspend_blocker {
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct list_head link;
+	int flags;
+	const char *name;
+#endif
+};
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+#define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
+	{ .name = #blocker_name, }
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker = __SUSPEND_BLOCKER_INITIALIZER(name)
+
+extern void suspend_blocker_register(struct suspend_blocker *blocker);
+extern void suspend_blocker_init(struct suspend_blocker *blocker,
+				 const char *name);
+extern void suspend_blocker_unregister(struct suspend_blocker *blocker);
+extern void suspend_block(struct suspend_blocker *blocker);
+extern void suspend_unblock(struct suspend_blocker *blocker);
+extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
+extern bool suspend_is_blocked(void);
+
+#else
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker
+
+static inline void suspend_blocker_register(struct suspend_blocker *bl) {}
+static inline void suspend_blocker_init(struct suspend_blocker *bl,
+					const char *n) {}
+static inline void suspend_blocker_unregister(struct suspend_blocker *bl) {}
+static inline void suspend_block(struct suspend_blocker *bl) {}
+static inline void suspend_unblock(struct suspend_blocker *bl) {}
+static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
+{
+	return false;
+}
+static inline bool suspend_is_blocked(void) { return false; }
+#endif
+
+#endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5c36ea9..6d11a45 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -130,6 +130,22 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config OPPORTUNISTIC_SUSPEND
+	bool "Opportunistic suspend"
+	depends on SUSPEND
+	select RTC_LIB
+	default n
+	---help---
+	  Opportunistic sleep support.  Allows the system to be put into a sleep
+	  state opportunistically, if it doesn't do any useful work at the
+	  moment. The PM subsystem is switched into this mode of operation by
+	  writing "opportunistic" into /sys/power/policy, while writing
+	  "forced" to this file turns the opportunistic suspend feature off.
+	  In the "opportunistic" mode suspend blockers are used to determine
+	  when to suspend the system and the value written to /sys/power/state
+	  determines the sleep state the system will be put into when there are
+	  no active suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4319181..95d8e6d 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
+obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/main.c b/kernel/power/main.c
index b58800b..afbb4dd 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -20,6 +20,58 @@ DEFINE_MUTEX(pm_mutex);
 unsigned int pm_flags;
 EXPORT_SYMBOL(pm_flags);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+struct pm_policy {
+	const char *name;
+	bool (*valid_state)(suspend_state_t state);
+	int (*set_state)(suspend_state_t state);
+};
+
+static struct pm_policy policies[] = {
+	{
+		.name		= "forced",
+		.valid_state	= valid_state,
+		.set_state	= enter_state,
+	},
+	{
+		.name		= "opportunistic",
+		.valid_state	= opportunistic_suspend_valid_state,
+		.set_state	= opportunistic_suspend_state,
+	},
+};
+
+static int policy;
+
+static inline bool hibernation_supported(void)
+{
+	return !strncmp(policies[policy].name, "forced", 6);
+}
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && policies[policy].valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return policies[policy].set_state(state_idx);
+}
+
+#else
+
+static inline bool hibernation_supported(void) { return true; }
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return enter_state(state_idx);
+}
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_SLEEP
 
 /* Routines for PM-transition notifications */
@@ -146,6 +198,12 @@ struct kobject *power_kobj;
  *
  *	store() accepts one of those strings, translates it into the 
  *	proper enumerated value, and initiates a suspend transition.
+ *
+ *	If policy is set to opportunistic, store() does not block until the
+ *	system resumes, and it will try to re-enter the state until another
+ *	state is requested. Suspend blockers are respected and the requested
+ *	state will only be entered when no suspend blockers are active.
+ *	Write "on" to disable.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
@@ -155,12 +213,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 
 	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
+		if (pm_state_valid(i))
 			s += sprintf(s,"%s ", pm_states[i]);
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (hibernation_supported())
+		s += sprintf(s, "%s\n", "disk");
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
@@ -173,7 +232,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_ON;
 	const char * const *s;
 #endif
 	char *p;
@@ -185,8 +244,9 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 	/* First, check if we are requested to hibernate */
 	if (len == 4 && !strncmp(buf, "disk", len)) {
-		error = hibernate();
-  goto Exit;
+		if (hibernation_supported())
+			error = hibernate();
+		goto Exit;
 	}
 
 #ifdef CONFIG_SUSPEND
@@ -195,7 +255,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
-		error = enter_state(state);
+		error = pm_enter_state(state);
 #endif
 
  Exit:
@@ -204,6 +264,56 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/**
+ *	policy - set policy for state
+ */
+static ssize_t policy_show(struct kobject *kobj,
+			   struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		if (i == policy)
+			s += sprintf(s, "[%s] ", policies[i].name);
+		else
+			s += sprintf(s, "%s ", policies[i].name);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t policy_store(struct kobject *kobj,
+			    struct kobj_attribute *attr,
+			    const char *buf, size_t n)
+{
+	const char *s;
+	char *p;
+	int len;
+	int i;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		s = policies[i].name;
+		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
+			mutex_lock(&pm_mutex);
+			policies[policy].set_state(PM_SUSPEND_ON);
+			policy = i;
+			mutex_unlock(&pm_mutex);
+			return n;
+		}
+	}
+	return -EINVAL;
+}
+
+power_attr(policy);
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -236,6 +346,9 @@ static struct attribute * g[] = {
 #endif
 #ifdef CONFIG_PM_SLEEP
 	&pm_async_attr.attr,
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	&policy_attr.attr,
+#endif
 #ifdef CONFIG_PM_DEBUG
 	&pm_test_attr.attr,
 #endif
@@ -247,7 +360,7 @@ static struct attribute_group attr_group = {
 	.attrs = g,
 };
 
-#ifdef CONFIG_PM_RUNTIME
+#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
 struct workqueue_struct *pm_wq;
 EXPORT_SYMBOL_GPL(pm_wq);
 
@@ -266,6 +379,7 @@ static int __init pm_init(void)
 	int error = pm_start_workqueue();
 	if (error)
 		return error;
+	opportunistic_suspend_init();
 	power_kobj = kobject_create_and_add("power", NULL);
 	if (!power_kobj)
 		return -ENOMEM;
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
new file mode 100644
index 0000000..acc1651
--- /dev/null
+++ b/kernel/power/opportunistic_suspend.c
@@ -0,0 +1,284 @@
+/*
+ * kernel/power/opportunistic_suspend.c
+ *
+ * Copyright (C) 2005-2010 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/rtc.h>
+#include <linux/suspend.h>
+
+#include "power.h"
+
+extern struct workqueue_struct *pm_wq;
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
+
+static DEFINE_SPINLOCK(list_lock);
+static DEFINE_SPINLOCK(state_lock);
+static LIST_HEAD(inactive_blockers);
+static LIST_HEAD(active_blockers);
+static int current_event_num;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+
+#define pr_info_time(fmt, args...) \
+	do { \
+		struct timespec ts; \
+		struct rtc_time tm; \
+		getnstimeofday(&ts); \
+		rtc_time_to_tm(ts.tv_sec, &tm); \
+		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+			args, \
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+	} while (0);
+
+static void print_active_suspend_blockers(void)
+{
+	struct suspend_blocker *blocker;
+
+	list_for_each_entry(blocker, &active_blockers, link)
+		pr_info("PM: Active suspend blocker %s\n", blocker->name);
+}
+
+/**
+ * suspend_is_blocked - Check if there are active suspend blockers.
+ *
+ * Return true if suspend blockers are enabled and there are active suspend
+ * blockers, in which case the system cannot be put to sleep opportunistically.
+ */
+bool suspend_is_blocked(void)
+{
+	return enable_suspend_blockers && !list_empty(&active_blockers);
+}
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = true;
+
+	if (suspend_is_blocked()) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: Automatic suspend aborted\n");
+		goto abort;
+	}
+
+	entry_event_num = current_event_num;
+
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("PM: Automatic suspend\n");
+
+	ret = pm_suspend(requested_suspend_state);
+
+	if (debug_mask & DEBUG_EXIT_SUSPEND)
+		pr_info_time("PM: Automatic suspend exit, ret = %d ", ret);
+
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: pm_suspend() returned with no event\n");
+		queue_work(pm_wq, work);
+	}
+
+abort:
+	enable_suspend_blockers = false;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+/**
+ * suspend_blocker_register - Prepare a suspend blocker for being used.
+ * @blocker: Suspend blocker to handle.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_register(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags = 0;
+
+	WARN_ON(!blocker->name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Registering %s\n", __func__, blocker->name);
+
+	blocker->flags = SB_INITIALIZED;
+	INIT_LIST_HEAD(&blocker->link);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&blocker->link, &inactive_blockers);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_register);
+
+/**
+ * suspend_blocker_init - Initialize a suspend blocker's name and register it.
+ * @blocker: Suspend blocker to initialize.
+ * @name:    The name of the suspend blocker to show in debug messages.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	blocker->name = name;
+	suspend_blocker_register(blocker);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_unregister - Unregister a suspend blocker.
+ * @blocker: Suspend blocker to handle.
+ */
+void suspend_blocker_unregister(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags &= ~SB_INITIALIZED;
+	list_del(&blocker->link);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Unregistered %s\n", __func__, blocker->name);
+}
+EXPORT_SYMBOL(suspend_blocker_unregister);
+
+/**
+ * suspend_block - Block system suspend.
+ * @blocker: Suspend blocker to use.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	blocker->flags |= SB_ACTIVE;
+	list_move(&blocker->link, &active_blockers);
+
+	current_event_num++;
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock - Allow system suspend to happen.
+ * @blocker: Suspend blocker to unblock.
+ *
+ * If no other suspend blockers are active, schedule suspend of the system.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	list_move(&blocker->link, &inactive_blockers);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	blocker->flags &= ~(SB_ACTIVE);
+
+	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
+		print_active_suspend_blockers();
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * suspend_blocker_is_active - Test if a suspend blocker is blocking suspend
+ * @blocker: Suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
+ */
+bool suspend_blocker_is_active(struct suspend_blocker *blocker)
+{
+	WARN_ON(!(blocker->flags & SB_INITIALIZED));
+
+	return !!(blocker->flags & SB_ACTIVE);
+}
+EXPORT_SYMBOL(suspend_blocker_is_active);
+
+bool opportunistic_suspend_valid_state(suspend_state_t state)
+{
+	return (state == PM_SUSPEND_ON) || valid_state(state);
+}
+
+int opportunistic_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+
+	if (!opportunistic_suspend_valid_state(state))
+		return -ENODEV;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+
+	if (debug_mask & DEBUG_USER_STATE)
+		pr_info_time("%s: %s (%d->%d) at %lld ", __func__,
+			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			     requested_suspend_state, state,
+			     ktime_to_ns(ktime_get()));
+
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+
+	spin_unlock_irqrestore(&state_lock, irqflags);
+
+	return 0;
+}
+
+void __init opportunistic_suspend_init(void)
+{
+	suspend_blocker_register(&main_suspend_blocker);
+	suspend_block(&main_suspend_blocker);
+}
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46c5a26..2e9cfd5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/* kernel/power/opportunistic_suspend.c */
+extern int opportunistic_suspend_state(suspend_state_t state);
+extern bool opportunistic_suspend_valid_state(suspend_state_t state);
+extern void __init opportunistic_suspend_init(void);
+#else
+static inline void opportunistic_suspend_init(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..9eb3876 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -20,6 +20,7 @@
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_ON]		= "on",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -157,7 +158,7 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
 			error = suspend_ops->enter(state);
 		sysdev_resume();
 	}
-- 
1.6.5.1

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

[PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

Add a misc device, "suspend_blocker", that allows user-space processes
to block auto suspend. The device has ioctls to create a suspend_blocker,
and to block and unblock suspend. To delete the suspend_blocker, close
the device.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/ioctl/ioctl-number.txt          |    3 +-
 Documentation/power/opportunistic-suspend.txt |   27 +++++
 include/linux/suspend_ioctls.h                |    4 +
 kernel/power/Kconfig                          |    7 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/user_suspend_blocker.c           |  143 +++++++++++++++++++++++++
 6 files changed, 184 insertions(+), 1 deletions(-)
 create mode 100644 kernel/power/user_suspend_blocker.c

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index dd5806f..e2458f7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -254,7 +254,8 @@ Code  Seq#(hex)	Include File		Comments
 'q'	80-FF	linux/telephony.h	Internet PhoneJACK, Internet LineJACK
 		linux/ixjuser.h		<http://www.quicknet.net>
 'r'	00-1F	linux/msdos_fs.h and fs/fat/dir.c
-'s'	all	linux/cdk.h
+'s'	all	linux/cdk.h	conflict!
+'s'	all	linux/suspend_block_dev.h	conflict!
 't'	00-7F	linux/if_ppp.h
 't'	80-8F	linux/isdn_ppp.h
 't'	90	linux/toshiba.h
diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
index 4bee7bc..93f4c24 100644
--- a/Documentation/power/opportunistic-suspend.txt
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -127,3 +127,30 @@ if (list_empty(&state->pending_work))
 	suspend_unblock(&state->suspend_blocker);
 else
 	suspend_block(&state->suspend_blocker);
+
+User space API
+==============
+
+To create a suspend blocker from user space, open the suspend_blocker special
+device file:
+
+    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
+
+then optionally call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
+
+To activate the suspend blocker call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
+
+To deactivate it call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
+
+To destroy the suspend blocker, close the device:
+
+    close(fd);
+
+If the first ioctl called is not SUSPEND_BLOCKER_IOCTL_SET_NAME the suspend
+blocker will get the default name "(userspace)".
diff --git a/include/linux/suspend_ioctls.h b/include/linux/suspend_ioctls.h
index 0b30382..b95a6b2 100644
--- a/include/linux/suspend_ioctls.h
+++ b/include/linux/suspend_ioctls.h
@@ -30,4 +30,8 @@ struct resume_swap_area {
 #define SNAPSHOT_ALLOC_SWAP_PAGE	_IOR(SNAPSHOT_IOC_MAGIC, 20, __kernel_loff_t)
 #define SNAPSHOT_IOC_MAXNR	20
 
+#define SUSPEND_BLOCKER_IOCTL_SET_NAME(len)	_IOC(_IOC_WRITE, 's', 0, len)
+#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
+#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
+
 #endif /* _LINUX_SUSPEND_IOCTLS_H */
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 6d11a45..2e665cd 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,13 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config USER_SUSPEND_BLOCKERS
+	bool "User space suspend blockers"
+	depends on OPPORTUNISTIC_SUSPEND
+	---help---
+	  User space suspend blockers API.  Creates a misc device allowing user
+	  space to create, use and destroy suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 95d8e6d..2015594 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
+obj-$(CONFIG_USER_SUSPEND_BLOCKERS)	+= user_suspend_blocker.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/user_suspend_blocker.c b/kernel/power/user_suspend_blocker.c
new file mode 100644
index 0000000..d53f939
--- /dev/null
+++ b/kernel/power/user_suspend_blocker.c
@@ -0,0 +1,143 @@
+/*
+ * kernel/power/user_suspend_blocker.c
+ *
+ * Copyright (C) 2009-2010 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/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/slab.h>
+#include <linux/suspend.h>
+#include <linux/suspend_ioctls.h>
+
+enum {
+	DEBUG_FAILURE	= BIT(0),
+};
+static int debug_mask = DEBUG_FAILURE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static DEFINE_MUTEX(ioctl_lock);
+
+#define USER_SUSPEND_BLOCKER_NAME_LEN 31
+
+struct user_suspend_blocker {
+	struct suspend_blocker	blocker;
+	char			name[USER_SUSPEND_BLOCKER_NAME_LEN + 1];
+	bool			registered;
+};
+
+static int user_suspend_blocker_open(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker;
+
+	blocker = kzalloc(sizeof(*blocker), GFP_KERNEL);
+	if (!blocker)
+		return -ENOMEM;
+
+	nonseekable_open(inode, filp);
+	strcpy(blocker->name, "(userspace)");
+	blocker->blocker.name = blocker->name;
+	filp->private_data = blocker;
+
+	return 0;
+}
+
+static int suspend_blocker_set_name(struct user_suspend_blocker *blocker,
+				    void __user *name, size_t name_len)
+{
+	if (blocker->registered)
+		return -EBUSY;
+
+	if (name_len > USER_SUSPEND_BLOCKER_NAME_LEN)
+		name_len = USER_SUSPEND_BLOCKER_NAME_LEN;
+
+	if (copy_from_user(blocker->name, name, name_len))
+		return -EFAULT;
+	blocker->name[name_len] = '\0';
+
+	return 0;
+}
+
+static long user_suspend_blocker_ioctl(struct file *filp, unsigned int cmd,
+					unsigned long _arg)
+{
+	void __user *arg = (void __user *)_arg;
+	struct user_suspend_blocker *blocker = filp->private_data;
+	long ret = 0;
+
+	mutex_lock(&ioctl_lock);
+	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_SET_NAME(0)) {
+		ret = suspend_blocker_set_name(blocker, arg, _IOC_SIZE(cmd));
+		goto done;
+	}
+	if (!blocker->registered) {
+		suspend_blocker_register(&blocker->blocker);
+		blocker->registered = true;
+	}
+	switch (cmd) {
+	case SUSPEND_BLOCKER_IOCTL_BLOCK:
+		suspend_block(&blocker->blocker);
+		break;
+
+	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
+		suspend_unblock(&blocker->blocker);
+		break;
+
+	default:
+		ret = -ENOTTY;
+	}
+done:
+	if (ret && (debug_mask & DEBUG_FAILURE))
+		pr_err("user_suspend_blocker_ioctl: cmd %x failed, %ld\n",
+			cmd, ret);
+	mutex_unlock(&ioctl_lock);
+	return ret;
+}
+
+static int user_suspend_blocker_release(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker = filp->private_data;
+
+	if (blocker->registered)
+		suspend_blocker_unregister(&blocker->blocker);
+	kfree(blocker);
+
+	return 0;
+}
+
+const struct file_operations user_suspend_blocker_fops = {
+	.open = user_suspend_blocker_open,
+	.release = user_suspend_blocker_release,
+	.unlocked_ioctl = user_suspend_blocker_ioctl,
+};
+
+struct miscdevice user_suspend_blocker_device = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "suspend_blocker",
+	.fops = &user_suspend_blocker_fops,
+};
+
+static int __init user_suspend_blocker_init(void)
+{
+	return misc_register(&user_suspend_blocker_device);
+}
+
+static void __exit user_suspend_blocker_exit(void)
+{
+	misc_deregister(&user_suspend_blocker_device);
+}
+
+module_init(user_suspend_blocker_init);
+module_exit(user_suspend_blocker_exit);
-- 
1.6.5.1

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

[PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.

[Arve Hjønnevåg]

If a suspend_blocker is active, suspend will fail anyway. Since
try_to_freeze_tasks can take up to 20 seconds to complete or fail, aborting
as soon as someone blocks suspend (e.g. from an interrupt handler) improves
the worst case wakeup latency.

On an older kernel where task freezing could fail for processes attached
to a debugger, this fixed a problem where the device sometimes hung for
20 seconds before the screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 kernel/power/process.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index 71ae290..27d26d3 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -38,6 +38,7 @@ static int try_to_freeze_tasks(bool sig_only)
 	struct timeval start, end;
 	u64 elapsed_csecs64;
 	unsigned int elapsed_csecs;
+	bool wakeup = false;
 
 	do_gettimeofday(&start);
 
@@ -63,6 +64,10 @@ static int try_to_freeze_tasks(bool sig_only)
 				todo++;
 		} while_each_thread(g, p);
 		read_unlock(&tasklist_lock);
+		if (todo && suspend_is_blocked()) {
+			wakeup = true;
+			break;
+		}
 		if (!todo || time_after(jiffies, end_time))
 			break;
 
@@ -85,13 +90,15 @@ static int try_to_freeze_tasks(bool sig_only)
 		 * but it cleans up leftover PF_FREEZE requests.
 		 */
 		printk("\n");
-		printk(KERN_ERR "Freezing of tasks failed after %d.%02d seconds "
+		printk(KERN_ERR "Freezing of tasks %s after %d.%02d seconds "
 				"(%d tasks refusing to freeze):\n",
+				wakeup ? "aborted" : "failed",
 				elapsed_csecs / 100, elapsed_csecs % 100, todo);
 		read_lock(&tasklist_lock);
 		do_each_thread(g, p) {
 			task_lock(p);
-			if (freezing(p) && !freezer_should_skip(p))
+			if (freezing(p) && !freezer_should_skip(p)
+					&& elapsed_csecs > 100)
 				sched_show_task(p);
 			cancel_freezing(p);
 			task_unlock(p);
-- 
1.6.5.1

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

[PATCH 4/8] PM: suspend_block: Add debugfs file

[Arve Hjønnevåg]

Report active and inactive suspend blockers in
/sys/kernel/debug/suspend_blockers.

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

diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index acc1651..c2dad76 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/rtc.h>
 #include <linux/suspend.h>
+#include <linux/debugfs.h>
 
 #include "power.h"
 
@@ -138,7 +139,8 @@ EXPORT_SYMBOL(suspend_blocker_register);
 /**
  * suspend_blocker_init - Initialize a suspend blocker's name and register it.
  * @blocker: Suspend blocker to initialize.
- * @name:    The name of the suspend blocker to show in debug messages.
+ * @name:    The name of the suspend blocker to show in debug messages and
+ *	     /sys/kernel/debug/suspend_blockers.
  *
  * The suspend blocker struct and name must not be freed before calling
  * suspend_blocker_unregister().
@@ -282,3 +284,42 @@ void __init opportunistic_suspend_init(void)
 	suspend_blocker_register(&main_suspend_blocker);
 	suspend_block(&main_suspend_blocker);
 }
+
+static struct dentry *suspend_blocker_stats_dentry;
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tactive\n");
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		seq_printf(m, "\"%s\"\t0\n", blocker->name);
+	list_for_each_entry(blocker, &active_blockers, link)
+		seq_printf(m, "\"%s\"\t1\n", blocker->name);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, suspend_blocker_stats_show, NULL);
+}
+
+static const struct file_operations suspend_blocker_stats_fops = {
+	.owner = THIS_MODULE,
+	.open = suspend_blocker_stats_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+static int __init suspend_blocker_debugfs_init(void)
+{
+	suspend_blocker_stats_dentry = debugfs_create_file("suspend_blockers",
+			S_IRUGO, NULL, NULL, &suspend_blocker_stats_fops);
+	return 0;
+}
+
+postcore_initcall(suspend_blocker_debugfs_init);
-- 
1.6.5.1

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

[PATCH 5/8] PM: suspend_block: Add suspend_blocker stats

[Arve Hjønnevåg]

Report suspend block stats in /sys/kernel/debug/suspend_blockers.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 include/linux/suspend_blocker.h      |   27 +++++-
 kernel/power/Kconfig                 |    8 ++
 kernel/power/opportunistic_suspend.c |  200 +++++++++++++++++++++++++++++++++-
 kernel/power/power.h                 |    5 +
 kernel/power/suspend.c               |    4 +-
 5 files changed, 239 insertions(+), 5 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 8788302..256af15 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -17,11 +17,35 @@
 #define _LINUX_SUSPEND_BLOCKER_H
 
 #include <linux/list.h>
+#include <linux/ktime.h>
+
+/**
+ * struct suspend_blocker_stats - statistics for a suspend blocker
+ *
+ * @count: Number of times this blocker has been deacivated.
+ * @wakeup_count: Number of times this blocker was the first to block suspend
+ *	after resume.
+ * @total_time: Total time this suspend blocker has prevented suspend.
+ * @prevent_suspend_time: Time this suspend blocker has prevented suspend while
+ *	user-space requested suspend.
+ * @max_time: Max time this suspend blocker has been continuously active.
+ * @last_time: Monotonic clock when the active state last changed.
+ */
+struct suspend_blocker_stats {
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	unsigned int count;
+	unsigned int wakeup_count;
+	ktime_t total_time;
+	ktime_t prevent_suspend_time;
+	ktime_t max_time;
+	ktime_t last_time;
+#endif
+};
 
 /**
  * struct suspend_blocker - the basic suspend_blocker structure
  * @link: List entry for active or inactive list.
- * @flags: Tracks initialized and active state.
+ * @flags: Tracks initialized and active state and statistics.
  * @name: Suspend blocker name used for debugging.
  *
  * When a suspend_blocker is active it prevents the system from entering
@@ -34,6 +58,7 @@ struct suspend_blocker {
 	struct list_head link;
 	int flags;
 	const char *name;
+	struct suspend_blocker_stats stat;
 #endif
 };
 
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2e665cd..16a2570 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,14 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config SUSPEND_BLOCKER_STATS
+	bool "Suspend blockers statistics"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  Use /sys/kernel/debug/suspend_blockers to report suspend blockers
+	  statistics.
+
 config USER_SUSPEND_BLOCKERS
 	bool "User space suspend blockers"
 	depends on OPPORTUNISTIC_SUSPEND
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index c2dad76..3f0153d 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -35,6 +35,7 @@ module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
 
 #define SB_INITIALIZED            (1U << 8)
 #define SB_ACTIVE                 (1U << 9)
+#define SB_PREVENTING_SUSPEND     (1U << 10)
 
 DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
 
@@ -45,6 +46,118 @@ static LIST_HEAD(active_blockers);
 static int current_event_num;
 static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
 static bool enable_suspend_blockers;
+static DEFINE_SUSPEND_BLOCKER(unknown_wakeup, unknown_wakeups);
+
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static struct suspend_blocker_stats dropped_suspend_blockers;
+static ktime_t last_sleep_time_update;
+static bool wait_for_wakeup;
+
+static void suspend_blocker_stat_init(struct suspend_blocker_stats *stat)
+{
+	stat->count = 0;
+	stat->wakeup_count = 0;
+	stat->total_time = ktime_set(0, 0);
+	stat->prevent_suspend_time = ktime_set(0, 0);
+	stat->max_time = ktime_set(0, 0);
+	stat->last_time = ktime_set(0, 0);
+}
+
+static void init_dropped_suspend_blockers(void)
+{
+	suspend_blocker_stat_init(&dropped_suspend_blockers);
+}
+
+static void suspend_blocker_stat_drop(struct suspend_blocker_stats *stat)
+{
+	if (!stat->count)
+		return;
+
+	dropped_suspend_blockers.count += stat->count;
+	dropped_suspend_blockers.total_time = ktime_add(
+		dropped_suspend_blockers.total_time, stat->total_time);
+	dropped_suspend_blockers.prevent_suspend_time = ktime_add(
+		dropped_suspend_blockers.prevent_suspend_time,
+		stat->prevent_suspend_time);
+	dropped_suspend_blockers.max_time = ktime_add(
+		dropped_suspend_blockers.max_time, stat->max_time);
+}
+
+static void suspend_unblock_stat(struct suspend_blocker *blocker)
+{
+	struct suspend_blocker_stats *stat = &blocker->stat;
+	ktime_t duration;
+	ktime_t now;
+
+	if (!(blocker->flags & SB_ACTIVE))
+		return;
+
+	now = ktime_get();
+	stat->count++;
+	duration = ktime_sub(now, stat->last_time);
+	stat->total_time = ktime_add(stat->total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(stat->max_time))
+		stat->max_time = duration;
+
+	stat->last_time = ktime_get();
+	if (blocker->flags & SB_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		stat->prevent_suspend_time = ktime_add(
+			stat->prevent_suspend_time, duration);
+		blocker->flags &= ~SB_PREVENTING_SUSPEND;
+	}
+}
+
+static void suspend_block_stat(struct suspend_blocker *blocker)
+{
+	if (wait_for_wakeup) {
+		if (debug_mask & DEBUG_WAKEUP)
+			pr_info("wakeup suspend blocker: %s\n", blocker->name);
+
+		wait_for_wakeup = false;
+		blocker->stat.wakeup_count++;
+	}
+	if (!(blocker->flags & SB_ACTIVE))
+		blocker->stat.last_time = ktime_get();
+}
+
+static void update_sleep_wait_stats(bool done)
+{
+	struct suspend_blocker *blocker;
+	ktime_t now, elapsed, add;
+
+	now = ktime_get();
+	elapsed = ktime_sub(now, last_sleep_time_update);
+	list_for_each_entry(blocker, &active_blockers, link) {
+		struct suspend_blocker_stats *stat = &blocker->stat;
+
+		if (blocker->flags & SB_PREVENTING_SUSPEND) {
+			add = elapsed;
+			stat->prevent_suspend_time = ktime_add(
+				stat->prevent_suspend_time, add);
+		}
+		if (done)
+			blocker->flags &= ~SB_PREVENTING_SUSPEND;
+		else
+			blocker->flags |= SB_PREVENTING_SUSPEND;
+	}
+	last_sleep_time_update = now;
+}
+
+void about_to_enter_suspend(void)
+{
+	wait_for_wakeup = true;
+}
+
+#else /* !CONFIG_SUSPEND_BLOCKER_STATS */
+
+static inline void init_dropped_suspend_blockers(void) {}
+static inline void suspend_blocker_stat_init(struct suspend_blocker_stats *s) {}
+static inline void suspend_blocker_stat_drop(struct suspend_blocker_stats *s) {}
+static inline void suspend_unblock_stat(struct suspend_blocker *blocker) {}
+static inline void suspend_block_stat(struct suspend_blocker *blocker) {}
+static inline void update_sleep_wait_stats(bool done) {}
+#endif /* !CONFIG_SUSPEND_BLOCKER_STATS */
 
 #define pr_info_time(fmt, args...) \
 	do { \
@@ -103,7 +216,8 @@ static void suspend_worker(struct work_struct *work)
 	if (current_event_num == entry_event_num) {
 		if (debug_mask & DEBUG_SUSPEND)
 			pr_info("PM: pm_suspend() returned with no event\n");
-		queue_work(pm_wq, work);
+		suspend_block(&unknown_wakeup);
+		suspend_unblock(&unknown_wakeup);
 	}
 
 abort:
@@ -127,6 +241,8 @@ void suspend_blocker_register(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: Registering %s\n", __func__, blocker->name);
 
+	suspend_blocker_stat_init(&blocker->stat);
+
 	blocker->flags = SB_INITIALIZED;
 	INIT_LIST_HEAD(&blocker->link);
 
@@ -164,6 +280,10 @@ void suspend_blocker_unregister(struct suspend_blocker *blocker)
 		return;
 
 	spin_lock_irqsave(&list_lock, irqflags);
+
+	suspend_unblock_stat(blocker);
+	suspend_blocker_stat_drop(&blocker->stat);
+
 	blocker->flags &= ~SB_INITIALIZED;
 	list_del(&blocker->link);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -193,11 +313,18 @@ void suspend_block(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_block_stat(blocker);
+
 	blocker->flags |= SB_ACTIVE;
 	list_move(&blocker->link, &active_blockers);
 
 	current_event_num++;
 
+	if (blocker == &main_suspend_blocker)
+		update_sleep_wait_stats(true);
+	else if (!suspend_blocker_is_active(&main_suspend_blocker))
+		update_sleep_wait_stats(false);
+
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
 EXPORT_SYMBOL(suspend_block);
@@ -222,13 +349,19 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_unblock_stat(blocker);
+
 	list_move(&blocker->link, &inactive_blockers);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
 		queue_work(pm_wq, &suspend_work);
 	blocker->flags &= ~(SB_ACTIVE);
 
-	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
-		print_active_suspend_blockers();
+	if (blocker == &main_suspend_blocker) {
+		if (debug_mask & DEBUG_SUSPEND)
+			print_active_suspend_blockers();
+
+		update_sleep_wait_stats(false);
+	}
 
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -283,10 +416,69 @@ void __init opportunistic_suspend_init(void)
 {
 	suspend_blocker_register(&main_suspend_blocker);
 	suspend_block(&main_suspend_blocker);
+	suspend_blocker_register(&unknown_wakeup);
+	init_dropped_suspend_blockers();
 }
 
 static struct dentry *suspend_blocker_stats_dentry;
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static int print_blocker_stats(struct seq_file *m, const char *name,
+				struct suspend_blocker_stats *stat, int flags)
+{
+	int lock_count = stat->count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = stat->total_time;
+	ktime_t max_time = stat->max_time;
+	ktime_t prevent_suspend_time = stat->prevent_suspend_time;
+
+	if (flags & SB_ACTIVE) {
+		ktime_t now, add_time;
+
+		now = ktime_get();
+		add_time = ktime_sub(now, stat->last_time);
+		lock_count++;
+		active_time = add_time;
+		total_time = ktime_add(total_time, add_time);
+		if (flags & SB_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 seq_printf(m, "\"%s\"\t%d\t%d\t%lld\t%lld\t%lld\t%lld\t%lld\n",
+			name, lock_count, 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(stat->last_time));
+}
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tcount\twake_count\tactive_since"
+		 "\ttotal_time\tsleep_time\tmax_time\tlast_change\n");
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &active_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	print_blocker_stats(m, "deleted", &dropped_suspend_blockers, 0);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+#else
+
 static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 {
 	unsigned long irqflags;
@@ -302,6 +494,8 @@ static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 	return 0;
 }
 
+#endif
+
 static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
 {
 	return single_open(file, suspend_blocker_stats_show, NULL);
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 2e9cfd5..e13c975 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -245,3 +245,8 @@ extern void __init opportunistic_suspend_init(void);
 #else
 static inline void opportunistic_suspend_init(void) {}
 #endif
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+void about_to_enter_suspend(void);
+#else
+static inline void about_to_enter_suspend(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 9eb3876..df694e7 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -158,8 +158,10 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE)) {
+			about_to_enter_suspend();
 			error = suspend_ops->enter(state);
+		}
 		sysdev_resume();
 	}
 
-- 
1.6.5.1

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

[PATCH 6/8] PM: Add suspend blocking work.

[Arve Hjønnevåg]

Allow work to be queued that will block suspend while it is pending
or executing. To get the same functionality in the calling code often
requires a separate suspend_blocker for pending and executing work, or
additional state and locking. This implementation does add additional
state and locking, but this can be removed later if we add support for
suspend blocking work to the core workqueue code.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 include/linux/suspend_blocker.h      |   67 +++++++++++++++++++++
 kernel/power/opportunistic_suspend.c |  109 ++++++++++++++++++++++++++++++++++
 2 files changed, 176 insertions(+), 0 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 256af15..bb90b45 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -18,6 +18,7 @@
 
 #include <linux/list.h>
 #include <linux/ktime.h>
+#include <linux/workqueue.h>
 
 /**
  * struct suspend_blocker_stats - statistics for a suspend blocker
@@ -62,6 +63,38 @@ struct suspend_blocker {
 #endif
 };
 
+/**
+ * struct suspend_blocking_work - the basic suspend_blocking_work structure
+ * @work:		Standard work struct.
+ * @suspend_blocker:	Suspend blocker.
+ * @func:		Callback.
+ * @lock:		Spinlock protecting pending and running state.
+ * @active:		Number of cpu workqueues where work is pending or
+ *			callback is running.
+ *
+ * When suspend blocking work is pending or its callback is running it prevents
+ * the system from entering opportunistic suspend.
+ *
+ * The suspend_blocking_work structure must be initialized by
+ * suspend_blocking_work_init().
+ */
+
+struct suspend_blocking_work {
+	struct work_struct work;
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct suspend_blocker suspend_blocker;
+	work_func_t func;
+	spinlock_t lock;
+	int active;
+#endif
+};
+
+static inline struct suspend_blocking_work *to_suspend_blocking_work(
+	struct work_struct *work)
+{
+	return container_of(work, struct suspend_blocking_work, work);
+}
+
 #ifdef CONFIG_OPPORTUNISTIC_SUSPEND
 #define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
 	{ .name = #blocker_name, }
@@ -78,6 +111,14 @@ extern void suspend_unblock(struct suspend_blocker *blocker);
 extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
 extern bool suspend_is_blocked(void);
 
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name);
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work);
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work);
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work);
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work);
+
 #else
 
 #define DEFINE_SUSPEND_BLOCKER(blocker, name) \
@@ -94,6 +135,32 @@ static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
 	return false;
 }
 static inline bool suspend_is_blocked(void) { return false; }
+
+static inline void suspend_blocking_work_init(
+	struct suspend_blocking_work *work, work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, func);
+}
+static inline void suspend_blocking_work_destroy(
+	struct suspend_blocking_work *work)
+{
+	cancel_work_sync(&work->work);
+}
+static inline int queue_suspend_blocking_work(
+	struct workqueue_struct *wq, struct suspend_blocking_work *work)
+{
+	return queue_work(wq, &work->work);
+}
+static inline int schedule_suspend_blocking_work(
+	struct suspend_blocking_work *work)
+{
+	return schedule_work(&work->work);
+}
+static inline int cancel_suspend_blocking_work_sync(
+	struct suspend_blocking_work *work)
+{
+	return cancel_work_sync(&work->work);
+}
 #endif
 
 #endif
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index 3f0153d..63be9ad 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -517,3 +517,112 @@ static int __init suspend_blocker_debugfs_init(void)
 }
 
 postcore_initcall(suspend_blocker_debugfs_init);
+
+static void suspend_blocking_work_complete(struct suspend_blocking_work *work)
+{
+	unsigned long flags;
+
+	WARN_ON(!work->active);
+	spin_lock_irqsave(&work->lock, flags);
+	if (!--work->active)
+		suspend_unblock(&work->suspend_blocker);
+	spin_unlock_irqrestore(&work->lock, flags);
+}
+
+static void suspend_blocking_work_func(struct work_struct *work)
+{
+	struct suspend_blocking_work *sbwork = to_suspend_blocking_work(work);
+
+	sbwork->func(work);
+	suspend_blocking_work_complete(sbwork);
+}
+
+/**
+ * suspend_blocking_work_init - Initialize a suspend-blocking work item.
+ * @work: Work item to initialize.
+ * @func: Callback.
+ * @name: Name for suspend blocker.
+ *
+ */
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, suspend_blocking_work_func);
+	suspend_blocker_init(&work->suspend_blocker, name);
+	work->func = func;
+	spin_lock_init(&work->lock);
+	work->active = 0;
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_init);
+
+/**
+ * cancel_suspend_blocking_work_sync - Cancel a suspend-blocking work item.
+ * @work: Work item to handle.
+ */
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work)
+{
+	int ret;
+
+	ret = cancel_work_sync(&work->work);
+	if (ret)
+		suspend_blocking_work_complete(work);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cancel_suspend_blocking_work_sync);
+
+/**
+ * suspend_blocking_work_destroy - Destroy a suspend-blocking work item.
+ * @work: The work item in question.
+ *
+ * If the work was ever queued on more then one workqueue all but the last
+ * workqueue must be flushed before calling suspend_blocking_work_destroy.
+ */
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work)
+{
+	cancel_suspend_blocking_work_sync(work);
+	WARN_ON(work->active);
+	suspend_blocker_unregister(&work->suspend_blocker);
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_destroy);
+
+/**
+ * queue_suspend_blocking_work - Queue a suspend-blocking work item.
+ * @wq: Workqueue to queue the work on.
+ * @work: Work item to queue.
+ */
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = queue_work(wq, &work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(queue_suspend_blocking_work);
+
+/**
+ * schedule_suspend_blocking_work - Schedule a suspend-blocking work item.
+ * @work: Work item to schedule.
+ */
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = schedule_work(&work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(schedule_suspend_blocking_work);
-- 
1.6.5.1

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

[PATCH 7/8] Input: Block suspend while event queue is not empty.

[Arve Hjønnevåg]

Add an ioctl, EVIOCSSUSPENDBLOCK, to enable a suspend_blocker that will block
suspend while the event queue is not empty. This 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 |   22 ++++++++++++++++++++++
 include/linux/input.h |    3 +++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2ee6c7a..bff2247 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -20,6 +20,7 @@
 #include <linux/input.h>
 #include <linux/major.h>
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include "input-compat.h"
 
 struct evdev {
@@ -43,6 +44,8 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	struct suspend_blocker suspend_blocker;
+	bool use_suspend_blocker;
 };
 
 static struct evdev *evdev_table[EVDEV_MINORS];
@@ -55,6 +58,8 @@ static void evdev_pass_event(struct evdev_client *client,
 	 * Interrupts are disabled, just acquire the lock
 	 */
 	spin_lock(&client->buffer_lock);
+	if (client->use_suspend_blocker)
+		suspend_block(&client->suspend_blocker);
 	client->buffer[client->head++] = *event;
 	client->head &= EVDEV_BUFFER_SIZE - 1;
 	spin_unlock(&client->buffer_lock);
@@ -234,6 +239,8 @@ static int evdev_release(struct inode *inode, struct file *file)
 	mutex_unlock(&evdev->mutex);
 
 	evdev_detach_client(evdev, client);
+	if (client->use_suspend_blocker)
+		suspend_blocker_unregister(&client->suspend_blocker);
 	kfree(client);
 
 	evdev_close_device(evdev);
@@ -335,6 +342,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->use_suspend_blocker && client->head == client->tail)
+			suspend_unblock(&client->suspend_blocker);
 	}
 
 	spin_unlock_irq(&client->buffer_lock);
@@ -585,6 +594,19 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		else
 			return evdev_ungrab(evdev, client);
 
+	case EVIOCGSUSPENDBLOCK:
+		return put_user(client->use_suspend_blocker, ip);
+
+	case EVIOCSSUSPENDBLOCK:
+		spin_lock_irq(&client->buffer_lock);
+		if (!client->use_suspend_blocker && p)
+			suspend_blocker_init(&client->suspend_blocker, "evdev");
+		else if (client->use_suspend_blocker && !p)
+			suspend_blocker_unregister(&client->suspend_blocker);
+		client->use_suspend_blocker = !!p;
+		spin_unlock_irq(&client->buffer_lock);
+		return 0;
+
 	default:
 
 		if (_IOC_TYPE(cmd) != 'E')
diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..b2d93b4 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -82,6 +82,9 @@ struct input_absinfo {
 
 #define EVIOCGRAB		_IOW('E', 0x90, int)			/* Grab/Release device */
 
+#define EVIOCGSUSPENDBLOCK	_IOR('E', 0x91, int)			/* get suspend block enable */
+#define EVIOCSSUSPENDBLOCK	_IOW('E', 0x91, int)			/* set suspend block enable */
+
 /*
  * Event types
  */
-- 
1.6.5.1

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

[PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending

[Arve Hjønnevåg]

When connecting usb or the charger the device would often go back to sleep
before the charge led and screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/power/power_supply_core.c |    9 ++++++---
 include/linux/power_supply.h      |    3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/power/power_supply_core.c b/drivers/power/power_supply_core.c
index cce75b4..577a131 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -39,7 +39,7 @@ static int __power_supply_changed_work(struct device *dev, void *data)
 static void power_supply_changed_work(struct work_struct *work)
 {
 	struct power_supply *psy = container_of(work, struct power_supply,
-						changed_work);
+						changed_work.work);
 
 	dev_dbg(psy->dev, "%s\n", __func__);
 
@@ -55,7 +55,7 @@ void power_supply_changed(struct power_supply *psy)
 {
 	dev_dbg(psy->dev, "%s\n", __func__);
 
-	schedule_work(&psy->changed_work);
+	schedule_suspend_blocking_work(&psy->changed_work);
 }
 EXPORT_SYMBOL_GPL(power_supply_changed);
 
@@ -155,7 +155,8 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 		goto dev_create_failed;
 	}
 
-	INIT_WORK(&psy->changed_work, power_supply_changed_work);
+	suspend_blocking_work_init(&psy->changed_work,
+				   power_supply_changed_work, "power-supply");
 
 	rc = power_supply_create_attrs(psy);
 	if (rc)
@@ -172,6 +173,7 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 create_triggers_failed:
 	power_supply_remove_attrs(psy);
 create_attrs_failed:
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 dev_create_failed:
 success:
@@ -184,6 +186,7 @@ void power_supply_unregister(struct power_supply *psy)
 	flush_scheduled_work();
 	power_supply_remove_triggers(psy);
 	power_supply_remove_attrs(psy);
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 }
 EXPORT_SYMBOL_GPL(power_supply_unregister);
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ebd2b8f..f6412c8 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -14,6 +14,7 @@
 #define __LINUX_POWER_SUPPLY_H__
 
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include <linux/workqueue.h>
 #include <linux/leds.h>
 
@@ -152,7 +153,7 @@ struct power_supply {
 
 	/* private */
 	struct device *dev;
-	struct work_struct changed_work;
+	struct suspend_blocking_work changed_work;
 
 #ifdef CONFIG_LEDS_TRIGGERS
 	struct led_trigger *charging_full_trig;
-- 
1.6.5.1

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5345 bytes --]


Hello,

some comments on the kernel-level suspend blocker API.

On Thu, 13 May 2010, Arve Hjønnevåg wrote:

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>

Another problem with the suspend-block kernel API is that its primary 
use-case[1] is to work around the brokenness of patch 1's opportunistic 
suspend governor.  The governor is broken because it intentionally ignores 
timers and the scheduler.  To work around problems caused by this 
decision, suspend-blocks must be spread throughout the kernel (and 
userspace) to restore the previous behavior of the system.  But if patch 
1's opportunistic suspend governor were fixed, most of the need for a 
suspend blockers would disappear.

[ This E-mail expands on some earlier comments[2] and is also related
  to other opportunistic suspend comments[3]. ]

The suspend-block patches require already-working code to be patched to 
keep it working.  This is a backwards approach.  Instead, broken code 
should be patched to fix the brokenness.  But the former approach is 
exactly what the suspend block API is intended to do.  Patches 7 and 8 in 
this series are two clear cases.  Patch 7 adds an ioctl to the input 
subsystem that will cause the system to stay running as long as there is 
an event in the event queue.  Patch 8 adds a suspend-block call to the 
power_supply code that causes the system to stay running as long as 
power_supply's changed_work workqueue has work to do.  Neither of these 
patches should be needed, since the default expectation of the mainline 
Linux kernel is that the system should run when there is work to be done.

This longstanding expectation should be preserved, not broken and then 
patched around.  But since patch 1 violates that expectation, there is no 
choice but to add patches 7 and 8 -- and ultimately many more patches -- 
to get a working system.  Once the opportunistic suspend governor in patch 
1 is introduced and enabled, the kernel will suspend the system 
immediately, even if the system has work to do.  The only way to prevent 
that is to add suspend-blocks.

Many suspend blocks will be needed throughout the kernel to keep things 
working.  One might think that patches 7 and 8 are the only changes needed 
to get a working Android-style opportunistic suspend system.  It turns out 
that many more changes are needed.  This can be seen by looking at 
currently shipping Android kernels, such as the current current Android 
'msm' kernel tree[4]. Suspend-blocker usage is spread through many drivers 
and subsystems:

[paul@twilight msm]$ fgrep -r wake_lock . | egrep '(^./drivers|^./arch)' | 
cut -f1 -d: | sort -u
./arch/arm/mach-msm/htc_battery.c
./arch/arm/mach-msm/pm.c
./arch/arm/mach-msm/qdsp5/adsp.c
./arch/arm/mach-msm/qdsp5/audio_out.c
./arch/arm/mach-msm/smd_qmi.c
./arch/arm/mach-msm/smd_rpcrouter.c
./arch/arm/mach-msm/smd_rpcrouter.h
./arch/arm/mach-msm/smd_rpcrouter_servers.c
./arch/arm/mach-msm/smd_tty.c
./drivers/i2c/chips/mt9t013.c
./drivers/input/evdev.c
./drivers/input/misc/gpio_input.c
./drivers/input/misc/gpio_matrix.c
./drivers/mmc/core/core.c
./drivers/net/msm_rmnet.c
./drivers/rtc/alarm.c
./drivers/serial/msm_serial_hs.c
./drivers/usb/function/mass_storage.c
./drivers/usb/gadget/f_mass_storage.c
./drivers/video/msm/mddi.c
./drivers/video/msm/msm_fb.c

I guess this is something like what kernel developers should eventually 
expect to see if suspend blockers are merged.

There is a better way to make the system work as expected: these patch 1 
shouldn't break general timer and scheduler assumptions.  If patch 1's 
governor is fixed, most of these calls will be unnecessary.  The apparent 
motivation is to prevent "untrusted" userspace processes from preventing 
the system from entering a low-power state.  I agree that this is a 
problem.  But it should be fixed by modifying the specific Linux code that 
determines when the idle loop is entered and when the next timer wakeup 
should occur, on a per-process basis.  Such targeted changes would ensure 
that the rest of the kernel would continue to execute as expected.

regards,

- Paul


1. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Mon, 3
   May 2010 17:09:22 -0700:
   http://www.spinics.net/lists/linux-pm/msg18432.html

2. Paul Walmsley E-mail to the linux-pm mailing list, dated Wed, 12
   May 2010 21:35:30 -0600: http://lkml.org/lkml/2010/5/12/528

3. Paul Walmsley E-mail to the linux-pm mailing list, dated Thu, 13
   May 2010 13:01:33 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18592

4. git://android.git.kernel.org/kernel/msm.git - as of commit
   c7f8bcecb06b937c45dd0e342450a3218b286b8d, "[ARM] msm: defconfig:
   Set mmap_min_addr to 32k"

5. http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/mmc/core/core.c;h=22f6ddad85c92f34c55035982049bb03b5abfc74;hb=c7f8bcecb06b937c45dd0e342450a3218b286b8d#l721

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3860 bytes --]


Hello,

Another comment on the kernel suspend-blocker API.

On Thu, 13 May 2010, Arve Hjønnevåg wrote:

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>

Looking at the way that suspend-blocks are used in the current Android 
'msm' kernel tree[1], they seem likely to cause layering violations, 
fragile kernel code with userspace dependencies, and code that consumes 
power unnecessarily.

For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find 
the following code:

	/* give userspace some time to react */
	wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);

This is a layering violation.  The MMC subsystem should have nothing to do 
with "giving userspace time to react."  That is the responsibility of the 
Linux scheduler.

This code is also intrinsically fragile and use-case dependent.  What if 
userspace occasionally needs more than (HZ / 2) to react?  If the 
distributor is lucky enough to catch this before the product ships, then 
the distributor can patch in a new magic number.  But if the device makes 
it to the consumer, the result is an unstable device that unpredictably 
suspends.

The above code will also waste power.  Even if userspace takes less than 
(HZ / 2) to react, the system will still be prevented from entering a 
system-wide low power state for the duration of the remaining time.  This 
is in contrast to an approach that uses the idle loop to enter a 
system-wide low power state.  The moment that the system has no further 
work to do, it can start saving power.

The problems with the above example are not isolated:

[paul@twilight msm]$ fgrep -r wake_lock_timeout . | egrep '(^./drivers|^./arch)'
./arch/arm/mach-msm/htc_battery.c:		wake_lock_timeout(&vbus_wake_lock, HZ / 2);
./arch/arm/mach-msm/smd_tty.c:		wake_lock_timeout(&info->wake_lock, HZ / 2);
./arch/arm/mach-msm/smd_qmi.c:		wake_lock_timeout(&ctxt->wake_lock, HZ / 2);
./drivers/rtc/alarm.c:		wake_lock_timeout(&alarm_wake_lock, 5 * HZ);
./drivers/rtc/alarm.c:	wake_lock_timeout(&alarm_rtc_wake_lock, 1 * HZ);
./drivers/rtc/alarm.c:			wake_lock_timeout(&alarm_rtc_wake_lock, 2 * HZ);
./drivers/mmc/core/core.c:	wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
./drivers/net/msm_rmnet.c:	wake_lock_timeout(&p->wake_lock, HZ / 2);
./drivers/video/msm/msm_fb.c:	wake_lock_timeout(&msmfb->idle_lock, HZ/4);
./drivers/video/msm/msm_fb.c:		wake_lock_timeout(&msmfb->idle_lock, HZ/4);
./drivers/video/msm/msm_fb.c:		wake_lock_timeout(&msmfb->idle_lock, HZ);
./drivers/input/evdev.c:	wake_lock_timeout(&client->wake_lock, 5 * HZ);
./drivers/serial/msm_serial_hs.c:	wake_lock_timeout(&msm_uport->rx.wake_lock, HZ / 2);

It is true that the current patch series does not propose the *_timeout() 
interface.  But that raises the question of what it will be replaced with, 
in situations where the problem can't simply be pushed to userspace, as it 
is in Arve's evdev patch 7.  Some of these cases seem difficult to handle 
without some sort of timer-based approach.  Timer-based approaches are 
intrinsically problematic for the reasons mentioned above.


- Paul


1. git://android.git.kernel.org/kernel/msm.git - as of commit
   c7f8bcecb06b937c45dd0e342450a3218b286b8d, "[ARM] msm: defconfig:
   Set mmap_min_addr to 32k"

2. http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/mmc/core/core.c;h=22f6ddad85c92f34c55035982049bb03b5abfc74;hb=c7f8bcecb06b937c45dd0e342450a3218b286b8d#l721



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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hello,
>
> Another comment on the kernel suspend-blocker API.
>
> On Thu, 13 May 2010, Arve Hjønnevåg wrote:
>
>> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
>> After setting the policy to opportunistic, writes to /sys/power/state
>> become non-blocking requests that specify which suspend state to enter
>> when no suspend blockers are active. A special state, "on", stops the
>> process by activating the "main" suspend blocker.
>>
>> Signed-off-by: Arve Hjønnevåg <arve@android.com>
>
> Looking at the way that suspend-blocks are used in the current Android
> 'msm' kernel tree[1], they seem likely to cause layering violations,
> fragile kernel code with userspace dependencies, and code that consumes
> power unnecessarily.
>
> For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
> the following code:
>
>        /* give userspace some time to react */
>        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
>
> This is a layering violation.  The MMC subsystem should have nothing to do
> with "giving userspace time to react."  That is the responsibility of the
> Linux scheduler.
>
> This code is also intrinsically fragile and use-case dependent.  What if
> userspace occasionally needs more than (HZ / 2) to react?  If the
> distributor is lucky enough to catch this before the product ships, then
> the distributor can patch in a new magic number.  But if the device makes
> it to the consumer, the result is an unstable device that unpredictably
> suspends.
>
> The above code will also waste power.  Even if userspace takes less than
> (HZ / 2) to react, the system will still be prevented from entering a
> system-wide low power state for the duration of the remaining time.  This
> is in contrast to an approach that uses the idle loop to enter a
> system-wide low power state.  The moment that the system has no further
> work to do, it can start saving power.
>

Yes, preventing suspend for 1/2 second wastes some power, but are you
seriously suggesting that it wastes more power then never suspending?
Opportunitic suspend does not prevent entering low power modes from
idle.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3446 bytes --]

Hello Arve,

On Fri, 14 May 2010, Arve Hjønnevåg wrote:

> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
> >
> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> >> After setting the policy to opportunistic, writes to /sys/power/state
> >> become non-blocking requests that specify which suspend state to enter
> >> when no suspend blockers are active. A special state, "on", stops the
> >> process by activating the "main" suspend blocker.
> >>
> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> >
> > Looking at the way that suspend-blocks are used in the current Android
> > 'msm' kernel tree[1], they seem likely to cause layering violations,
> > fragile kernel code with userspace dependencies, and code that consumes
> > power unnecessarily.
> >
> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
> > the following code:
> >
> >        /* give userspace some time to react */
> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
> >
> > This is a layering violation.  The MMC subsystem should have nothing to do
> > with "giving userspace time to react."  That is the responsibility of the
> > Linux scheduler.
> >
> > This code is also intrinsically fragile and use-case dependent.  What if
> > userspace occasionally needs more than (HZ / 2) to react?  If the
> > distributor is lucky enough to catch this before the product ships, then
> > the distributor can patch in a new magic number.  But if the device makes
> > it to the consumer, the result is an unstable device that unpredictably
> > suspends.
> >
> > The above code will also waste power.  Even if userspace takes less than
> > (HZ / 2) to react, the system will still be prevented from entering a
> > system-wide low power state for the duration of the remaining time.  This
> > is in contrast to an approach that uses the idle loop to enter a
> > system-wide low power state.  The moment that the system has no further
> > work to do, it can start saving power.
> >
> 
> Yes, preventing suspend for 1/2 second wastes some power, but are you
> seriously suggesting that it wastes more power then never suspending?
> Opportunitic suspend does not prevent entering low power modes from
> idle.

Sorry, my E-mail was unclear.  Here is my intended point:

The current Android opportunistic suspend governor does not enter full 
system suspend until all suspend-blocks are released.  If the governor 
were modified to respect the scheduler, then it could enter suspend the 
moment that the system had no further work to do.

So during part of the (HZ / 2) time interval in the above code, the system 
is running some kernel or userspace code.  But after that work is done, an 
idle-loop-based opportunistic suspend governor could enter idle during 
the remaining portion of that (HZ / 2) time interval, while the current 
governor must keep the system out of suspend.

Of course, to do this, a different method for freezing processes would be 
needed; one possible approach is described here[1]; others have proposed 
similar approaches.


regards,

- Paul


1. Paragraphs B4A and B4B of Paul Walmsley E-mail to the linux-pm mailing 
   list, dated Mon May 17 18:39:44 PDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Mon, May 17, 2010 at 7:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Arve,
>
> On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>
>> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
>> >> After setting the policy to opportunistic, writes to /sys/power/state
>> >> become non-blocking requests that specify which suspend state to enter
>> >> when no suspend blockers are active. A special state, "on", stops the
>> >> process by activating the "main" suspend blocker.
>> >>
>> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
>> >
>> > Looking at the way that suspend-blocks are used in the current Android
>> > 'msm' kernel tree[1], they seem likely to cause layering violations,
>> > fragile kernel code with userspace dependencies, and code that consumes
>> > power unnecessarily.
>> >
>> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
>> > the following code:
>> >
>> >        /* give userspace some time to react */
>> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
>> >
>> > This is a layering violation.  The MMC subsystem should have nothing to do
>> > with "giving userspace time to react."  That is the responsibility of the
>> > Linux scheduler.
>> >
>> > This code is also intrinsically fragile and use-case dependent.  What if
>> > userspace occasionally needs more than (HZ / 2) to react?  If the
>> > distributor is lucky enough to catch this before the product ships, then
>> > the distributor can patch in a new magic number.  But if the device makes
>> > it to the consumer, the result is an unstable device that unpredictably
>> > suspends.
>> >
>> > The above code will also waste power.  Even if userspace takes less than
>> > (HZ / 2) to react, the system will still be prevented from entering a
>> > system-wide low power state for the duration of the remaining time.  This
>> > is in contrast to an approach that uses the idle loop to enter a
>> > system-wide low power state.  The moment that the system has no further
>> > work to do, it can start saving power.
>> >
>>
>> Yes, preventing suspend for 1/2 second wastes some power, but are you
>> seriously suggesting that it wastes more power then never suspending?
>> Opportunitic suspend does not prevent entering low power modes from
>> idle.
>
> Sorry, my E-mail was unclear.  Here is my intended point:
>
> The current Android opportunistic suspend governor does not enter full
> system suspend until all suspend-blocks are released.  If the governor
> were modified to respect the scheduler, then it could enter suspend the
> moment that the system had no further work to do.
>

On the hardware that shipped we enter the same power state from idle
and suspend, so the only power savings we get from suspend that we
don't get in idle is from not respecting the scheduler and timers.

> So during part of the (HZ / 2) time interval in the above code, the system
> is running some kernel or userspace code.  But after that work is done, an
> idle-loop-based opportunistic suspend governor could enter idle during
> the remaining portion of that (HZ / 2) time interval, while the current
> governor must keep the system out of suspend.
>
Triggering a full suspend (that disregards normal timers) from idle
does not work, since the system may temporarily enter idle while
processing the event.

> Of course, to do this, a different method for freezing processes would be
> needed; one possible approach is described here[1]; others have proposed
> similar approaches.
>

If you freeze processes you need something like a suspend blocker to
prevent processes from being frozen. By having a process that never
gets frozen you could implement this entirely in user space, but you
would have to funnel all wakeup events though this process.

>
> regards,
>
> - Paul
>
>
> 1. Paragraphs B4A and B4B of Paul Walmsley E-mail to the linux-pm mailing
>   list, dated Mon May 17 18:39:44 PDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5241 bytes --]

Hello Arve,

On Mon, 17 May 2010, Arve Hjønnevåg wrote:

> On Mon, May 17, 2010 at 7:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
> >> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
> >> >
> >> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> >> >> After setting the policy to opportunistic, writes to /sys/power/state
> >> >> become non-blocking requests that specify which suspend state to enter
> >> >> when no suspend blockers are active. A special state, "on", stops the
> >> >> process by activating the "main" suspend blocker.
> >> >>
> >> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> >> >
> >> > Looking at the way that suspend-blocks are used in the current Android
> >> > 'msm' kernel tree[1], they seem likely to cause layering violations,
> >> > fragile kernel code with userspace dependencies, and code that consumes
> >> > power unnecessarily.
> >> >
> >> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
> >> > the following code:
> >> >
> >> >        /* give userspace some time to react */
> >> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
> >> >
> >> > This is a layering violation.  The MMC subsystem should have nothing to do
> >> > with "giving userspace time to react."  That is the responsibility of the
> >> > Linux scheduler.
> >> >
> >> > This code is also intrinsically fragile and use-case dependent.  What if
> >> > userspace occasionally needs more than (HZ / 2) to react?  If the
> >> > distributor is lucky enough to catch this before the product ships, then
> >> > the distributor can patch in a new magic number.  But if the device makes
> >> > it to the consumer, the result is an unstable device that unpredictably
> >> > suspends.
> >> >
> >> > The above code will also waste power.  Even if userspace takes less than
> >> > (HZ / 2) to react, the system will still be prevented from entering a
> >> > system-wide low power state for the duration of the remaining time.  This
> >> > is in contrast to an approach that uses the idle loop to enter a
> >> > system-wide low power state.  The moment that the system has no further
> >> > work to do, it can start saving power.
> >> >
> >>
> >> Yes, preventing suspend for 1/2 second wastes some power, but are you
> >> seriously suggesting that it wastes more power then never suspending?
> >> Opportunitic suspend does not prevent entering low power modes from
> >> idle.
> >
> > Sorry, my E-mail was unclear.  Here is my intended point:
> >
> > The current Android opportunistic suspend governor does not enter full
> > system suspend until all suspend-blocks are released.  If the governor
> > were modified to respect the scheduler, then it could enter suspend the
> > moment that the system had no further work to do.
> >
> 
> On the hardware that shipped we enter the same power state from idle
> and suspend, so the only power savings we get from suspend that we
> don't get in idle is from not respecting the scheduler and timers.

Other people 
say that their hardware XXX.  (This is probably likely for anything that 
supports ACPI.)

> > So during part of the (HZ / 2) time interval in the above code, the system
> > is running some kernel or userspace code.  But after that work is done, an
> > idle-loop-based opportunistic suspend governor could enter idle during
> > the remaining portion of that (HZ / 2) time interval, while the current
> > governor must keep the system out of suspend.
> >
> Triggering a full suspend (that disregards normal timers) from idle
> does not work, since the system may temporarily enter idle while
> processing the event.

Could you provide an example?

In such a case, how can the kernel guarantee that the system will process 
the event within (HZ / 2) seconds?

> > Of course, to do this, a different method for freezing processes would be
> > needed; one possible approach is described here[1]; others have proposed
> > similar approaches.
> 
> If you freeze processes you need something like a suspend blocker to
> prevent processes from being frozen. 

(It occurs to me that "frozen" is the wrong terminology to use.
 Perhaps "paused" would be a better term, along the lines of [1].)

The full set of processes does not need to be paused.  For example, if 
"untrusted" processes are run in a cgroup, and only tasks in that cgroup 
are put into TASK_INTERRUPTIBLE, then "trusted" processes will not be 
paused.

> By having a process that never gets frozen you could implement this 
> entirely in user space, but you would have to funnel all wakeup events 
> though this process.

The proposal[2] does require a kernel change.  No wakeup funnel process 
would be needed.  The proposal is to put processes into 
TASK_INTERRUPTIBLE, not TASK_STOPPED (unlike most "freezers").


- Paul


1. Paragraph B4B of Paul Walmsley E-mail to the linux-pm mailing 
   list, dated Mon May 17 18:39:44 PDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html

2. ibid.


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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Mon, May 17, 2010 at 8:34 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Arve,
>
> On Mon, 17 May 2010, Arve Hjønnevåg wrote:
>
>> On Mon, May 17, 2010 at 7:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>> >> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
>> >> >
>> >> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
>> >> >> After setting the policy to opportunistic, writes to /sys/power/state
>> >> >> become non-blocking requests that specify which suspend state to enter
>> >> >> when no suspend blockers are active. A special state, "on", stops the
>> >> >> process by activating the "main" suspend blocker.
>> >> >>
>> >> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
>> >> >
>> >> > Looking at the way that suspend-blocks are used in the current Android
>> >> > 'msm' kernel tree[1], they seem likely to cause layering violations,
>> >> > fragile kernel code with userspace dependencies, and code that consumes
>> >> > power unnecessarily.
>> >> >
>> >> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
>> >> > the following code:
>> >> >
>> >> >        /* give userspace some time to react */
>> >> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
>> >> >
>> >> > This is a layering violation.  The MMC subsystem should have nothing to do
>> >> > with "giving userspace time to react."  That is the responsibility of the
>> >> > Linux scheduler.
>> >> >
>> >> > This code is also intrinsically fragile and use-case dependent.  What if
>> >> > userspace occasionally needs more than (HZ / 2) to react?  If the
>> >> > distributor is lucky enough to catch this before the product ships, then
>> >> > the distributor can patch in a new magic number.  But if the device makes
>> >> > it to the consumer, the result is an unstable device that unpredictably
>> >> > suspends.
>> >> >
>> >> > The above code will also waste power.  Even if userspace takes less than
>> >> > (HZ / 2) to react, the system will still be prevented from entering a
>> >> > system-wide low power state for the duration of the remaining time.  This
>> >> > is in contrast to an approach that uses the idle loop to enter a
>> >> > system-wide low power state.  The moment that the system has no further
>> >> > work to do, it can start saving power.
>> >> >
>> >>
>> >> Yes, preventing suspend for 1/2 second wastes some power, but are you
>> >> seriously suggesting that it wastes more power then never suspending?
>> >> Opportunitic suspend does not prevent entering low power modes from
>> >> idle.
>> >
>> > Sorry, my E-mail was unclear.  Here is my intended point:
>> >
>> > The current Android opportunistic suspend governor does not enter full
>> > system suspend until all suspend-blocks are released.  If the governor
>> > were modified to respect the scheduler, then it could enter suspend the
>> > moment that the system had no further work to do.
>> >
>>
>> On the hardware that shipped we enter the same power state from idle
>> and suspend, so the only power savings we get from suspend that we
>> don't get in idle is from not respecting the scheduler and timers.
>
> Other people
> say that their hardware XXX.  (This is probably likely for anything that
> supports ACPI.)
>
>> > So during part of the (HZ / 2) time interval in the above code, the system
>> > is running some kernel or userspace code.  But after that work is done, an
>> > idle-loop-based opportunistic suspend governor could enter idle during
>> > the remaining portion of that (HZ / 2) time interval, while the current
>> > governor must keep the system out of suspend.
>> >
>> Triggering a full suspend (that disregards normal timers) from idle
>> does not work, since the system may temporarily enter idle while
>> processing the event.
>
> Could you provide an example?

The code takes a pagefault. The system is idle while waiting for the
dma to finish.

>
> In such a case, how can the kernel guarantee that the system will process
> the event within (HZ / 2) seconds?
>

It can't, but in my opinion if the event did not start processing in
1/2 second it was probably not time critical.

>> > Of course, to do this, a different method for freezing processes would be
>> > needed; one possible approach is described here[1]; others have proposed
>> > similar approaches.
>>
>> If you freeze processes you need something like a suspend blocker to
>> prevent processes from being frozen.
>
> (It occurs to me that "frozen" is the wrong terminology to use.
>  Perhaps "paused" would be a better term, along the lines of [1].)
>
> The full set of processes does not need to be paused.  For example, if
> "untrusted" processes are run in a cgroup, and only tasks in that cgroup
> are put into TASK_INTERRUPTIBLE, then "trusted" processes will not be
> paused.
>

We want to freeze trusted processes.

>> By having a process that never gets frozen you could implement this
>> entirely in user space, but you would have to funnel all wakeup events
>> though this process.
>
> The proposal[2] does require a kernel change.  No wakeup funnel process
> would be needed.  The proposal is to put processes into
> TASK_INTERRUPTIBLE, not TASK_STOPPED (unlike most "freezers").
>

Why is the method used for pausing the processes relevant? If the
process is paused it cannot process the wakeup event. The only way to
get the wake event to the process is to funnel it though a process
that never is paused.

>
> - Paul
>
>
> 1. Paragraph B4B of Paul Walmsley E-mail to the linux-pm mailing
>   list, dated Mon May 17 18:39:44 PDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html
>
> 2. ibid.
>
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6871 bytes --]

Hi Arve,

On Mon, 17 May 2010, Arve Hjønnevåg wrote:

> On Mon, May 17, 2010 at 8:34 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Mon, 17 May 2010, Arve Hjønnevåg wrote:
> >> On Mon, May 17, 2010 at 7:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
> >> >> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >> >> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
> >> >> >
> >> >> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> >> >> >> After setting the policy to opportunistic, writes to /sys/power/state
> >> >> >> become non-blocking requests that specify which suspend state to enter
> >> >> >> when no suspend blockers are active. A special state, "on", stops the
> >> >> >> process by activating the "main" suspend blocker.
> >> >> >>
> >> >> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> >> >> >
> >> >> > Looking at the way that suspend-blocks are used in the current Android
> >> >> > 'msm' kernel tree[1], they seem likely to cause layering violations,
> >> >> > fragile kernel code with userspace dependencies, and code that consumes
> >> >> > power unnecessarily.
> >> >> >
> >> >> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
> >> >> > the following code:
> >> >> >
> >> >> >        /* give userspace some time to react */
> >> >> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
> >> >> >
> >> >> > This is a layering violation.  The MMC subsystem should have nothing to do
> >> >> > with "giving userspace time to react."  That is the responsibility of the
> >> >> > Linux scheduler.
> >> >> >
> >> >> > This code is also intrinsically fragile and use-case dependent.  What if
> >> >> > userspace occasionally needs more than (HZ / 2) to react?  If the
> >> >> > distributor is lucky enough to catch this before the product ships, then
> >> >> > the distributor can patch in a new magic number.  But if the device makes
> >> >> > it to the consumer, the result is an unstable device that unpredictably
> >> >> > suspends.
> >> >> >
> >> >> > The above code will also waste power.  Even if userspace takes less than
> >> >> > (HZ / 2) to react, the system will still be prevented from entering a
> >> >> > system-wide low power state for the duration of the remaining time.  This
> >> >> > is in contrast to an approach that uses the idle loop to enter a
> >> >> > system-wide low power state.  The moment that the system has no further
> >> >> > work to do, it can start saving power.
> >> >> >
> >> >>
> >> >> Yes, preventing suspend for 1/2 second wastes some power, but are you
> >> >> seriously suggesting that it wastes more power then never suspending?
> >> >> Opportunitic suspend does not prevent entering low power modes from
> >> >> idle.
> >> >
> >> > Sorry, my E-mail was unclear.  Here is my intended point:
> >> >
> >> > The current Android opportunistic suspend governor does not enter full
> >> > system suspend until all suspend-blocks are released.  If the governor
> >> > were modified to respect the scheduler, then it could enter suspend the
> >> > moment that the system had no further work to do.
> >> >
> >>
> >> On the hardware that shipped we enter the same power state from idle
> >> and suspend, so the only power savings we get from suspend that we
> >> don't get in idle is from not respecting the scheduler and timers.
> >
> > Other people
> > say that their hardware XXX.  (This is probably likely for anything that
> > supports ACPI.)

Heh, looks like this part of my E-mail escaped a little too early.

> >> > So during part of the (HZ / 2) time interval in the above code, the system
> >> > is running some kernel or userspace code.  But after that work is done, an
> >> > idle-loop-based opportunistic suspend governor could enter idle during
> >> > the remaining portion of that (HZ / 2) time interval, while the current
> >> > governor must keep the system out of suspend.
> >> >
> >> Triggering a full suspend (that disregards normal timers) from idle
> >> does not work, since the system may temporarily enter idle while
> >> processing the event.
> >
> > Could you provide an example?
> 
> The code takes a pagefault. The system is idle while waiting for the
> dma to finish.

OK.

> > In such a case, how can the kernel guarantee that the system will process
> > the event within (HZ / 2) seconds?
>
> It can't, but in my opinion if the event did not start processing in
> 1/2 second it was probably not time critical.

Thanks for the correction regarding the unit of the time interval.

To use the pagefault example, wouldn't that be partially dependent on 
factors outside the control of the task that handles the input event?  
(e.g., the time needed to page back in, or other code running on the 
system.)

> >> > Of course, to do this, a different method for freezing processes would be
> >> > needed; one possible approach is described here[1]; others have proposed
> >> > similar approaches.
> >>
> >> If you freeze processes you need something like a suspend blocker to
> >> prevent processes from being frozen.
> >
> > (It occurs to me that "frozen" is the wrong terminology to use.
> >  Perhaps "paused" would be a better term, along the lines of [1].)
> >
> > The full set of processes does not need to be paused.  For example, if
> > "untrusted" processes are run in a cgroup, and only tasks in that cgroup
> > are put into TASK_INTERRUPTIBLE, then "trusted" processes will not be
> > paused.
> 
> We want to freeze trusted processes.

By "trusted," I mean processes that are run with a suspend block, as in 
your example to Tony[1].  Isn't it so that Android has processes that 
either run entirely under suspend-blocks, or which take suspend-blocks at 
some point in time during their execution?  Wouldn't those processes need 
to be prevented from a force-pause or force-freeze?

> >> By having a process that never gets frozen you could implement this
> >> entirely in user space, but you would have to funnel all wakeup events
> >> though this process.
> >
> > The proposal[2] does require a kernel change.  No wakeup funnel process
> > would be needed.  The proposal is to put processes into
> > TASK_INTERRUPTIBLE, not TASK_STOPPED (unlike most "freezers").
> >
> 
> Why is the method used for pausing the processes relevant? If the
> process is paused it cannot process the wakeup event.

Tasks in TASK_INTERRUPTIBLE are woken back up when an event arrives, 
unlike tasks in TASK_STOPPED, which are stopped until a SIGCONT arrives.

> The only way to get the wake event to the process is to funnel it though 
> a process that never is paused.


- Paul

1. http://lkml.org/lkml/2010/5/7/420


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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Wed, May 19, 2010 at 8:55 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi Arve,
>
> On Mon, 17 May 2010, Arve Hjønnevåg wrote:
>
>> On Mon, May 17, 2010 at 8:34 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Mon, 17 May 2010, Arve Hjønnevåg wrote:
>> >> On Mon, May 17, 2010 at 7:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> On Thu, May 13, 2010 at 11:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> >> > On Thu, 13 May 2010, Arve Hjønnevåg wrote:
>> >> >> >
>> >> >> >> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
>> >> >> >> After setting the policy to opportunistic, writes to /sys/power/state
>> >> >> >> become non-blocking requests that specify which suspend state to enter
>> >> >> >> when no suspend blockers are active. A special state, "on", stops the
>> >> >> >> process by activating the "main" suspend blocker.
>> >> >> >>
>> >> >> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
>> >> >> >
>> >> >> > Looking at the way that suspend-blocks are used in the current Android
>> >> >> > 'msm' kernel tree[1], they seem likely to cause layering violations,
>> >> >> > fragile kernel code with userspace dependencies, and code that consumes
>> >> >> > power unnecessarily.
>> >> >> >
>> >> >> > For example, in drivers/mmc/core/core.c:721, in mmc_rescan() [2], we find
>> >> >> > the following code:
>> >> >> >
>> >> >> >        /* give userspace some time to react */
>> >> >> >        wake_lock_timeout(&mmc_delayed_work_wake_lock, HZ / 2);
>> >> >> >
>> >> >> > This is a layering violation.  The MMC subsystem should have nothing to do
>> >> >> > with "giving userspace time to react."  That is the responsibility of the
>> >> >> > Linux scheduler.
>> >> >> >
>> >> >> > This code is also intrinsically fragile and use-case dependent.  What if
>> >> >> > userspace occasionally needs more than (HZ / 2) to react?  If the
>> >> >> > distributor is lucky enough to catch this before the product ships, then
>> >> >> > the distributor can patch in a new magic number.  But if the device makes
>> >> >> > it to the consumer, the result is an unstable device that unpredictably
>> >> >> > suspends.
>> >> >> >
>> >> >> > The above code will also waste power.  Even if userspace takes less than
>> >> >> > (HZ / 2) to react, the system will still be prevented from entering a
>> >> >> > system-wide low power state for the duration of the remaining time.  This
>> >> >> > is in contrast to an approach that uses the idle loop to enter a
>> >> >> > system-wide low power state.  The moment that the system has no further
>> >> >> > work to do, it can start saving power.
>> >> >> >
>> >> >>
>> >> >> Yes, preventing suspend for 1/2 second wastes some power, but are you
>> >> >> seriously suggesting that it wastes more power then never suspending?
>> >> >> Opportunitic suspend does not prevent entering low power modes from
>> >> >> idle.
>> >> >
>> >> > Sorry, my E-mail was unclear.  Here is my intended point:
>> >> >
>> >> > The current Android opportunistic suspend governor does not enter full
>> >> > system suspend until all suspend-blocks are released.  If the governor
>> >> > were modified to respect the scheduler, then it could enter suspend the
>> >> > moment that the system had no further work to do.
>> >> >
>> >>
>> >> On the hardware that shipped we enter the same power state from idle
>> >> and suspend, so the only power savings we get from suspend that we
>> >> don't get in idle is from not respecting the scheduler and timers.
>> >
>> > Other people
>> > say that their hardware XXX.  (This is probably likely for anything that
>> > supports ACPI.)
>
> Heh, looks like this part of my E-mail escaped a little too early.
>
>> >> > So during part of the (HZ / 2) time interval in the above code, the system
>> >> > is running some kernel or userspace code.  But after that work is done, an
>> >> > idle-loop-based opportunistic suspend governor could enter idle during
>> >> > the remaining portion of that (HZ / 2) time interval, while the current
>> >> > governor must keep the system out of suspend.
>> >> >
>> >> Triggering a full suspend (that disregards normal timers) from idle
>> >> does not work, since the system may temporarily enter idle while
>> >> processing the event.
>> >
>> > Could you provide an example?
>>
>> The code takes a pagefault. The system is idle while waiting for the
>> dma to finish.
>
> OK.
>
>> > In such a case, how can the kernel guarantee that the system will process
>> > the event within (HZ / 2) seconds?
>>
>> It can't, but in my opinion if the event did not start processing in
>> 1/2 second it was probably not time critical.
>
> Thanks for the correction regarding the unit of the time interval.
>
> To use the pagefault example, wouldn't that be partially dependent on
> factors outside the control of the task that handles the input event?
> (e.g., the time needed to page back in, or other code running on the
> system.)
>
Yes (we don't need any timeouts to handle input events though).

>> >> > Of course, to do this, a different method for freezing processes would be
>> >> > needed; one possible approach is described here[1]; others have proposed
>> >> > similar approaches.
>> >>
>> >> If you freeze processes you need something like a suspend blocker to
>> >> prevent processes from being frozen.
>> >
>> > (It occurs to me that "frozen" is the wrong terminology to use.
>> >  Perhaps "paused" would be a better term, along the lines of [1].)
>> >
>> > The full set of processes does not need to be paused.  For example, if
>> > "untrusted" processes are run in a cgroup, and only tasks in that cgroup
>> > are put into TASK_INTERRUPTIBLE, then "trusted" processes will not be
>> > paused.
>>
>> We want to freeze trusted processes.
>
> By "trusted," I mean processes that are run with a suspend block, as in
> your example to Tony[1].  Isn't it so that Android has processes that
> either run entirely under suspend-blocks, or which take suspend-blocks at
> some point in time during their execution?  Wouldn't those processes need
> to be prevented from a force-pause or force-freeze?
>
We don't freeze processes while any suspend blockers are active.

>> >> By having a process that never gets frozen you could implement this
>> >> entirely in user space, but you would have to funnel all wakeup events
>> >> though this process.
>> >
>> > The proposal[2] does require a kernel change.  No wakeup funnel process
>> > would be needed.  The proposal is to put processes into
>> > TASK_INTERRUPTIBLE, not TASK_STOPPED (unlike most "freezers").
>> >
>>
>> Why is the method used for pausing the processes relevant? If the
>> process is paused it cannot process the wakeup event.
>
> Tasks in TASK_INTERRUPTIBLE are woken back up when an event arrives,

So you are not actually preventing them from. A task that wakes up 60
times a second will still drain the battery, unless you happened to
pause it while it was active.

> unlike tasks in TASK_STOPPED, which are stopped until a SIGCONT arrives.
>
>> The only way to get the wake event to the process is to funnel it though
>> a process that never is paused.
>
>
> - Paul
>
> 1. http://lkml.org/lkml/2010/5/7/420
>
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to
> enter

Yeah, one file selects behavior of another file, and to read available
states for opportunistic, you have to write to file first.

I still don't like the interface.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Florian Mickler]

On Tue, 18 May 2010 15:11:11 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote:
> > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > After setting the policy to opportunistic, writes to /sys/power/state
> > become non-blocking requests that specify which suspend state to
> > enter
> 
> Yeah, one file selects behavior of another file, and to read available
> states for opportunistic, you have to write to file first.
> 
> I still don't like the interface.
> 

Actually, what would be a better interface? 

I wonder why it is not like this:

/sys/power/state 
	no change, works with and without opportunistic suspend the
	same. Ignores suspend blockers. Really no change. (From user
	perspective)

/sys/power/opportunistic
	On / Off
	While Off the opportunistic suspend is off.
	While On, the opportunistic suspend is on and if there are no
	suspend blockers the system goes to suspend. 

Cheers,
Flo

Re: [PATCH 1/8] PM: Add suspend block api.

[Florian Mickler]

On Thu, 20 May 2010 11:11:11 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Tue, 18 May 2010 15:11:11 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote:
> > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > After setting the policy to opportunistic, writes to /sys/power/state
> > > become non-blocking requests that specify which suspend state to
> > > enter
> > 
> > Yeah, one file selects behavior of another file, and to read available
> > states for opportunistic, you have to write to file first.
> > 
> > I still don't like the interface.
> > 
> 
> Actually, what would be a better interface? 
> 
> I wonder why it is not like this:
> 
> /sys/power/state 
> 	no change, works with and without opportunistic suspend the
> 	same. Ignores suspend blockers. Really no change. (From user
> 	perspective)
> 
> /sys/power/opportunistic
> 	On / Off
> 	While Off the opportunistic suspend is off.
> 	While On, the opportunistic suspend is on and if there are no
> 	suspend blockers the system goes to suspend. 
> 

I forgot, of course there needs to be another knob to implement the
"on" behaviour  in the opportunistic mode

 /sys/power/block_opportunistic_suspend

There you have it. One file, one purpose. 

> Cheers,
> Flo

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Thursday 20 May 2010, Florian Mickler wrote:
> On Thu, 20 May 2010 11:11:11 +0200
> Florian Mickler <florian@mickler.org> wrote:
> 
> > On Tue, 18 May 2010 15:11:11 +0200
> > Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > > On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote:
> > > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > > After setting the policy to opportunistic, writes to /sys/power/state
> > > > become non-blocking requests that specify which suspend state to
> > > > enter
> > > 
> > > Yeah, one file selects behavior of another file, and to read available
> > > states for opportunistic, you have to write to file first.
> > > 
> > > I still don't like the interface.
> > > 
> > 
> > Actually, what would be a better interface? 
> > 
> > I wonder why it is not like this:

Because I think the "forced" and "opportunistic" suspend "modes" are mutually
exclusive in practice and the interface as proposed reflects that quite well.

> > /sys/power/state 
> > 	no change, works with and without opportunistic suspend the
> > 	same. Ignores suspend blockers. Really no change. (From user
> > 	perspective)
> > 
> > /sys/power/opportunistic
> > 	On / Off
> > 	While Off the opportunistic suspend is off.
> > 	While On, the opportunistic suspend is on and if there are no
> > 	suspend blockers the system goes to suspend. 
> > 
> 
> I forgot, of course there needs to be another knob to implement the
> "on" behaviour  in the opportunistic mode
> 
>  /sys/power/block_opportunistic_suspend
> 
> There you have it. One file, one purpose. 

That's getting messy IMHO.

In addition to that you get a nice race when the user writes "mem"
to /sys/power/state and opportunistic suspend happens at the same time.
If the latter wins the race, the system will suspend again immediately after
being woken up, which probably is not the result you'd like to get.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Florian Mickler]

On Fri, 21 May 2010 00:18:43 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > > Actually, what would be a better interface? 
> > > 
> > > I wonder why it is not like this:
> 
> Because I think the "forced" and "opportunistic" suspend "modes" are mutually
> exclusive in practice and the interface as proposed reflects that quite well.
> 
> > > /sys/power/state 
> > > 	no change, works with and without opportunistic suspend the
> > > 	same. Ignores suspend blockers. Really no change. (From user
> > > 	perspective)
> > > 
> > > /sys/power/opportunistic
> > > 	On / Off
> > > 	While Off the opportunistic suspend is off.
> > > 	While On, the opportunistic suspend is on and if there are no
> > > 	suspend blockers the system goes to suspend. 
> > > 
> > 
> > I forgot, of course there needs to be another knob to implement the
> > "on" behaviour  in the opportunistic mode
> > 
> >  /sys/power/block_opportunistic_suspend
> > 
> > There you have it. One file, one purpose. 
> 
> That's getting messy IMHO.
> 
> In addition to that you get a nice race when the user writes "mem"
> to /sys/power/state and opportunistic suspend happens at the same time.
> If the latter wins the race, the system will suspend again immediately after
> being woken up, which probably is not the result you'd like to get.

But I don't think there is a problem with that. If the system is
'awake' (suspend blocked) and you hit it with forced 'mem', the system
_has_ to suspend. as that is what forced "mem"  means. And if
opportunistic won the race you would _expect_ the machine to suspend
again after the wakeup (and this time for good).

But perhaps this only makes sense if you can specify different
wake-events for opportunistic and forced suspend.

This is probably some kind of bikeshed by now. I'm alright with the
status quo. For what it's worth (not much): You can add my Reviewed-By.

Cheers,
Flo

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> > > > Yeah, one file selects behavior of another file, and to read available
> > > > states for opportunistic, you have to write to file first.
> > > > 
> > > > I still don't like the interface.
> > > > 
> > > 
> > > Actually, what would be a better interface? 
> > > 
> > > I wonder why it is not like this:
> 
> Because I think the "forced" and "opportunistic" suspend "modes" are mutually
> exclusive in practice and the interface as proposed reflects that quite well.

Why should they be? Forced disk while opportunistic mem is active
makes a lot of sense. If code can't support it now, just return
-EINVAL, but please don't cripple the interface just because of that.

> > > /sys/power/state 
> > > 	no change, works with and without opportunistic suspend the
> > > 	same. Ignores suspend blockers. Really no change. (From user
> > > 	perspective)
> > > 
> > > /sys/power/opportunistic
> > > 	On / Off
> > > 	While Off the opportunistic suspend is off.
> > > 	While On, the opportunistic suspend is on and if there are no
> > > 	suspend blockers the system goes to suspend. 
> > > 
> > 
> > I forgot, of course there needs to be another knob to implement the
> > "on" behaviour  in the opportunistic mode
> > 
> >  /sys/power/block_opportunistic_suspend
> > 
> > There you have it. One file, one purpose. 
> 
> That's getting messy IMHO.
> 
> In addition to that you get a nice race when the user writes "mem"
> to /sys/power/state and opportunistic suspend happens at the same
> time.

It should not opportunistically suspend when it has work to do (like
entering forced suspend).
									Pavel

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

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Friday 14 May 2010, Arve Hjønnevåg wrote:
> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version has some
> changes from, or requested by, Rafael. The most notable changes are:
> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>   for statically allocated suspend blockers. 
> - suspend_blocker_destroy is now called suspend_blocker_unregister
> - The user space mandatory _INIT ioctl has been replaced with an
>   optional _SET_NAME ioctl.
> 
> I kept the ack and reviewed by tags on two of the patches even though
> there were a few cosmetic changes.

Thanks for the patches, I think they are in a pretty good shape now.

That said, I'd like the changelogs to be a bit more descriptive, at least for
patch [1/8].  I think it should explain (in a few words) what the purpose of
the feature is and what problems it solves that generally a combination of
runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
think we need that feature.

The changelog of patch [2/8] appears to be outdated, that needs to be fixed.
Also, it would be nice to explain in the changelog what the interface is needed
for (in terms of the problems that it helps to handle).

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

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Friday 14 May 2010, Arve Hjønnevåg wrote:
> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version has some
> changes from, or requested by, Rafael. The most notable changes are:
> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>   for statically allocated suspend blockers. 
> - suspend_blocker_destroy is now called suspend_blocker_unregister
> - The user space mandatory _INIT ioctl has been replaced with an
>   optional _SET_NAME ioctl.
> 
> I kept the ack and reviewed by tags on two of the patches even though
> there were a few cosmetic changes.

I have one more comment, sorry for that.

Namely, if /sys/power/policy is set to "opportunistic" and "mem" is written
into /sys/power/state and there are no suspend blockers present except for
the main blocker (and the blockers used only for statistics), the system won't
be able to go out of an infinit suspend-resume loop (or at least it seems
so from reading the code).

I think we should prevent that from happening somehow.

Thanks,
Rafael


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

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> This patch series adds a suspend-block api that provides the same
>> functionality as the android wakelock api. This version has some
>> changes from, or requested by, Rafael. The most notable changes are:
>> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>>   for statically allocated suspend blockers.
>> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> - The user space mandatory _INIT ioctl has been replaced with an
>>   optional _SET_NAME ioctl.
>>
>> I kept the ack and reviewed by tags on two of the patches even though
>> there were a few cosmetic changes.
>
> I have one more comment, sorry for that.
>
> Namely, if /sys/power/policy is set to "opportunistic" and "mem" is written
> into /sys/power/state and there are no suspend blockers present except for
> the main blocker (and the blockers used only for statistics), the system won't
> be able to go out of an infinit suspend-resume loop (or at least it seems
> so from reading the code).
>
> I think we should prevent that from happening somehow.
>

It should get out of that loop as soon as someone blocks suspend. If
someone is constantly aborting suspend without using a suspend blocker
it will be very inefficient, but it should still work.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Monday 17 May 2010, Arve Hjønnevåg wrote:
> 2010/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version has some
> >> changes from, or requested by, Rafael. The most notable changes are:
> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >>   for statically allocated suspend blockers.
> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> - The user space mandatory _INIT ioctl has been replaced with an
> >>   optional _SET_NAME ioctl.
> >>
> >> I kept the ack and reviewed by tags on two of the patches even though
> >> there were a few cosmetic changes.
> >
> > I have one more comment, sorry for that.
> >
> > Namely, if /sys/power/policy is set to "opportunistic" and "mem" is written
> > into /sys/power/state and there are no suspend blockers present except for
> > the main blocker (and the blockers used only for statistics), the system won't
> > be able to go out of an infinit suspend-resume loop (or at least it seems
> > so from reading the code).
> >
> > I think we should prevent that from happening somehow.
> >
> 
> It should get out of that loop as soon as someone blocks suspend. If
> someone is constantly aborting suspend without using a suspend blocker
> it will be very inefficient, but it should still work.

Well, the scenario I have in mind is the following.  Someone wants to check
the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
/sys/power/state without any drivers or apps that use suspend blockers.

How in that case is the system supposed to break out of the suspend-resume loop
resulting from this?  I don't see right now, because the main blocker is
inactive, there are no other blockers that can be activated and it is next to
impossible to write to /sys/power/state again.

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Brian Swetland]

On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday 17 May 2010, Arve Hjønnevåg wrote:
>>
>> It should get out of that loop as soon as someone blocks suspend. If
>> someone is constantly aborting suspend without using a suspend blocker
>> it will be very inefficient, but it should still work.
>
> Well, the scenario I have in mind is the following.  Someone wants to check
> the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
> /sys/power/state without any drivers or apps that use suspend blockers.
>
> How in that case is the system supposed to break out of the suspend-resume loop
> resulting from this?  I don't see right now, because the main blocker is
> inactive, there are no other blockers that can be activated and it is next to
> impossible to write to /sys/power/state again.

I guess we could set a flag when a suspend blocker is registered and
refuse to enter opportunistic mode if no blockers have ever been
registered.

It does seem like extra effort to go through to handle a "don't do
that" type scenario (entering into opportunistic suspend without
anything that will prevent it).

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

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Monday 17 May 2010, Brian Swetland wrote:
> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >>
> >> It should get out of that loop as soon as someone blocks suspend. If
> >> someone is constantly aborting suspend without using a suspend blocker
> >> it will be very inefficient, but it should still work.
> >
> > Well, the scenario I have in mind is the following.  Someone wants to check
> > the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
> > /sys/power/state without any drivers or apps that use suspend blockers.
> >
> > How in that case is the system supposed to break out of the suspend-resume loop
> > resulting from this?  I don't see right now, because the main blocker is
> > inactive, there are no other blockers that can be activated and it is next to
> > impossible to write to /sys/power/state again.
> 
> I guess we could set a flag when a suspend blocker is registered and
> refuse to enter opportunistic mode if no blockers have ever been
> registered.
> 
> It does seem like extra effort to go through to handle a "don't do
> that" type scenario (entering into opportunistic suspend without
> anything that will prevent it).

I agree, but I think it's necessary.  We shouldn't add interfaces that hurt
users if not used with care.

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

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday 17 May 2010, Brian Swetland wrote:
>> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >>
>> >> It should get out of that loop as soon as someone blocks suspend. If
>> >> someone is constantly aborting suspend without using a suspend blocker
>> >> it will be very inefficient, but it should still work.
>> >
>> > Well, the scenario I have in mind is the following.  Someone wants to check
>> > the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
>> > /sys/power/state without any drivers or apps that use suspend blockers.
>> >
>> > How in that case is the system supposed to break out of the suspend-resume loop
>> > resulting from this?  I don't see right now, because the main blocker is
>> > inactive, there are no other blockers that can be activated and it is next to
>> > impossible to write to /sys/power/state again.
>>
>> I guess we could set a flag when a suspend blocker is registered and
>> refuse to enter opportunistic mode if no blockers have ever been
>> registered.
>>
>> It does seem like extra effort to go through to handle a "don't do
>> that" type scenario (entering into opportunistic suspend without
>> anything that will prevent it).
>
> I agree, but I think it's necessary.  We shouldn't add interfaces that hurt
> users if not used with care.
>

I'm not sure this can be "fixed". The user asked that the system to
suspend whenever possible, which is what it is doing. I don't think
disabling opportunistic suspend if no suspend blockers have been
registered will work. As soon as we register a suspend blocker we are
back in the same situation.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday 17 May 2010, Brian Swetland wrote:
> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >>
> >> >> It should get out of that loop as soon as someone blocks suspend. If
> >> >> someone is constantly aborting suspend without using a suspend blocker
> >> >> it will be very inefficient, but it should still work.
> >> >
> >> > Well, the scenario I have in mind is the following.  Someone wants to check
> >> > the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
> >> > /sys/power/state without any drivers or apps that use suspend blockers.
> >> >
> >> > How in that case is the system supposed to break out of the suspend-resume loop
> >> > resulting from this?  I don't see right now, because the main blocker is
> >> > inactive, there are no other blockers that can be activated and it is next to
> >> > impossible to write to /sys/power/state again.
> >>
> >> I guess we could set a flag when a suspend blocker is registered and
> >> refuse to enter opportunistic mode if no blockers have ever been
> >> registered.
> >>
> >> It does seem like extra effort to go through to handle a "don't do
> >> that" type scenario (entering into opportunistic suspend without
> >> anything that will prevent it).
> >
> > I agree, but I think it's necessary.  We shouldn't add interfaces that hurt
> > users if not used with care.
> >
> 
> I'm not sure this can be "fixed".

Yes, it can, but perhaps a workaround would be sufficient (see below).

> The user asked that the system to suspend whenever possible, which is what it
> is doing. I don't think disabling opportunistic suspend if no suspend
> blockers have been registered will work. As soon as we register a suspend
> blocker we are back in the same situation.

Not really, because the new suspend blocker is not added by the _framework_ _itself_.

Now, to make it more "user-friendly", we can simply use
queue_delayed_work() with a reasonable delay instead of queue_work() to queue
the suspend work (the delay may be configurable via sysfs).

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Monday 17 May 2010, Brian Swetland wrote:
>> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >>
>> >> >> It should get out of that loop as soon as someone blocks suspend. If
>> >> >> someone is constantly aborting suspend without using a suspend blocker
>> >> >> it will be very inefficient, but it should still work.
>> >> >
>> >> > Well, the scenario I have in mind is the following.  Someone wants to check
>> >> > the feature and simply writes "opportunistic" to /sys/power/policy and "mem" to
>> >> > /sys/power/state without any drivers or apps that use suspend blockers.
>> >> >
>> >> > How in that case is the system supposed to break out of the suspend-resume loop
>> >> > resulting from this?  I don't see right now, because the main blocker is
>> >> > inactive, there are no other blockers that can be activated and it is next to
>> >> > impossible to write to /sys/power/state again.
>> >>
>> >> I guess we could set a flag when a suspend blocker is registered and
>> >> refuse to enter opportunistic mode if no blockers have ever been
>> >> registered.
>> >>
>> >> It does seem like extra effort to go through to handle a "don't do
>> >> that" type scenario (entering into opportunistic suspend without
>> >> anything that will prevent it).
>> >
>> > I agree, but I think it's necessary.  We shouldn't add interfaces that hurt
>> > users if not used with care.
>> >
>>
>> I'm not sure this can be "fixed".
>
> Yes, it can, but perhaps a workaround would be sufficient (see below).
>
>> The user asked that the system to suspend whenever possible, which is what it
>> is doing. I don't think disabling opportunistic suspend if no suspend
>> blockers have been registered will work. As soon as we register a suspend
>> blocker we are back in the same situation.
>
> Not really, because the new suspend blocker is not added by the _framework_ _itself_.
>

I'm not sure what you mean by this. If we add a workaround that is
disabled when the first suspend blocker is registered, then we cannot
add any suspend blockers without disabling the workaround (for
instance the power supply framework patch later in this patch set).

> Now, to make it more "user-friendly", we can simply use
> queue_delayed_work() with a reasonable delay instead of queue_work() to queue
> the suspend work (the delay may be configurable via sysfs).
>

I can add a delay (and the timeout support code does add a delay as an
optimization) to the unknown wakeup case, but this does not fix the
problem of a user turning on opportunistic suspend with a user space
framework that does not use suspend blockers. If the kernel uses
suspend blockers to make sure the wakeup event makes it to user space,
but user space does not block suspend, then the system will suspend
before the event is processed.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > On Monday 17 May 2010, Brian Swetland wrote:
> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >>
...
> 
> > Now, to make it more "user-friendly", we can simply use
> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
> > the suspend work (the delay may be configurable via sysfs).
> >
> 
> I can add a delay (and the timeout support code does add a delay as an
> optimization) to the unknown wakeup case, but this does not fix the
> problem of a user turning on opportunistic suspend with a user space
> framework that does not use suspend blockers. If the kernel uses
> suspend blockers to make sure the wakeup event makes it to user space,
> but user space does not block suspend, then the system will suspend
> before the event is processed.

But the user can still manually write to /sys/power/state. :-)

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> > On Monday 17 May 2010, Brian Swetland wrote:
>> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >>
> ...
>>
>> > Now, to make it more "user-friendly", we can simply use
>> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
>> > the suspend work (the delay may be configurable via sysfs).
>> >
>>
>> I can add a delay (and the timeout support code does add a delay as an
>> optimization) to the unknown wakeup case, but this does not fix the
>> problem of a user turning on opportunistic suspend with a user space
>> framework that does not use suspend blockers. If the kernel uses
>> suspend blockers to make sure the wakeup event makes it to user space,
>> but user space does not block suspend, then the system will suspend
>> before the event is processed.
>
> But the user can still manually write to /sys/power/state. :-)
>

Does adding or removing a delay change this? It seems in only changes
how quickly the user can finish that write.

I'm not convinced adding a configurable delay here is necessary. Once
the driver that enabled the wakeup event has been updated to block
suspend until this event gets to user space, then this delay will
never be triggered. The kernel cannot tell the difference between a
user enabling opportunistic suspend but not wanting it and
opportunistic suspend aware user space code deciding that this wakeup
event should be ignored.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> > On Monday 17 May 2010, Brian Swetland wrote:
> >> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >>
> > ...
> >>
> >> > Now, to make it more "user-friendly", we can simply use
> >> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
> >> > the suspend work (the delay may be configurable via sysfs).
> >> >
> >>
> >> I can add a delay (and the timeout support code does add a delay as an
> >> optimization) to the unknown wakeup case, but this does not fix the
> >> problem of a user turning on opportunistic suspend with a user space
> >> framework that does not use suspend blockers. If the kernel uses
> >> suspend blockers to make sure the wakeup event makes it to user space,
> >> but user space does not block suspend, then the system will suspend
> >> before the event is processed.
> >
> > But the user can still manually write to /sys/power/state. :-)
> >
> 
> Does adding or removing a delay change this? It seems in only changes
> how quickly the user can finish that write.

Yes, but that should allow the user to avoid rebooting the system if he does
the "wrong thing".

> I'm not convinced adding a configurable delay here is necessary.

No, it's not, but it would be useful in some cases IMO.  Pretty much the same
way your debug features are useful.

> Once the driver that enabled the wakeup event has been updated to block
> suspend until this event gets to user space, then this delay will
> never be triggered. The kernel cannot tell the difference between a
> user enabling opportunistic suspend but not wanting it and
> opportunistic suspend aware user space code deciding that this wakeup
> event should be ignored.

The point is, if there's a delay, it may be too aggressive for some users and
too conservative for some other users, so it makes sense to provide a means
to adjust it to the user's needs.

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> >> > On Monday 17 May 2010, Brian Swetland wrote:
>> >> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >>
>> > ...
>> >>
>> >> > Now, to make it more "user-friendly", we can simply use
>> >> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
>> >> > the suspend work (the delay may be configurable via sysfs).
>> >> >
>> >>
>> >> I can add a delay (and the timeout support code does add a delay as an
>> >> optimization) to the unknown wakeup case, but this does not fix the
>> >> problem of a user turning on opportunistic suspend with a user space
>> >> framework that does not use suspend blockers. If the kernel uses
>> >> suspend blockers to make sure the wakeup event makes it to user space,
>> >> but user space does not block suspend, then the system will suspend
>> >> before the event is processed.
>> >
>> > But the user can still manually write to /sys/power/state. :-)
>> >
>>
>> Does adding or removing a delay change this? It seems in only changes
>> how quickly the user can finish that write.
>
> Yes, but that should allow the user to avoid rebooting the system if he does
> the "wrong thing".
>
>> I'm not convinced adding a configurable delay here is necessary.
>
> No, it's not, but it would be useful in some cases IMO.  Pretty much the same
> way your debug features are useful.
>
>> Once the driver that enabled the wakeup event has been updated to block
>> suspend until this event gets to user space, then this delay will
>> never be triggered. The kernel cannot tell the difference between a
>> user enabling opportunistic suspend but not wanting it and
>> opportunistic suspend aware user space code deciding that this wakeup
>> event should be ignored.
>
> The point is, if there's a delay, it may be too aggressive for some users and
> too conservative for some other users, so it makes sense to provide a means
> to adjust it to the user's needs.
>

My point is that the delay will not be used at all if the driver uses
a suspend blocker (like it should). Why add a configuration option for
opportunistic suspend that only works when the driver does not support
opportunistic suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> >> > On Monday 17 May 2010, Brian Swetland wrote:
> >> >> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> >>
> >> > ...
> >> >>
> >> >> > Now, to make it more "user-friendly", we can simply use
> >> >> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
> >> >> > the suspend work (the delay may be configurable via sysfs).
> >> >> >
> >> >>
> >> >> I can add a delay (and the timeout support code does add a delay as an
> >> >> optimization) to the unknown wakeup case, but this does not fix the
> >> >> problem of a user turning on opportunistic suspend with a user space
> >> >> framework that does not use suspend blockers. If the kernel uses
> >> >> suspend blockers to make sure the wakeup event makes it to user space,
> >> >> but user space does not block suspend, then the system will suspend
> >> >> before the event is processed.
> >> >
> >> > But the user can still manually write to /sys/power/state. :-)
> >> >
> >>
> >> Does adding or removing a delay change this? It seems in only changes
> >> how quickly the user can finish that write.
> >
> > Yes, but that should allow the user to avoid rebooting the system if he does
> > the "wrong thing".
> >
> >> I'm not convinced adding a configurable delay here is necessary.
> >
> > No, it's not, but it would be useful in some cases IMO.  Pretty much the same
> > way your debug features are useful.
> >
> >> Once the driver that enabled the wakeup event has been updated to block
> >> suspend until this event gets to user space, then this delay will
> >> never be triggered. The kernel cannot tell the difference between a
> >> user enabling opportunistic suspend but not wanting it and
> >> opportunistic suspend aware user space code deciding that this wakeup
> >> event should be ignored.
> >
> > The point is, if there's a delay, it may be too aggressive for some users and
> > too conservative for some other users, so it makes sense to provide a means
> > to adjust it to the user's needs.
> >
> 
> My point is that the delay will not be used at all if the driver uses
> a suspend blocker (like it should). Why add a configuration option for
> opportunistic suspend that only works when the driver does not support
> opportunistic suspend.

Because on many systems there are no such drivers (yet, at least).

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> This patch series adds a suspend-block api that provides the same
>> functionality as the android wakelock api. This version has some
>> changes from, or requested by, Rafael. The most notable changes are:
>> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>>   for statically allocated suspend blockers.
>> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> - The user space mandatory _INIT ioctl has been replaced with an
>>   optional _SET_NAME ioctl.
>>
>> I kept the ack and reviewed by tags on two of the patches even though
>> there were a few cosmetic changes.
>
> Thanks for the patches, I think they are in a pretty good shape now.
>
> That said, I'd like the changelogs to be a bit more descriptive, at least for
> patch [1/8].  I think it should explain (in a few words) what the purpose of
> the feature is and what problems it solves that generally a combination of
> runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> think we need that feature.
>

How about:

PM: Add opportunistic suspend support.

Adds a suspend block api that drivers can use to block opportunistic
suspend. This is needed to avoid losing wakeup events that occur
right after suspend is initiated.

Adds /sys/power/policy that selects the behaviour of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Opportunistic suspend is most useful on systems that cannot enter their
lowest power state from idle, but it is also useful on systems that enter
the same power state from idle and suspend. Periodic timers can cause
a significant power drain on these systems, and suspend will stop most
of this. Opportunistic suspend can also reduce the harm caused by apps
that never go idle.

> The changelog of patch [2/8] appears to be outdated, that needs to be fixed.
> Also, it would be nice to explain in the changelog what the interface is needed
> for (in terms of the problems that it helps to handle).
>

How about:

PM: suspend_block: Add driver to access suspend blockers from user-space

Add a misc device, "suspend_blocker", that allows user-space processes
to block auto suspend. Opening this device creates a suspend_blocker.
ioctls are provided to name this suspend_blocker, and to block and unblock
suspend. To delete the suspend_blocker, close the device.

For example, when select or poll indicates that input event are available, this
interface can be used to block suspend before reading those event. This allows
the input driver to release its suspend blocker as soon as the event queue is
empty.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Mike Snitzer]

2010/5/17 Arve Hjønnevåg <arve@android.com>:
> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> On Friday 14 May 2010, Arve Hjønnevåg wrote:
>>> This patch series adds a suspend-block api that provides the same
>>> functionality as the android wakelock api. This version has some
>>> changes from, or requested by, Rafael. The most notable changes are:
>>> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>>>   for statically allocated suspend blockers.
>>> - suspend_blocker_destroy is now called suspend_blocker_unregister
>>> - The user space mandatory _INIT ioctl has been replaced with an
>>>   optional _SET_NAME ioctl.
>>>
>>> I kept the ack and reviewed by tags on two of the patches even though
>>> there were a few cosmetic changes.
>>
>> Thanks for the patches, I think they are in a pretty good shape now.
>>
>> That said, I'd like the changelogs to be a bit more descriptive, at least for
>> patch [1/8].  I think it should explain (in a few words) what the purpose of
>> the feature is and what problems it solves that generally a combination of
>> runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> think we need that feature.
>>
>
> How about:
>
> PM: Add opportunistic suspend support.
>
> Adds a suspend block api

In the future I think it'd be ideal if you were to always use "suspend
blocker" (rather than "suspend block").

This work has nothing to do with the block layer yet by the subject I
thought it somehow did.

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Monday 17 May 2010, Arve Hjønnevåg wrote:
> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version has some
> >> changes from, or requested by, Rafael. The most notable changes are:
> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >>   for statically allocated suspend blockers.
> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> - The user space mandatory _INIT ioctl has been replaced with an
> >>   optional _SET_NAME ioctl.
> >>
> >> I kept the ack and reviewed by tags on two of the patches even though
> >> there were a few cosmetic changes.
> >
> > Thanks for the patches, I think they are in a pretty good shape now.
> >
> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> > the feature is and what problems it solves that generally a combination of
> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> > think we need that feature.
> >
> 
> How about:
> 
> PM: Add opportunistic suspend support.

"PM: Opportunistic suspend support" would be sufficient IMO.

Now, I'd start with the motivation.  Like "Power management features present
in the current mainline kernel are insufficient to get maximum possible energy
savings on some platforms, such as Android, because ..." (here go explanations
why this is the case in your opinion).

Next, "To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, introduce a mechanism by which
the system is automatically suspended (i.e. put into a system-wide sleep state)
whenever it's not doing useful work, called opportunistic suspend".

"For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to suspend
the system (i.e. when useful work is not being done).  Add an API that ..."

> Adds a suspend block api that drivers can use to block opportunistic
> suspend. This is needed to avoid losing wakeup events that occur
> right after suspend is initiated.
>
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Opportunistic suspend is most useful on systems that cannot enter their
> lowest power state from idle, but it is also useful on systems that enter
> the same power state from idle and suspend. Periodic timers can cause
> a significant power drain on these systems, and suspend will stop most
> of this. Opportunistic suspend can also reduce the harm caused by apps
> that never go idle.
> 
> > The changelog of patch [2/8] appears to be outdated, that needs to be fixed.
> > Also, it would be nice to explain in the changelog what the interface is needed
> > for (in terms of the problems that it helps to handle).
> >
> 
> How about:
> 
> PM: suspend_block: Add driver to access suspend blockers from user-space
> 
> Add a misc device, "suspend_blocker", that allows user-space processes
> to block auto suspend.

"automatic suspend" would be better IMO.

> Opening this device creates a suspend_blocker.

"suspend blocker that can be used by the opener to prevent automatic suspend
from occuring.  There are ioctls provided for blocking and unblocking suspend
and for giving the suspend blocker a meaningful name.  Closing the device
special file causes the suspend blocker to be destroyed."

> ioctls are provided to name this suspend_blocker, and to block and unblock
> suspend. To delete the suspend_blocker, close the device.
> 
> For example, when select or poll indicates that input event are available, this
> interface can be used to block suspend before reading those event. This allows
> the input driver to release its suspend blocker as soon as the event queue is
> empty.

I think you should explain in more detail how suspend blockers used by user
space make that possible.

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Monday 17 May 2010, Arve Hjønnevåg wrote:

>> 
>> How about:
>> 
>> PM: Add opportunistic suspend support.
>
> "PM: Opportunistic suspend support" would be sufficient IMO.
>
> Now, I'd start with the motivation.  Like "Power management features present
> in the current mainline kernel are insufficient to get maximum possible energy
> savings on some platforms, such as Android, because ..." (here go explanations
> why this is the case in your opinion).

Yes, this will be helpful.

> Next, "To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, introduce a mechanism by which
> the system is automatically suspended (i.e. put into a system-wide sleep state)
> whenever it's not doing useful work, called opportunistic suspend".

Hopefully, a definition of "useful" will be given here, including by
what standards on-going work is determined not to be useful.

Kevin

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> This patch series adds a suspend-block api that provides the same
>> >> functionality as the android wakelock api. This version has some
>> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >>   for statically allocated suspend blockers.
>> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >>   optional _SET_NAME ioctl.
>> >>
>> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> there were a few cosmetic changes.
>> >
>> > Thanks for the patches, I think they are in a pretty good shape now.
>> >
>> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> > the feature is and what problems it solves that generally a combination of
>> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> > think we need that feature.
>> >
>>
>> How about:
>>
>> PM: Add opportunistic suspend support.
>
> "PM: Opportunistic suspend support" would be sufficient IMO.
>
> Now, I'd start with the motivation.  Like "Power management features present
> in the current mainline kernel are insufficient to get maximum possible energy
> savings on some platforms, such as Android, because ..." (here go explanations
> why this is the case in your opinion).
>
> Next, "To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, introduce a mechanism by which
> the system is automatically suspended (i.e. put into a system-wide sleep state)
> whenever it's not doing useful work, called opportunistic suspend".
>
> "For this purpose introduce the suspend blockers framework allowing the
> kernel's power management subsystem to decide when it is desirable to suspend
> the system (i.e. when useful work is not being done).  Add an API that ..."
>

PM: Opportunistic suspend support.

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android, because low power states can only safely be entered
from idle. Suspend, in its current form, cannot be used, since wakeup
events that occur right after initiating suspend will not be processed
until another possibly unrelated event wake up the system again.

On some systems idle combined with runtime PM can enter the same power
state as suspend, but periodic wakeups increase the average power
consumption. Suspending the system also reduces the harm caused by
apps that never go idle. On other systems suspend can enter a much
lower power state than idle.

To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, we introduce a mechanism
by which the system is automatically suspended (i.e. put into a
system-wide sleep state) whenever it's not doing useful work, called
opportunistic suspend.

For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to
suspend the system (i.e. when useful work is not being done). Add an
API that that drivers can use to block opportunistic suspend. This is
needed to avoid losing wakeup events that occur right after suspend is
initiated.

Adds /sys/power/policy that selects the behavior of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.


>> Adds a suspend block api that drivers can use to block opportunistic
>> suspend. This is needed to avoid losing wakeup events that occur
>> right after suspend is initiated.
>>
>> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
>> After setting the policy to opportunistic, writes to /sys/power/state
>> become non-blocking requests that specify which suspend state to enter
>> when no suspend blockers are active. A special state, "on", stops the
>> process by activating the "main" suspend blocker.
>>
>> Opportunistic suspend is most useful on systems that cannot enter their
>> lowest power state from idle, but it is also useful on systems that enter
>> the same power state from idle and suspend. Periodic timers can cause
>> a significant power drain on these systems, and suspend will stop most
>> of this. Opportunistic suspend can also reduce the harm caused by apps
>> that never go idle.
>>
>> > The changelog of patch [2/8] appears to be outdated, that needs to be fixed.
>> > Also, it would be nice to explain in the changelog what the interface is needed
>> > for (in terms of the problems that it helps to handle).
>> >
>>
>> How about:
>>
>> PM: suspend_block: Add driver to access suspend blockers from user-space
>>
>> Add a misc device, "suspend_blocker", that allows user-space processes
>> to block auto suspend.
>
> "automatic suspend" would be better IMO.
>
>> Opening this device creates a suspend_blocker.
>
> "suspend blocker that can be used by the opener to prevent automatic suspend
> from occuring.  There are ioctls provided for blocking and unblocking suspend
> and for giving the suspend blocker a meaningful name.  Closing the device
> special file causes the suspend blocker to be destroyed."
>
>> ioctls are provided to name this suspend_blocker, and to block and unblock
>> suspend. To delete the suspend_blocker, close the device.
>>
>> For example, when select or poll indicates that input event are available, this
>> interface can be used to block suspend before reading those event. This allows
>> the input driver to release its suspend blocker as soon as the event queue is
>> empty.
>
> I think you should explain in more detail how suspend blockers used by user
> space make that possible.
>


PM: suspend_block: Add driver to access suspend blockers from user-space

Add a misc device, "suspend_blocker", that allows user-space processes
to block automatic suspend.

Opening this device creates a suspend blocker that can be used by the
opener to prevent automatic suspend from occurring.  There are ioctls
provided for blocking and unblocking suspend and for giving the
suspend blocker a meaningful name.  Closing the device special file
causes the suspend blocker to be destroyed.

For example, when select or poll indicates that input event are
available, this interface can be used by user space to block suspend
before it reads those events. This allows the input driver to release
its suspend blocker as soon as the event queue is empty. If user space
could not use a suspend blocker here the input driver would need to
delay the release of its suspend blocker until it knows (or assumes)
that user space has finished processing the events.

By careful use of suspend blockers in drivers and user space system
code, one can arrange for the system to stay awake for extremely short
periods of time in reaction to events, rapidly returning to a fully
suspended state.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Kevin Hilman]

Arve Hjønnevåg <arve@android.com> writes:

>
> PM: Opportunistic suspend support.
>
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android, because low power states can only safely be entered
> from idle.  Suspend, in its current form, cannot be used, since wakeup
> events that occur right after initiating suspend will not be processed
> until another possibly unrelated event wake up the system again.

I think the problems with wakeups in the current suspend path need to
be described in more detail.  In particular, why check_wakeup_irqs()
is not enough etc.

> On some systems idle combined with runtime PM can enter the same power
> state as suspend, but periodic wakeups increase the average power
> consumption. Suspending the system also reduces the harm caused by
> apps that never go idle. On other systems suspend can enter a much
> lower power state than idle.
>
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, we introduce a mechanism
> by which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing useful work, called
> opportunistic suspend.

A definition of "useful work" here would provide clarity and would
also help clarify by what criteria other on-going work is determined
to be not useful.

Kevin

Re: [PATCH 0/8] Suspend block api (version 7)

[Kevin Hilman]

Arve Hjønnevåg <arve@android.com> writes:

>
> PM: Opportunistic suspend support.
>
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android, because low power states can only safely be entered
> from idle.  Suspend, in its current form, cannot be used, since wakeup
> events that occur right after initiating suspend will not be processed
> until another possibly unrelated event wake up the system again.

I think the problems with wakeups in the current suspend path need to
be described in more detail.  In particular, why check_wakeup_irqs()
is not enough etc.

> On some systems idle combined with runtime PM can enter the same power
> state as suspend, but periodic wakeups increase the average power
> consumption. Suspending the system also reduces the harm caused by
> apps that never go idle. On other systems suspend can enter a much
> lower power state than idle.
>
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, we introduce a mechanism
> by which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing useful work, called
> opportunistic suspend.

A definition of "useful work" here would provide clarity and would
also help clarify by what criteria other on-going work is determined
to be not useful.

Kevin

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Kevin Hilman wrote:
> Arve Hjønnevåg <arve@android.com> writes:
> 
> >
> > PM: Opportunistic suspend support.
> >
> > Power management features present in the current mainline kernel are
> > insufficient to get maximum possible energy savings on some platforms,
> > such as Android, because low power states can only safely be entered
> > from idle.  Suspend, in its current form, cannot be used, since wakeup
> > events that occur right after initiating suspend will not be processed
> > until another possibly unrelated event wake up the system again.
> 
> I think the problems with wakeups in the current suspend path need to
> be described in more detail.  In particular, why check_wakeup_irqs()
> is not enough etc.

That one is really easy.: because some (the majority of?) architectures
don't even implement it.
 
> > On some systems idle combined with runtime PM can enter the same power
> > state as suspend, but periodic wakeups increase the average power
> > consumption. Suspending the system also reduces the harm caused by
> > apps that never go idle. On other systems suspend can enter a much
> > lower power state than idle.
> >
> > To allow Android and similar platforms to save more energy than they
> > currently can save using the mainline kernel, we introduce a mechanism
> > by which the system is automatically suspended (i.e. put into a
> > system-wide sleep state) whenever it's not doing useful work, called
> > opportunistic suspend.
> 
> A definition of "useful work" here would provide clarity and would
> also help clarify by what criteria other on-going work is determined
> to be not useful.

Probably "useful" is not the right word here.  I guess it's more like
"work that can be deferred without visible impact on functionality".

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Tuesday 18 May 2010, Kevin Hilman wrote:
>> Arve Hjønnevåg <arve@android.com> writes:
>> 
>> >
>> > PM: Opportunistic suspend support.
>> >
>> > Power management features present in the current mainline kernel are
>> > insufficient to get maximum possible energy savings on some platforms,
>> > such as Android, because low power states can only safely be entered
>> > from idle.  Suspend, in its current form, cannot be used, since wakeup
>> > events that occur right after initiating suspend will not be processed
>> > until another possibly unrelated event wake up the system again.
>> 
>> I think the problems with wakeups in the current suspend path need to
>> be described in more detail.  In particular, why check_wakeup_irqs()
>> is not enough etc.
>
> That one is really easy.: because some (the majority of?) architectures
> don't even implement it.

OK, then this problem will still in traditional suspend even after
this series, so calling it out as a the problem to be solved but not
fixing it doesn't seem right.

This problem needs an independent fix, namely implementing
check_wakeup_irqs().

That being said, what exactly is there for architectures to implement
for check_wakeup_irqs()?  IIUC, this all handled by genirq as long as
deferred disable (now the default) is used?

I suspect the platforms that Android currently cares about already
have this functionality.  At least OMAP does already.

>> > On some systems idle combined with runtime PM can enter the same power
>> > state as suspend, but periodic wakeups increase the average power
>> > consumption. Suspending the system also reduces the harm caused by
>> > apps that never go idle. On other systems suspend can enter a much
>> > lower power state than idle.
>> >
>> > To allow Android and similar platforms to save more energy than they
>> > currently can save using the mainline kernel, we introduce a mechanism
>> > by which the system is automatically suspended (i.e. put into a
>> > system-wide sleep state) whenever it's not doing useful work, called
>> > opportunistic suspend.
>> 
>> A definition of "useful work" here would provide clarity and would
>> also help clarify by what criteria other on-going work is determined
>> to be not useful.
>
> Probably "useful" is not the right word here.  I guess it's more like
> "work that can be deferred without visible impact on functionality".

OK, then a definition of "visible impact on functionality" should be
provided and the critera for determining that.

I know this sounds like splitting hairs, but what I'm getting at is
that this series implements a brand new method for making decisions
about when the system is idle.  That fact should be clearly stated and
the criteria for making this decision should be clearly described.

Kevin

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Tuesday 18 May 2010, Kevin Hilman wrote:
> >> Arve Hjønnevåg <arve@android.com> writes:
> >> 
> >> >
> >> > PM: Opportunistic suspend support.
> >> >
> >> > Power management features present in the current mainline kernel are
> >> > insufficient to get maximum possible energy savings on some platforms,
> >> > such as Android, because low power states can only safely be entered
> >> > from idle.  Suspend, in its current form, cannot be used, since wakeup
> >> > events that occur right after initiating suspend will not be processed
> >> > until another possibly unrelated event wake up the system again.
> >> 
> >> I think the problems with wakeups in the current suspend path need to
> >> be described in more detail.  In particular, why check_wakeup_irqs()
> >> is not enough etc.
> >
> > That one is really easy.: because some (the majority of?) architectures
> > don't even implement it.
> 
> OK, then this problem will still in traditional suspend even after
> this series, so calling it out as a the problem to be solved but not
> fixing it doesn't seem right.
> 
> This problem needs an independent fix, namely implementing
> check_wakeup_irqs().

No, it is not.  There's nothing like wake-up interrupts on (ACPI-based) x86 PCs.
 
> That being said, what exactly is there for architectures to implement
> for check_wakeup_irqs()?  IIUC, this all handled by genirq as long as
> deferred disable (now the default) is used?

No.  Wakeup IRQs cause the system to wake up from sleep states.  On a PC
the only interrupts that can do that are PCIe root port PME interrupts, but
they are not really "device" interrupts (ie. they come from a source that is
different from a device signaling wakeup).

> I suspect the platforms that Android currently cares about already
> have this functionality.  At least OMAP does already.

ISTR there is an x86 Android port, so not all of them.  Although that really
doesn't matter.

> >> > On some systems idle combined with runtime PM can enter the same power
> >> > state as suspend, but periodic wakeups increase the average power
> >> > consumption. Suspending the system also reduces the harm caused by
> >> > apps that never go idle. On other systems suspend can enter a much
> >> > lower power state than idle.
> >> >
> >> > To allow Android and similar platforms to save more energy than they
> >> > currently can save using the mainline kernel, we introduce a mechanism
> >> > by which the system is automatically suspended (i.e. put into a
> >> > system-wide sleep state) whenever it's not doing useful work, called
> >> > opportunistic suspend.
> >> 
> >> A definition of "useful work" here would provide clarity and would
> >> also help clarify by what criteria other on-going work is determined
> >> to be not useful.
> >
> > Probably "useful" is not the right word here.  I guess it's more like
> > "work that can be deferred without visible impact on functionality".
> 
> OK, then a definition of "visible impact on functionality" should be
> provided and the critera for determining that.
> 
> I know this sounds like splitting hairs,

Yes, it does.

> but what I'm getting at is that this series implements a brand new method
> for making decisions about when the system is idle.

Since we are splitting hairs, I'd be rather cautious about the word "idle".
It would be safer to say "when the system is not doing anything the user
really cares about at the moment and therefore it may be suspended".

That actually is the whole point of the patch series.

> That fact should be clearly stated and the criteria for making this decision
> should be clearly described.

Well, suspend blockers are the tool to define the criteria.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Kevin Hilman <khilman@deeprootsystems.com>:
> Arve Hjønnevåg <arve@android.com> writes:
>
>>
>> PM: Opportunistic suspend support.
>>
>> Power management features present in the current mainline kernel are
>> insufficient to get maximum possible energy savings on some platforms,
>> such as Android, because low power states can only safely be entered
>> from idle.  Suspend, in its current form, cannot be used, since wakeup
>> events that occur right after initiating suspend will not be processed
>> until another possibly unrelated event wake up the system again.
>
> I think the problems with wakeups in the current suspend path need to
> be described in more detail.  In particular, why check_wakeup_irqs()
> is not enough etc.
>

check_wakeup_irqs only handles interrupts that occurred after the
interrupt was masked during suspend. If the interrupt occurred before
it was masked, it will not be pending when check_wakeup_irqs is
called.

>> On some systems idle combined with runtime PM can enter the same power
>> state as suspend, but periodic wakeups increase the average power
>> consumption. Suspending the system also reduces the harm caused by
>> apps that never go idle. On other systems suspend can enter a much
>> lower power state than idle.
>>
>> To allow Android and similar platforms to save more energy than they
>> currently can save using the mainline kernel, we introduce a mechanism
>> by which the system is automatically suspended (i.e. put into a
>> system-wide sleep state) whenever it's not doing useful work, called
>> opportunistic suspend.
>
> A definition of "useful work" here would provide clarity and would
> also help clarify by what criteria other on-going work is determined
> to be not useful.
>
> Kevin
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> >> This patch series adds a suspend-block api that provides the same
> >> >> functionality as the android wakelock api. This version has some
> >> >> changes from, or requested by, Rafael. The most notable changes are:
> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >> >>   for statically allocated suspend blockers.
> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> >> - The user space mandatory _INIT ioctl has been replaced with an
> >> >>   optional _SET_NAME ioctl.
> >> >>
> >> >> I kept the ack and reviewed by tags on two of the patches even though
> >> >> there were a few cosmetic changes.
> >> >
> >> > Thanks for the patches, I think they are in a pretty good shape now.
> >> >
> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> >> > the feature is and what problems it solves that generally a combination of
> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> >> > think we need that feature.
> >> >
> >>
> >> How about:
> >>
> >> PM: Add opportunistic suspend support.
> >
> > "PM: Opportunistic suspend support" would be sufficient IMO.
> >
> > Now, I'd start with the motivation.  Like "Power management features present
> > in the current mainline kernel are insufficient to get maximum possible energy
> > savings on some platforms, such as Android, because ..." (here go explanations
> > why this is the case in your opinion).
> >
> > Next, "To allow Android and similar platforms to save more energy than they
> > currently can save using the mainline kernel, introduce a mechanism by which
> > the system is automatically suspended (i.e. put into a system-wide sleep state)
> > whenever it's not doing useful work, called opportunistic suspend".
> >
> > "For this purpose introduce the suspend blockers framework allowing the
> > kernel's power management subsystem to decide when it is desirable to suspend
> > the system (i.e. when useful work is not being done).  Add an API that ..."
> >
> 
> PM: Opportunistic suspend support.
> 
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android, because low power states can only safely be entered
> from idle.

Do you mean CPU low-power states or system low-power states here?

I'd add more details here, because it may not be completely clear to the
(interested) reader why entering these states only from idle affects the
possibility to achieve maximum energy savings.  I _guess_ you mean that
using idle is not sufficient, because there are so many wakeups on the
systems in question that more savings are still possible.  Is that correct?

> Suspend, in its current form, cannot be used, since wakeup
> events that occur right after initiating suspend will not be processed
> until another possibly unrelated event wake up the system again.

I think the word "cannot" is too strong here.  I'd say "not suitable" instead
and I'd say what kind of wakeup events I meant more precisely (there are
events that wake up a CPU from idle and events that wake up the system from
suspend).

> On some systems idle combined with runtime PM can enter the same power
> state as suspend, but periodic wakeups increase the average power
> consumption. Suspending the system also reduces the harm caused by
> apps that never go idle. On other systems suspend can enter a much
> lower power state than idle.
> 
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, we introduce a mechanism

Just "introduce" without "we" works too.

> by which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing useful work, called
> opportunistic suspend.

I think we can address the Kevin's comment about "useful" and say "whenever
it's only doing work that can be done later without noticeable effect on
functionality".

> For this purpose introduce the suspend blockers framework allowing the
> kernel's power management subsystem to decide when it is desirable to
> suspend the system (i.e. when useful work is not being done). Add an

Perhaps remove the part in parens entirely.

> API that that drivers can use to block opportunistic suspend. This is
> needed to avoid losing wakeup events that occur right after suspend is
> initiated.
> 
> Adds /sys/power/policy that selects the behavior of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.

...
 
> PM: suspend_block: Add driver to access suspend blockers from user-space
> 
> Add a misc device, "suspend_blocker", that allows user-space processes
> to block automatic suspend.
> 
> Opening this device creates a suspend blocker that can be used by the
> opener to prevent automatic suspend from occurring.  There are ioctls
> provided for blocking and unblocking suspend and for giving the
> suspend blocker a meaningful name.  Closing the device special file
> causes the suspend blocker to be destroyed.
> 
> For example, when select or poll indicates that input event are
> available, this interface can be used by user space to block suspend
> before it reads those events. This allows the input driver to release
> its suspend blocker as soon as the event queue is empty. If user space
> could not use a suspend blocker here the input driver would need to
> delay the release of its suspend blocker until it knows (or assumes)
> that user space has finished processing the events.
> 
> By careful use of suspend blockers in drivers and user space system
> code, one can arrange for the system to stay awake for extremely short
> periods of time in reaction to events, rapidly returning to a fully
> suspended state.

That's fine by me.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> This patch series adds a suspend-block api that provides the same
>> >> >> functionality as the android wakelock api. This version has some
>> >> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >> >>   for statically allocated suspend blockers.
>> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >> >>   optional _SET_NAME ioctl.
>> >> >>
>> >> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> >> there were a few cosmetic changes.
>> >> >
>> >> > Thanks for the patches, I think they are in a pretty good shape now.
>> >> >
>> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> >> > the feature is and what problems it solves that generally a combination of
>> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> >> > think we need that feature.
>> >> >
>> >>
>> >> How about:
>> >>
>> >> PM: Add opportunistic suspend support.
>> >
>> > "PM: Opportunistic suspend support" would be sufficient IMO.
>> >
>> > Now, I'd start with the motivation.  Like "Power management features present
>> > in the current mainline kernel are insufficient to get maximum possible energy
>> > savings on some platforms, such as Android, because ..." (here go explanations
>> > why this is the case in your opinion).
>> >
>> > Next, "To allow Android and similar platforms to save more energy than they
>> > currently can save using the mainline kernel, introduce a mechanism by which
>> > the system is automatically suspended (i.e. put into a system-wide sleep state)
>> > whenever it's not doing useful work, called opportunistic suspend".
>> >
>> > "For this purpose introduce the suspend blockers framework allowing the
>> > kernel's power management subsystem to decide when it is desirable to suspend
>> > the system (i.e. when useful work is not being done).  Add an API that ..."
>> >
>>
>> PM: Opportunistic suspend support.
>>
>> Power management features present in the current mainline kernel are
>> insufficient to get maximum possible energy savings on some platforms,
>> such as Android, because low power states can only safely be entered
>> from idle.
>
> Do you mean CPU low-power states or system low-power states here?
>
I think either.

> I'd add more details here, because it may not be completely clear to the
> (interested) reader why entering these states only from idle affects the
> possibility to achieve maximum energy savings.  I _guess_ you mean that
> using idle is not sufficient, because there are so many wakeups on the
> systems in question that more savings are still possible.  Is that correct?
>
Yes, is this not what the next paragraph explains?

>> Suspend, in its current form, cannot be used, since wakeup
>> events that occur right after initiating suspend will not be processed
>> until another possibly unrelated event wake up the system again.
>
> I think the word "cannot" is too strong here.  I'd say "not suitable" instead

I don't think it is too strong, but I can change it.

> and I'd say what kind of wakeup events I meant more precisely (there are
> events that wake up a CPU from idle and events that wake up the system from
> suspend).

When I say wakeup events I mean events that do both. Is there another
term for this, or should I just add: "since wakeup events (events that
wake the CPU from idle and the system from suspend)..."

>
>> On some systems idle combined with runtime PM can enter the same power
>> state as suspend, but periodic wakeups increase the average power
>> consumption. Suspending the system also reduces the harm caused by
>> apps that never go idle. On other systems suspend can enter a much
>> lower power state than idle.
>>
>> To allow Android and similar platforms to save more energy than they
>> currently can save using the mainline kernel, we introduce a mechanism
>
> Just "introduce" without "we" works too.
>
>> by which the system is automatically suspended (i.e. put into a
>> system-wide sleep state) whenever it's not doing useful work, called
>> opportunistic suspend.
>
> I think we can address the Kevin's comment about "useful" and say "whenever
> it's only doing work that can be done later without noticeable effect on
> functionality".
>
>> For this purpose introduce the suspend blockers framework allowing the
>> kernel's power management subsystem to decide when it is desirable to
>> suspend the system (i.e. when useful work is not being done). Add an
>
> Perhaps remove the part in parens entirely.
>
>> API that that drivers can use to block opportunistic suspend. This is
>> needed to avoid losing wakeup events that occur right after suspend is
>> initiated.
>>
>> Adds /sys/power/policy that selects the behavior of /sys/power/state.
>> After setting the policy to opportunistic, writes to /sys/power/state
>> become non-blocking requests that specify which suspend state to enter
>> when no suspend blockers are active. A special state, "on", stops the
>> process by activating the "main" suspend blocker.
>
> ...
>
>> PM: suspend_block: Add driver to access suspend blockers from user-space
>>
>> Add a misc device, "suspend_blocker", that allows user-space processes
>> to block automatic suspend.
>>
>> Opening this device creates a suspend blocker that can be used by the
>> opener to prevent automatic suspend from occurring.  There are ioctls
>> provided for blocking and unblocking suspend and for giving the
>> suspend blocker a meaningful name.  Closing the device special file
>> causes the suspend blocker to be destroyed.
>>
>> For example, when select or poll indicates that input event are
>> available, this interface can be used by user space to block suspend
>> before it reads those events. This allows the input driver to release
>> its suspend blocker as soon as the event queue is empty. If user space
>> could not use a suspend blocker here the input driver would need to
>> delay the release of its suspend blocker until it knows (or assumes)
>> that user space has finished processing the events.
>>
>> By careful use of suspend blockers in drivers and user space system
>> code, one can arrange for the system to stay awake for extremely short
>> periods of time in reaction to events, rapidly returning to a fully
>> suspended state.
>
> That's fine by me.
>
> Thanks,
> Rafael
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> >> >> This patch series adds a suspend-block api that provides the same
> >> >> >> functionality as the android wakelock api. This version has some
> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >> >> >>   for statically allocated suspend blockers.
> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
> >> >> >>   optional _SET_NAME ioctl.
> >> >> >>
> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
> >> >> >> there were a few cosmetic changes.
> >> >> >
> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
> >> >> >
> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> >> >> > the feature is and what problems it solves that generally a combination of
> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> >> >> > think we need that feature.
> >> >> >
> >> >>
> >> >> How about:
> >> >>
> >> >> PM: Add opportunistic suspend support.
> >> >
> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
> >> >
> >> > Now, I'd start with the motivation.  Like "Power management features present
> >> > in the current mainline kernel are insufficient to get maximum possible energy
> >> > savings on some platforms, such as Android, because ..." (here go explanations
> >> > why this is the case in your opinion).
> >> >
> >> > Next, "To allow Android and similar platforms to save more energy than they
> >> > currently can save using the mainline kernel, introduce a mechanism by which
> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
> >> > whenever it's not doing useful work, called opportunistic suspend".
> >> >
> >> > "For this purpose introduce the suspend blockers framework allowing the
> >> > kernel's power management subsystem to decide when it is desirable to suspend
> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
> >> >
> >>
> >> PM: Opportunistic suspend support.
> >>
> >> Power management features present in the current mainline kernel are
> >> insufficient to get maximum possible energy savings on some platforms,
> >> such as Android, because low power states can only safely be entered
> >> from idle.
> >
> > Do you mean CPU low-power states or system low-power states here?
> >
> I think either.

The statement is not true for system low-power states (or sleep states),
because generally (ie. on many platforms) they aren't entered from idle.
Suspend is for entering them.

So, there is a difference and the explanation can go like this: "... to achieve
maximum energy savings one has to put all I/O devices and the CPU into
low-power states, but the CPU can only be put into a low-power state from
idle.  This, in turn, means that the CPU leaves the low-power state on
interrupts triggered by periodic timers and user space processes that use
polling.  It turns out, however, that many of these events causing the CPU to
leave the low-power state aren't essential for the desired system functionality
and from the power management point of view it would be better if they didn't
occur".

> > I'd add more details here, because it may not be completely clear to the
> > (interested) reader why entering these states only from idle affects the
> > possibility to achieve maximum energy savings.  I _guess_ you mean that
> > using idle is not sufficient, because there are so many wakeups on the
> > systems in question that more savings are still possible.  Is that correct?
> >
> Yes, is this not what the next paragraph explains?

Well, it doesn't explain that.  It explains why idle + runtime PM is generally
insufficient and is using that as an argument (at least in my view).

> >> Suspend, in its current form, cannot be used, since wakeup
> >> events that occur right after initiating suspend will not be processed
> >> until another possibly unrelated event wake up the system again.
> >
> > I think the word "cannot" is too strong here.  I'd say "not suitable" instead
> 
> I don't think it is too strong, but I can change it.
> 
> > and I'd say what kind of wakeup events I meant more precisely (there are
> > events that wake up a CPU from idle and events that wake up the system from
> > suspend).
> 
> When I say wakeup events I mean events that do both. Is there another
> term for this, or should I just add: "since wakeup events (events that
> wake the CPU from idle and the system from suspend)..."

Yes, that would clarify things IMO.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> This patch series adds a suspend-block api that provides the same
>> >> >> >> functionality as the android wakelock api. This version has some
>> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >> >> >>   for statically allocated suspend blockers.
>> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >> >> >>   optional _SET_NAME ioctl.
>> >> >> >>
>> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> >> >> there were a few cosmetic changes.
>> >> >> >
>> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
>> >> >> >
>> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> >> >> > the feature is and what problems it solves that generally a combination of
>> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> >> >> > think we need that feature.
>> >> >> >
>> >> >>
>> >> >> How about:
>> >> >>
>> >> >> PM: Add opportunistic suspend support.
>> >> >
>> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
>> >> >
>> >> > Now, I'd start with the motivation.  Like "Power management features present
>> >> > in the current mainline kernel are insufficient to get maximum possible energy
>> >> > savings on some platforms, such as Android, because ..." (here go explanations
>> >> > why this is the case in your opinion).
>> >> >
>> >> > Next, "To allow Android and similar platforms to save more energy than they
>> >> > currently can save using the mainline kernel, introduce a mechanism by which
>> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
>> >> > whenever it's not doing useful work, called opportunistic suspend".
>> >> >
>> >> > "For this purpose introduce the suspend blockers framework allowing the
>> >> > kernel's power management subsystem to decide when it is desirable to suspend
>> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
>> >> >
>> >>
>> >> PM: Opportunistic suspend support.
>> >>
>> >> Power management features present in the current mainline kernel are
>> >> insufficient to get maximum possible energy savings on some platforms,
>> >> such as Android, because low power states can only safely be entered
>> >> from idle.
>> >
>> > Do you mean CPU low-power states or system low-power states here?
>> >
>> I think either.
>
> The statement is not true for system low-power states (or sleep states),
> because generally (ie. on many platforms) they aren't entered from idle.
> Suspend is for entering them.
>
I don't think that makes my statement false. If you can only safely
enter low power states from idle, but some low power states cannot be
entered from idle, then it follows that you cannot safely enter those
low power states.

> So, there is a difference and the explanation can go like this: "... to achieve
> maximum energy savings one has to put all I/O devices and the CPU into
> low-power states, but the CPU can only be put into a low-power state from
> idle.  This, in turn, means that the CPU leaves the low-power state on
> interrupts triggered by periodic timers and user space processes that use
> polling.  It turns out, however, that many of these events causing the CPU to
> leave the low-power state aren't essential for the desired system functionality
> and from the power management point of view it would be better if they didn't
> occur".

This only explain why we still want to use suspend on systems that can
enter the same power states from idle and suspend.

>
>> > I'd add more details here, because it may not be completely clear to the
>> > (interested) reader why entering these states only from idle affects the
>> > possibility to achieve maximum energy savings.  I _guess_ you mean that
>> > using idle is not sufficient, because there are so many wakeups on the
>> > systems in question that more savings are still possible.  Is that correct?
>> >
>> Yes, is this not what the next paragraph explains?
>
> Well, it doesn't explain that.  It explains why idle + runtime PM is generally
> insufficient and is using that as an argument (at least in my view).
>
>> >> Suspend, in its current form, cannot be used, since wakeup
>> >> events that occur right after initiating suspend will not be processed
>> >> until another possibly unrelated event wake up the system again.
>> >
>> > I think the word "cannot" is too strong here.  I'd say "not suitable" instead
>>
>> I don't think it is too strong, but I can change it.
>>
>> > and I'd say what kind of wakeup events I meant more precisely (there are
>> > events that wake up a CPU from idle and events that wake up the system from
>> > suspend).
>>
>> When I say wakeup events I mean events that do both. Is there another
>> term for this, or should I just add: "since wakeup events (events that
>> wake the CPU from idle and the system from suspend)..."
>
> Yes, that would clarify things IMO.
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> This patch series adds a suspend-block api that provides the same
> >> >> >> >> functionality as the android wakelock api. This version has some
> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >> >> >> >>   for statically allocated suspend blockers.
> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
> >> >> >> >>   optional _SET_NAME ioctl.
> >> >> >> >>
> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
> >> >> >> >> there were a few cosmetic changes.
> >> >> >> >
> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
> >> >> >> >
> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> >> >> >> > the feature is and what problems it solves that generally a combination of
> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> >> >> >> > think we need that feature.
> >> >> >> >
> >> >> >>
> >> >> >> How about:
> >> >> >>
> >> >> >> PM: Add opportunistic suspend support.
> >> >> >
> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
> >> >> >
> >> >> > Now, I'd start with the motivation.  Like "Power management features present
> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
> >> >> > why this is the case in your opinion).
> >> >> >
> >> >> > Next, "To allow Android and similar platforms to save more energy than they
> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
> >> >> > whenever it's not doing useful work, called opportunistic suspend".
> >> >> >
> >> >> > "For this purpose introduce the suspend blockers framework allowing the
> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
> >> >> >
> >> >>
> >> >> PM: Opportunistic suspend support.
> >> >>
> >> >> Power management features present in the current mainline kernel are
> >> >> insufficient to get maximum possible energy savings on some platforms,
> >> >> such as Android, because low power states can only safely be entered
> >> >> from idle.
> >> >
> >> > Do you mean CPU low-power states or system low-power states here?
> >> >
> >> I think either.
> >
> > The statement is not true for system low-power states (or sleep states),
> > because generally (ie. on many platforms) they aren't entered from idle.
> > Suspend is for entering them.
> >
> I don't think that makes my statement false. If you can only safely
> enter low power states from idle, but some low power states cannot be
> entered from idle, then it follows that you cannot safely enter those
> low power states.

Define "safely", then.

> > So, there is a difference and the explanation can go like this: "... to achieve
> > maximum energy savings one has to put all I/O devices and the CPU into
> > low-power states, but the CPU can only be put into a low-power state from
> > idle.  This, in turn, means that the CPU leaves the low-power state on
> > interrupts triggered by periodic timers and user space processes that use
> > polling.  It turns out, however, that many of these events causing the CPU to
> > leave the low-power state aren't essential for the desired system functionality
> > and from the power management point of view it would be better if they didn't
> > occur".
> 
> This only explain why we still want to use suspend on systems that can
> enter the same power states from idle and suspend.

Sorry, I'm confused now.  Isn't that why you do that on Android?

AFACS, your hardware is capable of doing that, isn't it?

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> This patch series adds a suspend-block api that provides the same
>> >> >> >> >> functionality as the android wakelock api. This version has some
>> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >> >> >> >>   for statically allocated suspend blockers.
>> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >> >> >> >>   optional _SET_NAME ioctl.
>> >> >> >> >>
>> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> >> >> >> there were a few cosmetic changes.
>> >> >> >> >
>> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
>> >> >> >> >
>> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> >> >> >> > the feature is and what problems it solves that generally a combination of
>> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> >> >> >> > think we need that feature.
>> >> >> >> >
>> >> >> >>
>> >> >> >> How about:
>> >> >> >>
>> >> >> >> PM: Add opportunistic suspend support.
>> >> >> >
>> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
>> >> >> >
>> >> >> > Now, I'd start with the motivation.  Like "Power management features present
>> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
>> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
>> >> >> > why this is the case in your opinion).
>> >> >> >
>> >> >> > Next, "To allow Android and similar platforms to save more energy than they
>> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
>> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
>> >> >> > whenever it's not doing useful work, called opportunistic suspend".
>> >> >> >
>> >> >> > "For this purpose introduce the suspend blockers framework allowing the
>> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
>> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
>> >> >> >
>> >> >>
>> >> >> PM: Opportunistic suspend support.
>> >> >>
>> >> >> Power management features present in the current mainline kernel are
>> >> >> insufficient to get maximum possible energy savings on some platforms,
>> >> >> such as Android, because low power states can only safely be entered
>> >> >> from idle.
>> >> >
>> >> > Do you mean CPU low-power states or system low-power states here?
>> >> >
>> >> I think either.
>> >
>> > The statement is not true for system low-power states (or sleep states),
>> > because generally (ie. on many platforms) they aren't entered from idle.
>> > Suspend is for entering them.
>> >
>> I don't think that makes my statement false. If you can only safely
>> enter low power states from idle, but some low power states cannot be
>> entered from idle, then it follows that you cannot safely enter those
>> low power states.
>
> Define "safely", then.
>
OK. Is this clearer:

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android, because some wakeup events must work at all times
which means that low power states can only safely be entered from idle.
Suspend, in its current form, cannot be used, since wakeup events that
occur right after initiating suspend will not be processed until another
possibly unrelated event wake up the system again.


>> > So, there is a difference and the explanation can go like this: "... to achieve
>> > maximum energy savings one has to put all I/O devices and the CPU into
>> > low-power states, but the CPU can only be put into a low-power state from
>> > idle.  This, in turn, means that the CPU leaves the low-power state on
>> > interrupts triggered by periodic timers and user space processes that use
>> > polling.  It turns out, however, that many of these events causing the CPU to
>> > leave the low-power state aren't essential for the desired system functionality
>> > and from the power management point of view it would be better if they didn't
>> > occur".
>>
>> This only explain why we still want to use suspend on systems that can
>> enter the same power states from idle and suspend.
>
> Sorry, I'm confused now.  Isn't that why you do that on Android?
>

Yes, but it is not the only reason to use opportunistic support. It is
way more important to have opportunistic suspend support if the
hardware can enter lower power states from suspend than idle.

> AFACS, your hardware is capable of doing that, isn't it?
>

The current hardware, yes, the hardware we started with, no.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> >> This patch series adds a suspend-block api that provides the same
> >> >> >> >> >> functionality as the android wakelock api. This version has some
> >> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
> >> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >> >> >> >> >>   for statically allocated suspend blockers.
> >> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
> >> >> >> >> >>   optional _SET_NAME ioctl.
> >> >> >> >> >>
> >> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
> >> >> >> >> >> there were a few cosmetic changes.
> >> >> >> >> >
> >> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
> >> >> >> >> >
> >> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> >> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> >> >> >> >> > the feature is and what problems it solves that generally a combination of
> >> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> >> >> >> >> > think we need that feature.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> How about:
> >> >> >> >>
> >> >> >> >> PM: Add opportunistic suspend support.
> >> >> >> >
> >> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
> >> >> >> >
> >> >> >> > Now, I'd start with the motivation.  Like "Power management features present
> >> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
> >> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
> >> >> >> > why this is the case in your opinion).
> >> >> >> >
> >> >> >> > Next, "To allow Android and similar platforms to save more energy than they
> >> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
> >> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
> >> >> >> > whenever it's not doing useful work, called opportunistic suspend".
> >> >> >> >
> >> >> >> > "For this purpose introduce the suspend blockers framework allowing the
> >> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
> >> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
> >> >> >> >
> >> >> >>
> >> >> >> PM: Opportunistic suspend support.
> >> >> >>
> >> >> >> Power management features present in the current mainline kernel are
> >> >> >> insufficient to get maximum possible energy savings on some platforms,
> >> >> >> such as Android, because low power states can only safely be entered
> >> >> >> from idle.
> >> >> >
> >> >> > Do you mean CPU low-power states or system low-power states here?
> >> >> >
> >> >> I think either.
> >> >
> >> > The statement is not true for system low-power states (or sleep states),
> >> > because generally (ie. on many platforms) they aren't entered from idle.
> >> > Suspend is for entering them.
> >> >
> >> I don't think that makes my statement false. If you can only safely
> >> enter low power states from idle, but some low power states cannot be
> >> entered from idle, then it follows that you cannot safely enter those
> >> low power states.
> >
> > Define "safely", then.
> >
> OK. Is this clearer:

Not really.

> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android, because some wakeup events must work at all times
> which means that low power states can only safely be entered from idle.

It's not clear what you mean by "some wakeup events must work at all times"
and what "safely" means.

> Suspend, in its current form, cannot be used, since wakeup events that
> occur right after initiating suspend will not be processed until another
> possibly unrelated event wake up the system again.

Well, I _guess_ I know what you're trying to say, but I'm not sure if that's
the core of the problem the patchset is supposed to address.

The problem, as I see it, is really two-fold.

First, to save as much energy as reasonably possible you need to put everything
except for memory (ie. I/O devices and CPUs) into low-power states and let that
stay in these low-power states for as long as reasonably possible, right?

Second, you need the system to _always_ respond to some _specific_ events
regardless of its current state, correct?

Now, at present, we can put I/O devices and the CPU into low-power states
at the same time in two ways: (1) by using runtime PM and cpuidle and (2) by
suspending the system.  Unfortunately, none of these approaches is ideal,
because (1) is vulnerable to periodic timers and polling apps (and CPU-bound
apps) and (2) doesn't guarantee that all events you care about will be
responded to.

The proposed solution is to use suspend with an additional mechanism that
will prevent the events that have to be responded to from being lost.  This
additional mechanism is suspend blockers.

Is this correct?

> >> > So, there is a difference and the explanation can go like this: "... to achieve
> >> > maximum energy savings one has to put all I/O devices and the CPU into
> >> > low-power states, but the CPU can only be put into a low-power state from
> >> > idle.  This, in turn, means that the CPU leaves the low-power state on
> >> > interrupts triggered by periodic timers and user space processes that use
> >> > polling.  It turns out, however, that many of these events causing the CPU to
> >> > leave the low-power state aren't essential for the desired system functionality
> >> > and from the power management point of view it would be better if they didn't
> >> > occur".
> >>
> >> This only explain why we still want to use suspend on systems that can
> >> enter the same power states from idle and suspend.
> >
> > Sorry, I'm confused now.  Isn't that why you do that on Android?
> >
> 
> Yes, but it is not the only reason to use opportunistic support. It is
> way more important to have opportunistic suspend support if the
> hardware can enter lower power states from suspend than idle.

Sure, but you can add something like "There also are systems where some
devices cannot be put into low-power states without suspending the entire
system (or the low-power states available to them without suspending the
entire system are substantially shallower than the low-power states they are
put into when the entire system is suspended), so the system have to be
suspended as a whole to achieve the maximum energy savings".

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> >> This patch series adds a suspend-block api that provides the same
>> >> >> >> >> >> functionality as the android wakelock api. This version has some
>> >> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >> >> >> >> >>   for statically allocated suspend blockers.
>> >> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >> >> >> >> >>   optional _SET_NAME ioctl.
>> >> >> >> >> >>
>> >> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> >> >> >> >> there were a few cosmetic changes.
>> >> >> >> >> >
>> >> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
>> >> >> >> >> >
>> >> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> >> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> >> >> >> >> > the feature is and what problems it solves that generally a combination of
>> >> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> >> >> >> >> > think we need that feature.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> How about:
>> >> >> >> >>
>> >> >> >> >> PM: Add opportunistic suspend support.
>> >> >> >> >
>> >> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
>> >> >> >> >
>> >> >> >> > Now, I'd start with the motivation.  Like "Power management features present
>> >> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
>> >> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
>> >> >> >> > why this is the case in your opinion).
>> >> >> >> >
>> >> >> >> > Next, "To allow Android and similar platforms to save more energy than they
>> >> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
>> >> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
>> >> >> >> > whenever it's not doing useful work, called opportunistic suspend".
>> >> >> >> >
>> >> >> >> > "For this purpose introduce the suspend blockers framework allowing the
>> >> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
>> >> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
>> >> >> >> >
>> >> >> >>
>> >> >> >> PM: Opportunistic suspend support.
>> >> >> >>
>> >> >> >> Power management features present in the current mainline kernel are
>> >> >> >> insufficient to get maximum possible energy savings on some platforms,
>> >> >> >> such as Android, because low power states can only safely be entered
>> >> >> >> from idle.
>> >> >> >
>> >> >> > Do you mean CPU low-power states or system low-power states here?
>> >> >> >
>> >> >> I think either.
>> >> >
>> >> > The statement is not true for system low-power states (or sleep states),
>> >> > because generally (ie. on many platforms) they aren't entered from idle.
>> >> > Suspend is for entering them.
>> >> >
>> >> I don't think that makes my statement false. If you can only safely
>> >> enter low power states from idle, but some low power states cannot be
>> >> entered from idle, then it follows that you cannot safely enter those
>> >> low power states.
>> >
>> > Define "safely", then.
>> >
>> OK. Is this clearer:
>
> Not really.
>
>> Power management features present in the current mainline kernel are
>> insufficient to get maximum possible energy savings on some platforms,
>> such as Android, because some wakeup events must work at all times
>> which means that low power states can only safely be entered from idle.
>
> It's not clear what you mean by "some wakeup events must work at all times"
> and what "safely" means.
>
>> Suspend, in its current form, cannot be used, since wakeup events that
>> occur right after initiating suspend will not be processed until another
>> possibly unrelated event wake up the system again.
>
> Well, I _guess_ I know what you're trying to say, but I'm not sure if that's
> the core of the problem the patchset is supposed to address.
>
> The problem, as I see it, is really two-fold.
>
> First, to save as much energy as reasonably possible you need to put everything
> except for memory (ie. I/O devices and CPUs) into low-power states and let that
> stay in these low-power states for as long as reasonably possible, right?

Memory should also be in a low power state, but yes, everything should
be in the lowest power possible state for as long as possible.

>
> Second, you need the system to _always_ respond to some _specific_ events
> regardless of its current state, correct?
>
> Now, at present, we can put I/O devices and the CPU into low-power states
> at the same time in two ways: (1) by using runtime PM and cpuidle and (2) by
> suspending the system.  Unfortunately, none of these approaches is ideal,
> because (1) is vulnerable to periodic timers and polling apps (and CPU-bound
> apps) and (2) doesn't guarantee that all events you care about will be
> responded to.
>
> The proposed solution is to use suspend with an additional mechanism that
> will prevent the events that have to be responded to from being lost.  This
> additional mechanism is suspend blockers.
>
> Is this correct?

Yes.

>
>> >> > So, there is a difference and the explanation can go like this: "... to achieve
>> >> > maximum energy savings one has to put all I/O devices and the CPU into
>> >> > low-power states, but the CPU can only be put into a low-power state from
>> >> > idle.  This, in turn, means that the CPU leaves the low-power state on
>> >> > interrupts triggered by periodic timers and user space processes that use
>> >> > polling.  It turns out, however, that many of these events causing the CPU to
>> >> > leave the low-power state aren't essential for the desired system functionality
>> >> > and from the power management point of view it would be better if they didn't
>> >> > occur".
>> >>
>> >> This only explain why we still want to use suspend on systems that can
>> >> enter the same power states from idle and suspend.
>> >
>> > Sorry, I'm confused now.  Isn't that why you do that on Android?
>> >
>>
>> Yes, but it is not the only reason to use opportunistic support. It is
>> way more important to have opportunistic suspend support if the
>> hardware can enter lower power states from suspend than idle.
>
> Sure, but you can add something like "There also are systems where some
> devices cannot be put into low-power states without suspending the entire
> system (or the low-power states available to them without suspending the
> entire system are substantially shallower than the low-power states they are
> put into when the entire system is suspended), so the system have to be
> suspended as a whole to achieve the maximum energy savings".
>

Does this work for you:

PM: Opportunistic suspend support.

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android, because the system must always respond to certain
events. Suspend, in its current form, cannot be used on these
platforms, since wakeup events (events that wake the CPU from idle and
the system from suspend) that occur right after initiating suspend
will not be processed until another possibly unrelated event wake up
the system again.

On hardware where idle can enter the same power state as suspend, idle
combined with runtime PM can be used, but periodic wakeups increase
the average power consumption. Suspending the system also reduces the
harm caused by apps that never go idle. There also are systems where
some devices cannot be put into low-power states without suspending
the entire system (or the low-power states available to them without
suspending the entire system are substantially shallower than the
low-power states they are put into when the entire system is
suspended), so the system have to be suspended as a whole to achieve
the maximum energy savings.

To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, introduce a mechanism by
which the system is automatically suspended (i.e. put into a
system-wide sleep state) whenever it's not doing useful work, called
opportunistic suspend.

For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to
suspend the system (i.e. when the system is not doing anything the
user really cares about at the moment and therefore it may be
suspended). Add an API that that drivers can use to block
opportunistic suspend. This is needed to avoid losing wakeup events
that occur right after suspend is initiated.

Adds /sys/power/policy that selects the behavior of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.


-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
> >> >> >> >> >> >> This patch series adds a suspend-block api that provides the same
> >> >> >> >> >> >> functionality as the android wakelock api. This version has some
> >> >> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
> >> >> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
> >> >> >> >> >> >>   for statically allocated suspend blockers.
> >> >> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
> >> >> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
> >> >> >> >> >> >>   optional _SET_NAME ioctl.
> >> >> >> >> >> >>
> >> >> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
> >> >> >> >> >> >> there were a few cosmetic changes.
> >> >> >> >> >> >
> >> >> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
> >> >> >> >> >> >
> >> >> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
> >> >> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
> >> >> >> >> >> > the feature is and what problems it solves that generally a combination of
> >> >> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
> >> >> >> >> >> > think we need that feature.
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> How about:
> >> >> >> >> >>
> >> >> >> >> >> PM: Add opportunistic suspend support.
> >> >> >> >> >
> >> >> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
> >> >> >> >> >
> >> >> >> >> > Now, I'd start with the motivation.  Like "Power management features present
> >> >> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
> >> >> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
> >> >> >> >> > why this is the case in your opinion).
> >> >> >> >> >
> >> >> >> >> > Next, "To allow Android and similar platforms to save more energy than they
> >> >> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
> >> >> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
> >> >> >> >> > whenever it's not doing useful work, called opportunistic suspend".
> >> >> >> >> >
> >> >> >> >> > "For this purpose introduce the suspend blockers framework allowing the
> >> >> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
> >> >> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> PM: Opportunistic suspend support.
> >> >> >> >>
> >> >> >> >> Power management features present in the current mainline kernel are
> >> >> >> >> insufficient to get maximum possible energy savings on some platforms,
> >> >> >> >> such as Android, because low power states can only safely be entered
> >> >> >> >> from idle.
> >> >> >> >
> >> >> >> > Do you mean CPU low-power states or system low-power states here?
> >> >> >> >
> >> >> >> I think either.
> >> >> >
> >> >> > The statement is not true for system low-power states (or sleep states),
> >> >> > because generally (ie. on many platforms) they aren't entered from idle.
> >> >> > Suspend is for entering them.
> >> >> >
> >> >> I don't think that makes my statement false. If you can only safely
> >> >> enter low power states from idle, but some low power states cannot be
> >> >> entered from idle, then it follows that you cannot safely enter those
> >> >> low power states.
> >> >
> >> > Define "safely", then.
> >> >
> >> OK. Is this clearer:
> >
> > Not really.
> >
> >> Power management features present in the current mainline kernel are
> >> insufficient to get maximum possible energy savings on some platforms,
> >> such as Android, because some wakeup events must work at all times
> >> which means that low power states can only safely be entered from idle.
> >
> > It's not clear what you mean by "some wakeup events must work at all times"
> > and what "safely" means.
> >
> >> Suspend, in its current form, cannot be used, since wakeup events that
> >> occur right after initiating suspend will not be processed until another
> >> possibly unrelated event wake up the system again.
> >
> > Well, I _guess_ I know what you're trying to say, but I'm not sure if that's
> > the core of the problem the patchset is supposed to address.
> >
> > The problem, as I see it, is really two-fold.
> >
> > First, to save as much energy as reasonably possible you need to put everything
> > except for memory (ie. I/O devices and CPUs) into low-power states and let that
> > stay in these low-power states for as long as reasonably possible, right?
> 
> Memory should also be in a low power state, but yes, everything should
> be in the lowest power possible state for as long as possible.
> 
> >
> > Second, you need the system to _always_ respond to some _specific_ events
> > regardless of its current state, correct?
> >
> > Now, at present, we can put I/O devices and the CPU into low-power states
> > at the same time in two ways: (1) by using runtime PM and cpuidle and (2) by
> > suspending the system.  Unfortunately, none of these approaches is ideal,
> > because (1) is vulnerable to periodic timers and polling apps (and CPU-bound
> > apps) and (2) doesn't guarantee that all events you care about will be
> > responded to.
> >
> > The proposed solution is to use suspend with an additional mechanism that
> > will prevent the events that have to be responded to from being lost.  This
> > additional mechanism is suspend blockers.
> >
> > Is this correct?
> 
> Yes.
> 
> >
> >> >> > So, there is a difference and the explanation can go like this: "... to achieve
> >> >> > maximum energy savings one has to put all I/O devices and the CPU into
> >> >> > low-power states, but the CPU can only be put into a low-power state from
> >> >> > idle.  This, in turn, means that the CPU leaves the low-power state on
> >> >> > interrupts triggered by periodic timers and user space processes that use
> >> >> > polling.  It turns out, however, that many of these events causing the CPU to
> >> >> > leave the low-power state aren't essential for the desired system functionality
> >> >> > and from the power management point of view it would be better if they didn't
> >> >> > occur".
> >> >>
> >> >> This only explain why we still want to use suspend on systems that can
> >> >> enter the same power states from idle and suspend.
> >> >
> >> > Sorry, I'm confused now.  Isn't that why you do that on Android?
> >> >
> >>
> >> Yes, but it is not the only reason to use opportunistic support. It is
> >> way more important to have opportunistic suspend support if the
> >> hardware can enter lower power states from suspend than idle.
> >
> > Sure, but you can add something like "There also are systems where some
> > devices cannot be put into low-power states without suspending the entire
> > system (or the low-power states available to them without suspending the
> > entire system are substantially shallower than the low-power states they are
> > put into when the entire system is suspended), so the system have to be
> > suspended as a whole to achieve the maximum energy savings".
> >
> 
> Does this work for you:

Well, almost.

> PM: Opportunistic suspend support.
> 
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android,

I'd finish the first sentence here.

> because the system must always respond to certain
> events. Suspend, in its current form, cannot be used on these
> platforms,

This doesn't seem to be correct.  Surely you can suspend these systems, but
you can't address the problem at hand using suspend as is.

I'd say (in the second sentence) "The problem is that to save maximum amount of
energy all system hardware components need to be in the lowest-power states
available for as long as reasonably possible, but at the same time the system
must always respond to certain events, regardless of the current state of the
hardware.

The first goal can be achieved either by using device runtime PM and cpuidle to
put all hardware into low-power states, transparently from the user space point
of view, or by suspending the whole system.  However, system suspend, in its
current form, does not guarantee that the events of interest will always be
responded to, since wakeup events ..."

> since wakeup events (events that wake the CPU from idle and
> the system from suspend) that occur right after initiating suspend
> will not be processed until another possibly unrelated event wake up

"... wakes up ..." I guess.

> the system again.
> 
> On hardware where idle can enter the same power state as suspend, idle
> combined with runtime PM can be used, but periodic wakeups increase
> the average power consumption. Suspending the system also reduces the
> harm caused by apps that never go idle. There also are systems where
> some devices cannot be put into low-power states without suspending
> the entire system (or the low-power states available to them without
> suspending the entire system are substantially shallower than the
> low-power states they are put into when the entire system is
> suspended), so the system have to be suspended as a whole to achieve
> the maximum energy savings.
> 
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, introduce a mechanism by
> which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing useful work, called
> opportunistic suspend.

I'd say "... whenever it's not doing work that's immediately useful to the
user, called  ..." or something like this.

The rest is fine by me.

Rafael

Re: [PATCH 0/8] Suspend block api (version 7)

[Arve Hjønnevåg]

2010/5/19 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> 2010/5/18 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> 2010/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> >> 2010/5/14 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> >> >> >> >> > On Friday 14 May 2010, Arve Hjønnevåg wrote:
>> >> >> >> >> >> >> This patch series adds a suspend-block api that provides the same
>> >> >> >> >> >> >> functionality as the android wakelock api. This version has some
>> >> >> >> >> >> >> changes from, or requested by, Rafael. The most notable changes are:
>> >> >> >> >> >> >> - DEFINE_SUSPEND_BLOCKER and suspend_blocker_register have been added
>> >> >> >> >> >> >>   for statically allocated suspend blockers.
>> >> >> >> >> >> >> - suspend_blocker_destroy is now called suspend_blocker_unregister
>> >> >> >> >> >> >> - The user space mandatory _INIT ioctl has been replaced with an
>> >> >> >> >> >> >>   optional _SET_NAME ioctl.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> I kept the ack and reviewed by tags on two of the patches even though
>> >> >> >> >> >> >> there were a few cosmetic changes.
>> >> >> >> >> >> >
>> >> >> >> >> >> > Thanks for the patches, I think they are in a pretty good shape now.
>> >> >> >> >> >> >
>> >> >> >> >> >> > That said, I'd like the changelogs to be a bit more descriptive, at least for
>> >> >> >> >> >> > patch [1/8].  I think it should explain (in a few words) what the purpose of
>> >> >> >> >> >> > the feature is and what problems it solves that generally a combination of
>> >> >> >> >> >> > runtime PM and cpuidle is not suitable for in your opinion.  IOW, why you
>> >> >> >> >> >> > think we need that feature.
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> How about:
>> >> >> >> >> >>
>> >> >> >> >> >> PM: Add opportunistic suspend support.
>> >> >> >> >> >
>> >> >> >> >> > "PM: Opportunistic suspend support" would be sufficient IMO.
>> >> >> >> >> >
>> >> >> >> >> > Now, I'd start with the motivation.  Like "Power management features present
>> >> >> >> >> > in the current mainline kernel are insufficient to get maximum possible energy
>> >> >> >> >> > savings on some platforms, such as Android, because ..." (here go explanations
>> >> >> >> >> > why this is the case in your opinion).
>> >> >> >> >> >
>> >> >> >> >> > Next, "To allow Android and similar platforms to save more energy than they
>> >> >> >> >> > currently can save using the mainline kernel, introduce a mechanism by which
>> >> >> >> >> > the system is automatically suspended (i.e. put into a system-wide sleep state)
>> >> >> >> >> > whenever it's not doing useful work, called opportunistic suspend".
>> >> >> >> >> >
>> >> >> >> >> > "For this purpose introduce the suspend blockers framework allowing the
>> >> >> >> >> > kernel's power management subsystem to decide when it is desirable to suspend
>> >> >> >> >> > the system (i.e. when useful work is not being done).  Add an API that ..."
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> PM: Opportunistic suspend support.
>> >> >> >> >>
>> >> >> >> >> Power management features present in the current mainline kernel are
>> >> >> >> >> insufficient to get maximum possible energy savings on some platforms,
>> >> >> >> >> such as Android, because low power states can only safely be entered
>> >> >> >> >> from idle.
>> >> >> >> >
>> >> >> >> > Do you mean CPU low-power states or system low-power states here?
>> >> >> >> >
>> >> >> >> I think either.
>> >> >> >
>> >> >> > The statement is not true for system low-power states (or sleep states),
>> >> >> > because generally (ie. on many platforms) they aren't entered from idle.
>> >> >> > Suspend is for entering them.
>> >> >> >
>> >> >> I don't think that makes my statement false. If you can only safely
>> >> >> enter low power states from idle, but some low power states cannot be
>> >> >> entered from idle, then it follows that you cannot safely enter those
>> >> >> low power states.
>> >> >
>> >> > Define "safely", then.
>> >> >
>> >> OK. Is this clearer:
>> >
>> > Not really.
>> >
>> >> Power management features present in the current mainline kernel are
>> >> insufficient to get maximum possible energy savings on some platforms,
>> >> such as Android, because some wakeup events must work at all times
>> >> which means that low power states can only safely be entered from idle.
>> >
>> > It's not clear what you mean by "some wakeup events must work at all times"
>> > and what "safely" means.
>> >
>> >> Suspend, in its current form, cannot be used, since wakeup events that
>> >> occur right after initiating suspend will not be processed until another
>> >> possibly unrelated event wake up the system again.
>> >
>> > Well, I _guess_ I know what you're trying to say, but I'm not sure if that's
>> > the core of the problem the patchset is supposed to address.
>> >
>> > The problem, as I see it, is really two-fold.
>> >
>> > First, to save as much energy as reasonably possible you need to put everything
>> > except for memory (ie. I/O devices and CPUs) into low-power states and let that
>> > stay in these low-power states for as long as reasonably possible, right?
>>
>> Memory should also be in a low power state, but yes, everything should
>> be in the lowest power possible state for as long as possible.
>>
>> >
>> > Second, you need the system to _always_ respond to some _specific_ events
>> > regardless of its current state, correct?
>> >
>> > Now, at present, we can put I/O devices and the CPU into low-power states
>> > at the same time in two ways: (1) by using runtime PM and cpuidle and (2) by
>> > suspending the system.  Unfortunately, none of these approaches is ideal,
>> > because (1) is vulnerable to periodic timers and polling apps (and CPU-bound
>> > apps) and (2) doesn't guarantee that all events you care about will be
>> > responded to.
>> >
>> > The proposed solution is to use suspend with an additional mechanism that
>> > will prevent the events that have to be responded to from being lost.  This
>> > additional mechanism is suspend blockers.
>> >
>> > Is this correct?
>>
>> Yes.
>>
>> >
>> >> >> > So, there is a difference and the explanation can go like this: "... to achieve
>> >> >> > maximum energy savings one has to put all I/O devices and the CPU into
>> >> >> > low-power states, but the CPU can only be put into a low-power state from
>> >> >> > idle.  This, in turn, means that the CPU leaves the low-power state on
>> >> >> > interrupts triggered by periodic timers and user space processes that use
>> >> >> > polling.  It turns out, however, that many of these events causing the CPU to
>> >> >> > leave the low-power state aren't essential for the desired system functionality
>> >> >> > and from the power management point of view it would be better if they didn't
>> >> >> > occur".
>> >> >>
>> >> >> This only explain why we still want to use suspend on systems that can
>> >> >> enter the same power states from idle and suspend.
>> >> >
>> >> > Sorry, I'm confused now.  Isn't that why you do that on Android?
>> >> >
>> >>
>> >> Yes, but it is not the only reason to use opportunistic support. It is
>> >> way more important to have opportunistic suspend support if the
>> >> hardware can enter lower power states from suspend than idle.
>> >
>> > Sure, but you can add something like "There also are systems where some
>> > devices cannot be put into low-power states without suspending the entire
>> > system (or the low-power states available to them without suspending the
>> > entire system are substantially shallower than the low-power states they are
>> > put into when the entire system is suspended), so the system have to be
>> > suspended as a whole to achieve the maximum energy savings".
>> >
>>
>> Does this work for you:
>
> Well, almost.
>
>> PM: Opportunistic suspend support.
>>
>> Power management features present in the current mainline kernel are
>> insufficient to get maximum possible energy savings on some platforms,
>> such as Android,
>
> I'd finish the first sentence here.
>
>> because the system must always respond to certain
>> events. Suspend, in its current form, cannot be used on these
>> platforms,
>
> This doesn't seem to be correct.  Surely you can suspend these systems, but
> you can't address the problem at hand using suspend as is.
>
> I'd say (in the second sentence) "The problem is that to save maximum amount of
> energy all system hardware components need to be in the lowest-power states
> available for as long as reasonably possible, but at the same time the system
> must always respond to certain events, regardless of the current state of the
> hardware.
>
> The first goal can be achieved either by using device runtime PM and cpuidle to
> put all hardware into low-power states, transparently from the user space point
> of view, or by suspending the whole system.  However, system suspend, in its
> current form, does not guarantee that the events of interest will always be
> responded to, since wakeup events ..."
>
>> since wakeup events (events that wake the CPU from idle and
>> the system from suspend) that occur right after initiating suspend
>> will not be processed until another possibly unrelated event wake up
>
> "... wakes up ..." I guess.
>
>> the system again.
>>
>> On hardware where idle can enter the same power state as suspend, idle
>> combined with runtime PM can be used, but periodic wakeups increase
>> the average power consumption. Suspending the system also reduces the
>> harm caused by apps that never go idle. There also are systems where
>> some devices cannot be put into low-power states without suspending
>> the entire system (or the low-power states available to them without
>> suspending the entire system are substantially shallower than the
>> low-power states they are put into when the entire system is
>> suspended), so the system have to be suspended as a whole to achieve
>> the maximum energy savings.
>>
>> To allow Android and similar platforms to save more energy than they
>> currently can save using the mainline kernel, introduce a mechanism by
>> which the system is automatically suspended (i.e. put into a
>> system-wide sleep state) whenever it's not doing useful work, called
>> opportunistic suspend.
>
> I'd say "... whenever it's not doing work that's immediately useful to the
> user, called  ..." or something like this.
>
> The rest is fine by me.
>

PM: Opportunistic suspend support.

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android.  The problem is that to save maximum amount of energy
all system hardware components need to be in the lowest-power states
available for as long as reasonably possible, but at the same time the
system must always respond to certain events, regardless of the
current state of the hardware.

The first goal can be achieved either by using device runtime PM and
cpuidle to put all hardware into low-power states, transparently from
the user space point of view, or by suspending the whole system.
However, system suspend, in its current form, does not guarantee that
the events of interest will always be responded to, since wakeup
events (events that wake the CPU from idle and the system from
suspend) that occur right after initiating suspend will not be
processed until another possibly unrelated event wakes the system up
again.

On hardware where idle can enter the same power state as suspend, idle
combined with runtime PM can be used, but periodic wakeups increase
the average power consumption. Suspending the system also reduces the
harm caused by apps that never go idle. There also are systems where
some devices cannot be put into low-power states without suspending
the entire system (or the low-power states available to them without
suspending the entire system are substantially shallower than the
low-power states they are put into when the entire system is
suspended), so the system has to be suspended as a whole to achieve
the maximum energy savings.

To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, introduce a mechanism by
which the system is automatically suspended (i.e. put into a
system-wide sleep state) whenever it's not doing work that's
immediately useful to the user, called opportunistic suspend.

For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to
suspend the system (i.e. when the system is not doing anything the
user really cares about at the moment and therefore it may be
suspended). Add an API that that drivers can use to block
opportunistic suspend. This is needed to avoid losing wakeup events
that occur right after suspend is initiated.

Add /sys/power/policy that selects the behavior of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 7)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
...
> PM: Opportunistic suspend support.
> 
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android.  The problem is that to save maximum amount of energy
> all system hardware components need to be in the lowest-power states
> available for as long as reasonably possible, but at the same time the
> system must always respond to certain events, regardless of the
> current state of the hardware.
> 
> The first goal can be achieved either by using device runtime PM and
> cpuidle to put all hardware into low-power states, transparently from
> the user space point of view, or by suspending the whole system.
> However, system suspend, in its current form, does not guarantee that
> the events of interest will always be responded to, since wakeup
> events (events that wake the CPU from idle and the system from
> suspend) that occur right after initiating suspend will not be
> processed until another possibly unrelated event wakes the system up
> again.
> 
> On hardware where idle can enter the same power state as suspend, idle
> combined with runtime PM can be used, but periodic wakeups increase
> the average power consumption. Suspending the system also reduces the
> harm caused by apps that never go idle. There also are systems where
> some devices cannot be put into low-power states without suspending
> the entire system (or the low-power states available to them without
> suspending the entire system are substantially shallower than the
> low-power states they are put into when the entire system is
> suspended), so the system has to be suspended as a whole to achieve
> the maximum energy savings.
> 
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, introduce a mechanism by
> which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing work that's
> immediately useful to the user, called opportunistic suspend.
> 
> For this purpose introduce the suspend blockers framework allowing the
> kernel's power management subsystem to decide when it is desirable to
> suspend the system (i.e. when the system is not doing anything the
> user really cares about at the moment and therefore it may be
> suspended). Add an API that that drivers can use to block
> opportunistic suspend. This is needed to avoid losing wakeup events
> that occur right after suspend is initiated.
> 
> Add /sys/power/policy that selects the behavior of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.

That looks good to me.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Thu, 6 May 2010, Arve Hjønnevåg wrote:

> On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 6 May 2010, Rafael J. Wysocki wrote:
> >
> >> > Here's a completely new issue.  When using opportunistic suspends on an
> >> > SMP system, it could happen that the system gets a wakeup event and
> >> > this routine starts running again before the event's IRQ handler has
> >> > finished (or has enabled a suspend blocker).  The system would
> >> > re-suspend too soon.
> >>
> >> This routine will be run from a freezable workqueue.
> >
> > But how do you know that processes won't get unfrozen until all the
> > pending IRQs have been handled?  Imagine something like this:
> >
> >        CPU 0                   CPU 1
> >        -----                   -----
> >        Wake up non-boot CPUs
> >        Resume devices          Invoke the IRQ handler
> >
> >        [ CPU 0 should wait here for the handler to finish,
> >          but it doesn't ]
> >
> >        Defrost threads         Handler running...
> >        Workqueue routine runs
> >        Start another suspend
> >                                Handler enables a suspend blocker,
> >                                but it's too late
> 
> It is not optimal, but it is not too late. We check if any suspend
> blockers block suspend after disabling non-boot cpus so as long as
> this is done in a way that does not lose interrupts the resuspend
> attempt will not succeed.

Is it possible for the resuspend to disable CPU 1 before the IRQ
handler can enable its suspend blocker?  (Probably not -- but I don't
know enough about how non-boot CPUs are enabled or disabled.)

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Thu, 6 May 2010, Rafael J. Wysocki wrote:

> > Here's a completely new issue.  When using opportunistic suspends on an
> > SMP system, it could happen that the system gets a wakeup event and
> > this routine starts running again before the event's IRQ handler has
> > finished (or has enabled a suspend blocker).  The system would 
> > re-suspend too soon.
> 
> This routine will be run from a freezable workqueue.

But how do you know that processes won't get unfrozen until all the 
pending IRQs have been handled?  Imagine something like this:

	CPU 0			CPU 1
	-----			-----
	Wake up non-boot CPUs
	Resume devices		Invoke the IRQ handler

	[ CPU 0 should wait here for the handler to finish, 
	  but it doesn't ]

	Defrost threads		Handler running...
	Workqueue routine runs
	Start another suspend
				Handler enables a suspend blocker,
				but it's too late

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 6 May 2010, Rafael J. Wysocki wrote:
>
>> > Here's a completely new issue.  When using opportunistic suspends on an
>> > SMP system, it could happen that the system gets a wakeup event and
>> > this routine starts running again before the event's IRQ handler has
>> > finished (or has enabled a suspend blocker).  The system would
>> > re-suspend too soon.
>>
>> This routine will be run from a freezable workqueue.
>
> But how do you know that processes won't get unfrozen until all the
> pending IRQs have been handled?  Imagine something like this:
>
>        CPU 0                   CPU 1
>        -----                   -----
>        Wake up non-boot CPUs
>        Resume devices          Invoke the IRQ handler
>
>        [ CPU 0 should wait here for the handler to finish,
>          but it doesn't ]
>
>        Defrost threads         Handler running...
>        Workqueue routine runs
>        Start another suspend
>                                Handler enables a suspend blocker,
>                                but it's too late

It is not optimal, but it is not too late. We check if any suspend
blockers block suspend after disabling non-boot cpus so as long as
this is done in a way that does not lose interrupts the resuspend
attempt will not succeed.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Thursday 06 May 2010, Alan Stern wrote:
> On Tue, 27 Apr 2010, [UTF-8] Arve Hjønnevåg wrote:
> 
> > +static void suspend_worker(struct work_struct *work)
> > +{
> > +	int ret;
> > +	int entry_event_num;
> > +
> > +	enable_suspend_blockers = true;
> > +	while (!suspend_is_blocked()) {
> > +		entry_event_num = current_event_num;
> > +
> > +		if (debug_mask & DEBUG_SUSPEND)
> > +			pr_info("suspend: enter suspend\n");
> > +
> > +		ret = pm_suspend(requested_suspend_state);
> > +
> > +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> > +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> > +
> > +		if (current_event_num == entry_event_num)
> > +			pr_info("suspend: pm_suspend returned with no event\n");
> > +	}
> > +	enable_suspend_blockers = false;
> > +}
> 
> Here's a completely new issue.  When using opportunistic suspends on an
> SMP system, it could happen that the system gets a wakeup event and
> this routine starts running again before the event's IRQ handler has
> finished (or has enabled a suspend blocker).  The system would 
> re-suspend too soon.

This routine will be run from a freezable workqueue.

Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Wed, 5 May 2010, mark gross wrote:

> > > True, you need an ack back from user mode for when its ok to allow
> > > suspend to happen.  This ack is device specific and needs to be custom
> > > built per product to its wake up sources.
> > 
> > No and no.  Nothing special is needed.  All userspace needs to do is 
> > remove the condition that led to the blocker being enabled initially -- 
> > which is exactly what userspace would do normally anyway.
> 
> Oh, like tell the modem that user mode has handled the ring event and
> its ok to un-block?

No, that's not how it works.  It would go like this:

	The modem IRQ handler queues its event to the input subsystem.  
	As it does so the input subsystem enables a suspend blocker, 
	causing the system to stay awake after the IRQ is done.

	The user program enables its own suspend blocker before reading
	the input queue.  When the queue is empty, the input subsystem
	releases its suspend blocker.

	When the user program finishes processing the event, it
	releases its suspend blocker.  Now the system can go back to
	sleep.

At no point does the user program have to communicate anything to the 
modem driver, and at no point does it have to do anything out of the 
ordinary except to enable and disable a suspend blocker.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Brian Swetland]

On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>
>> Oh, like tell the modem that user mode has handled the ring event and
>> its ok to un-block?
>
> No, that's not how it works.  It would go like this:
>
>        The modem IRQ handler queues its event to the input subsystem.
>        As it does so the input subsystem enables a suspend blocker,
>        causing the system to stay awake after the IRQ is done.
>
>        The user program enables its own suspend blocker before reading
>        the input queue.  When the queue is empty, the input subsystem
>        releases its suspend blocker.
>
>        When the user program finishes processing the event, it
>        releases its suspend blocker.  Now the system can go back to
>        sleep.
>
> At no point does the user program have to communicate anything to the
> modem driver, and at no point does it have to do anything out of the
> ordinary except to enable and disable a suspend blocker.

Exactly -- and you can use the same style of overlapping suspend
blockers with other drivers than input, if the input interface is not
suitable for the particular interaction.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Brian Swetland <swetland@google.com> [100505 14:34]:
> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >>
> >> Oh, like tell the modem that user mode has handled the ring event and
> >> its ok to un-block?
> >
> > No, that's not how it works.  It would go like this:
> >
> >        The modem IRQ handler queues its event to the input subsystem.
> >        As it does so the input subsystem enables a suspend blocker,
> >        causing the system to stay awake after the IRQ is done.

How about instead the modem driver fails to suspend until it's done?

Each driver could have a suspend_policy sysfs entry with options such
as [ forced | safe ]. The default would be forced. Forced would
be the current behaviour, while safe would refuse suspend until the
driver is done processing.

> >        The user program enables its own suspend blocker before reading
> >        the input queue.  When the queue is empty, the input subsystem
> >        releases its suspend blocker.

And also the input layer could refuse to suspend until it's done.

> >        When the user program finishes processing the event, it
> >        releases its suspend blocker.  Now the system can go back to
> >        sleep.

And here the user space just tries to suspend again when it's done?
It's not like you're trying to suspend all the time, so it should be
OK to retry a few times.

> > At no point does the user program have to communicate anything to the
> > modem driver, and at no point does it have to do anything out of the
> > ordinary except to enable and disable a suspend blocker.
> 
> Exactly -- and you can use the same style of overlapping suspend
> blockers with other drivers than input, if the input interface is not
> suitable for the particular interaction.

Would the suspend blockers still be needed somewhere in the example
above?

Regards,

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Brian Swetland]

On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Brian Swetland <swetland@google.com> [100505 14:34]:
>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> >>
>> >> Oh, like tell the modem that user mode has handled the ring event and
>> >> its ok to un-block?
>> >
>> > No, that's not how it works.  It would go like this:
>> >
>> >        The modem IRQ handler queues its event to the input subsystem.
>> >        As it does so the input subsystem enables a suspend blocker,
>> >        causing the system to stay awake after the IRQ is done.
>
> How about instead the modem driver fails to suspend until it's done?
>
> Each driver could have a suspend_policy sysfs entry with options such
> as [ forced | safe ]. The default would be forced. Forced would
> be the current behaviour, while safe would refuse suspend until the
> driver is done processing.
>
>> >        The user program enables its own suspend blocker before reading
>> >        the input queue.  When the queue is empty, the input subsystem
>> >        releases its suspend blocker.
>
> And also the input layer could refuse to suspend until it's done.
>
>> >        When the user program finishes processing the event, it
>> >        releases its suspend blocker.  Now the system can go back to
>> >        sleep.
>
> And here the user space just tries to suspend again when it's done?
> It's not like you're trying to suspend all the time, so it should be
> OK to retry a few times.

We actually are trying to suspend all the time -- that's our basic
model -- suspend whenever we can when something doesn't prevent it.

>> > At no point does the user program have to communicate anything to the
>> > modem driver, and at no point does it have to do anything out of the
>> > ordinary except to enable and disable a suspend blocker.
>>
>> Exactly -- and you can use the same style of overlapping suspend
>> blockers with other drivers than input, if the input interface is not
>> suitable for the particular interaction.
>
> Would the suspend blockers still be needed somewhere in the example
> above?

How often would we retry suspending?

If we fail to suspend, don't we have to resume all the drivers that
suspended before the one that failed?  (Maybe I'm mistaken here)

With the suspend block model we know the moment we're capable of
suspending and then can suspend at that moment.  Continually trying to
suspend seems like it'd be inefficient power-wise (we're going to be
doing a lot more work as we try to suspend over and over, or we're
going to retry after a timeout and spend extra time not suspended).

We can often spend minutes (possibly many) at a time preventing
suspend when the system is doing work that would be interrupted by a
full suspend.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Brian Swetland <swetland@google.com> [100505 16:51]:
> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Brian Swetland <swetland@google.com> [100505 14:34]:
> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >> >>
> >> >> Oh, like tell the modem that user mode has handled the ring event and
> >> >> its ok to un-block?
> >> >
> >> > No, that's not how it works.  It would go like this:
> >> >
> >> >        The modem IRQ handler queues its event to the input subsystem.
> >> >        As it does so the input subsystem enables a suspend blocker,
> >> >        causing the system to stay awake after the IRQ is done.
> >
> > How about instead the modem driver fails to suspend until it's done?
> >
> > Each driver could have a suspend_policy sysfs entry with options such
> > as [ forced | safe ]. The default would be forced. Forced would
> > be the current behaviour, while safe would refuse suspend until the
> > driver is done processing.
> >
> >> >        The user program enables its own suspend blocker before reading
> >> >        the input queue.  When the queue is empty, the input subsystem
> >> >        releases its suspend blocker.
> >
> > And also the input layer could refuse to suspend until it's done.
> >
> >> >        When the user program finishes processing the event, it
> >> >        releases its suspend blocker.  Now the system can go back to
> >> >        sleep.
> >
> > And here the user space just tries to suspend again when it's done?
> > It's not like you're trying to suspend all the time, so it should be
> > OK to retry a few times.
> 
> We actually are trying to suspend all the time -- that's our basic
> model -- suspend whenever we can when something doesn't prevent it.

Maybe that state could be kept in some userspace suspend policy manager?
 
> >> > At no point does the user program have to communicate anything to the
> >> > modem driver, and at no point does it have to do anything out of the
> >> > ordinary except to enable and disable a suspend blocker.
> >>
> >> Exactly -- and you can use the same style of overlapping suspend
> >> blockers with other drivers than input, if the input interface is not
> >> suitable for the particular interaction.
> >
> > Would the suspend blockers still be needed somewhere in the example
> > above?
> 
> How often would we retry suspending?

Well based on some timer, the same way the screen blanks? Or five
seconds of no audio play? So if the suspend fails, then reset whatever
userspace suspend policy timers.
 
> If we fail to suspend, don't we have to resume all the drivers that
> suspended before the one that failed?  (Maybe I'm mistaken here)

Sure, but I guess that should be a rare event that only happens when
you try to suspend and something interrupts the suspend.
 
> With the suspend block model we know the moment we're capable of
> suspending and then can suspend at that moment.  Continually trying to
> suspend seems like it'd be inefficient power-wise (we're going to be
> doing a lot more work as we try to suspend over and over, or we're
> going to retry after a timeout and spend extra time not suspended).
> 
> We can often spend minutes (possibly many) at a time preventing
> suspend when the system is doing work that would be interrupted by a
> full suspend.

Maybe you a userspace suspend policy manager would do the trick if
it knows when the screen is blanked and no audio has been played for
five seconds etc?

Regards,

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Brian Swetland <swetland@google.com> [100505 16:51]:
>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Brian Swetland <swetland@google.com> [100505 14:34]:
>> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> >> >>
>> >> >> Oh, like tell the modem that user mode has handled the ring event and
>> >> >> its ok to un-block?
>> >> >
>> >> > No, that's not how it works.  It would go like this:
>> >> >
>> >> >        The modem IRQ handler queues its event to the input subsystem.
>> >> >        As it does so the input subsystem enables a suspend blocker,
>> >> >        causing the system to stay awake after the IRQ is done.
>> >
>> > How about instead the modem driver fails to suspend until it's done?
>> >
>> > Each driver could have a suspend_policy sysfs entry with options such
>> > as [ forced | safe ]. The default would be forced. Forced would
>> > be the current behaviour, while safe would refuse suspend until the
>> > driver is done processing.
>> >
>> >> >        The user program enables its own suspend blocker before reading
>> >> >        the input queue.  When the queue is empty, the input subsystem
>> >> >        releases its suspend blocker.
>> >
>> > And also the input layer could refuse to suspend until it's done.
>> >
>> >> >        When the user program finishes processing the event, it
>> >> >        releases its suspend blocker.  Now the system can go back to
>> >> >        sleep.
>> >
>> > And here the user space just tries to suspend again when it's done?
>> > It's not like you're trying to suspend all the time, so it should be
>> > OK to retry a few times.
>>
>> We actually are trying to suspend all the time -- that's our basic
>> model -- suspend whenever we can when something doesn't prevent it.
>
> Maybe that state could be kept in some userspace suspend policy manager?
>
>> >> > At no point does the user program have to communicate anything to the
>> >> > modem driver, and at no point does it have to do anything out of the
>> >> > ordinary except to enable and disable a suspend blocker.
>> >>
>> >> Exactly -- and you can use the same style of overlapping suspend
>> >> blockers with other drivers than input, if the input interface is not
>> >> suitable for the particular interaction.
>> >
>> > Would the suspend blockers still be needed somewhere in the example
>> > above?
>>
>> How often would we retry suspending?
>
> Well based on some timer, the same way the screen blanks? Or five
> seconds of no audio play? So if the suspend fails, then reset whatever
> userspace suspend policy timers.
>
>> If we fail to suspend, don't we have to resume all the drivers that
>> suspended before the one that failed?  (Maybe I'm mistaken here)
>
> Sure, but I guess that should be a rare event that only happens when
> you try to suspend and something interrupts the suspend.
>

This is not a rare event. For example, the matrix keypad driver blocks
suspend when a key is down so it can scan the matrix.

>> With the suspend block model we know the moment we're capable of
>> suspending and then can suspend at that moment.  Continually trying to
>> suspend seems like it'd be inefficient power-wise (we're going to be
>> doing a lot more work as we try to suspend over and over, or we're
>> going to retry after a timeout and spend extra time not suspended).
>>
>> We can often spend minutes (possibly many) at a time preventing
>> suspend when the system is doing work that would be interrupted by a
>> full suspend.
>
> Maybe you a userspace suspend policy manager would do the trick if
> it knows when the screen is blanked and no audio has been played for
> five seconds etc?
>

If user space has to initiate every suspend attempt, then you are
forcing it to poll whenever a driver needs to block suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Arve Hjønnevåg <arve@android.com> [100505 21:11]:
> On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Brian Swetland <swetland@google.com> [100505 16:51]:
> >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > * Brian Swetland <swetland@google.com> [100505 14:34]:
> >> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >> >> >>
> >> >> >> Oh, like tell the modem that user mode has handled the ring event and
> >> >> >> its ok to un-block?
> >> >> >
> >> >> > No, that's not how it works.  It would go like this:
> >> >> >
> >> >> >        The modem IRQ handler queues its event to the input subsystem.
> >> >> >        As it does so the input subsystem enables a suspend blocker,
> >> >> >        causing the system to stay awake after the IRQ is done.
> >> >
> >> > How about instead the modem driver fails to suspend until it's done?
> >> >
> >> > Each driver could have a suspend_policy sysfs entry with options such
> >> > as [ forced | safe ]. The default would be forced. Forced would
> >> > be the current behaviour, while safe would refuse suspend until the
> >> > driver is done processing.
> >> >
> >> >> >        The user program enables its own suspend blocker before reading
> >> >> >        the input queue.  When the queue is empty, the input subsystem
> >> >> >        releases its suspend blocker.
> >> >
> >> > And also the input layer could refuse to suspend until it's done.
> >> >
> >> >> >        When the user program finishes processing the event, it
> >> >> >        releases its suspend blocker.  Now the system can go back to
> >> >> >        sleep.
> >> >
> >> > And here the user space just tries to suspend again when it's done?
> >> > It's not like you're trying to suspend all the time, so it should be
> >> > OK to retry a few times.
> >>
> >> We actually are trying to suspend all the time -- that's our basic
> >> model -- suspend whenever we can when something doesn't prevent it.
> >
> > Maybe that state could be kept in some userspace suspend policy manager?
> >
> >> >> > At no point does the user program have to communicate anything to the
> >> >> > modem driver, and at no point does it have to do anything out of the
> >> >> > ordinary except to enable and disable a suspend blocker.
> >> >>
> >> >> Exactly -- and you can use the same style of overlapping suspend
> >> >> blockers with other drivers than input, if the input interface is not
> >> >> suitable for the particular interaction.
> >> >
> >> > Would the suspend blockers still be needed somewhere in the example
> >> > above?
> >>
> >> How often would we retry suspending?
> >
> > Well based on some timer, the same way the screen blanks? Or five
> > seconds of no audio play? So if the suspend fails, then reset whatever
> > userspace suspend policy timers.
> >
> >> If we fail to suspend, don't we have to resume all the drivers that
> >> suspended before the one that failed?  (Maybe I'm mistaken here)
> >
> > Sure, but I guess that should be a rare event that only happens when
> > you try to suspend and something interrupts the suspend.
> >
> 
> This is not a rare event. For example, the matrix keypad driver blocks
> suspend when a key is down so it can scan the matrix.

Sure, but how many times per day are you suspending?
 
> >> With the suspend block model we know the moment we're capable of
> >> suspending and then can suspend at that moment.  Continually trying to
> >> suspend seems like it'd be inefficient power-wise (we're going to be
> >> doing a lot more work as we try to suspend over and over, or we're
> >> going to retry after a timeout and spend extra time not suspended).
> >>
> >> We can often spend minutes (possibly many) at a time preventing
> >> suspend when the system is doing work that would be interrupted by a
> >> full suspend.
> >
> > Maybe you a userspace suspend policy manager would do the trick if
> > it knows when the screen is blanked and no audio has been played for
> > five seconds etc?
> >
> 
> If user space has to initiate every suspend attempt, then you are
> forcing it to poll whenever a driver needs to block suspend.

Hmm I don't follow you. If the userspace policy daemon timer times
out, the device suspends. If the device does not suspend because of
a blocking driver, then the timers get reset and you try again based
on some event such as when the screen blanks.

Regards,

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2010/5/6 Tony Lindgren <tony@atomide.com>:
> * Arve Hjønnevåg <arve@android.com> [100505 21:11]:
>> On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Brian Swetland <swetland@google.com> [100505 16:51]:
>> >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > * Brian Swetland <swetland@google.com> [100505 14:34]:
>> >> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> >> >> >>
>> >> >> >> Oh, like tell the modem that user mode has handled the ring event and
>> >> >> >> its ok to un-block?
>> >> >> >
>> >> >> > No, that's not how it works.  It would go like this:
>> >> >> >
>> >> >> >        The modem IRQ handler queues its event to the input subsystem.
>> >> >> >        As it does so the input subsystem enables a suspend blocker,
>> >> >> >        causing the system to stay awake after the IRQ is done.
>> >> >
>> >> > How about instead the modem driver fails to suspend until it's done?
>> >> >
>> >> > Each driver could have a suspend_policy sysfs entry with options such
>> >> > as [ forced | safe ]. The default would be forced. Forced would
>> >> > be the current behaviour, while safe would refuse suspend until the
>> >> > driver is done processing.
>> >> >
>> >> >> >        The user program enables its own suspend blocker before reading
>> >> >> >        the input queue.  When the queue is empty, the input subsystem
>> >> >> >        releases its suspend blocker.
>> >> >
>> >> > And also the input layer could refuse to suspend until it's done.
>> >> >
>> >> >> >        When the user program finishes processing the event, it
>> >> >> >        releases its suspend blocker.  Now the system can go back to
>> >> >> >        sleep.
>> >> >
>> >> > And here the user space just tries to suspend again when it's done?
>> >> > It's not like you're trying to suspend all the time, so it should be
>> >> > OK to retry a few times.
>> >>
>> >> We actually are trying to suspend all the time -- that's our basic
>> >> model -- suspend whenever we can when something doesn't prevent it.
>> >
>> > Maybe that state could be kept in some userspace suspend policy manager?
>> >
>> >> >> > At no point does the user program have to communicate anything to the
>> >> >> > modem driver, and at no point does it have to do anything out of the
>> >> >> > ordinary except to enable and disable a suspend blocker.
>> >> >>
>> >> >> Exactly -- and you can use the same style of overlapping suspend
>> >> >> blockers with other drivers than input, if the input interface is not
>> >> >> suitable for the particular interaction.
>> >> >
>> >> > Would the suspend blockers still be needed somewhere in the example
>> >> > above?
>> >>
>> >> How often would we retry suspending?
>> >
>> > Well based on some timer, the same way the screen blanks? Or five
>> > seconds of no audio play? So if the suspend fails, then reset whatever
>> > userspace suspend policy timers.
>> >
>> >> If we fail to suspend, don't we have to resume all the drivers that
>> >> suspended before the one that failed?  (Maybe I'm mistaken here)
>> >
>> > Sure, but I guess that should be a rare event that only happens when
>> > you try to suspend and something interrupts the suspend.
>> >
>>
>> This is not a rare event. For example, the matrix keypad driver blocks
>> suspend when a key is down so it can scan the matrix.
>
> Sure, but how many times per day are you suspending?
>

How many times we successfully suspend is irrelevant here. If the
driver blocks suspend the number of suspend attempts depend on your
poll frequency.

>> >> With the suspend block model we know the moment we're capable of
>> >> suspending and then can suspend at that moment.  Continually trying to
>> >> suspend seems like it'd be inefficient power-wise (we're going to be
>> >> doing a lot more work as we try to suspend over and over, or we're
>> >> going to retry after a timeout and spend extra time not suspended).
>> >>
>> >> We can often spend minutes (possibly many) at a time preventing
>> >> suspend when the system is doing work that would be interrupted by a
>> >> full suspend.
>> >
>> > Maybe you a userspace suspend policy manager would do the trick if
>> > it knows when the screen is blanked and no audio has been played for
>> > five seconds etc?
>> >
>>
>> If user space has to initiate every suspend attempt, then you are
>> forcing it to poll whenever a driver needs to block suspend.
>
> Hmm I don't follow you. If the userspace policy daemon timer times
> out, the device suspends. If the device does not suspend because of
> a blocking driver, then the timers get reset and you try again based
> on some event such as when the screen blanks.
>

This retry is what I call polling. You have to keep retrying until you
succeed. Also, using the screen blank timeout for this polling is not
a good idea. You do not want to toggle the screen off and on with with
every suspend attempt.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Arve Hjønnevåg <arve@android.com> [100506 17:05]:
> 2010/5/6 Tony Lindgren <tony@atomide.com>:
> > * Arve Hjønnevåg <arve@android.com> [100505 21:11]:

<snip>

> >> This is not a rare event. For example, the matrix keypad driver blocks
> >> suspend when a key is down so it can scan the matrix.
> >
> > Sure, but how many times per day are you suspending?
> >
> 
> How many times we successfully suspend is irrelevant here. If the
> driver blocks suspend the number of suspend attempts depend on your
> poll frequency.

I guess what I'm trying to say is that a failed suspend should be
a rare event.
 
> >> >> With the suspend block model we know the moment we're capable of
> >> >> suspending and then can suspend at that moment.  Continually trying to
> >> >> suspend seems like it'd be inefficient power-wise (we're going to be
> >> >> doing a lot more work as we try to suspend over and over, or we're
> >> >> going to retry after a timeout and spend extra time not suspended).
> >> >>
> >> >> We can often spend minutes (possibly many) at a time preventing
> >> >> suspend when the system is doing work that would be interrupted by a
> >> >> full suspend.
> >> >
> >> > Maybe you a userspace suspend policy manager would do the trick if
> >> > it knows when the screen is blanked and no audio has been played for
> >> > five seconds etc?
> >> >
> >>
> >> If user space has to initiate every suspend attempt, then you are
> >> forcing it to poll whenever a driver needs to block suspend.
> >
> > Hmm I don't follow you. If the userspace policy daemon timer times
> > out, the device suspends. If the device does not suspend because of
> > a blocking driver, then the timers get reset and you try again based
> > on some event such as when the screen blanks.
> >
> 
> This retry is what I call polling. You have to keep retrying until you
> succeed. Also, using the screen blank timeout for this polling is not
> a good idea. You do not want to toggle the screen off and on with with
> every suspend attempt.

The number of retries depends on the power management policy for your
device. And that is often device and use specific.

So having to retry suspend should be a rare event. The userspace should
mostly know when it's OK to suspend.

Regards,

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> >> >> How often would we retry suspending?
> >> >
> >> > Well based on some timer, the same way the screen blanks? Or five
> >> > seconds of no audio play? So if the suspend fails, then reset whatever
> >> > userspace suspend policy timers.
> >> >
> >> >> If we fail to suspend, don't we have to resume all the drivers that
> >> >> suspended before the one that failed?  (Maybe I'm mistaken here)
> >> >
> >> > Sure, but I guess that should be a rare event that only happens when
> >> > you try to suspend and something interrupts the suspend.
> >> >
> >>
> >> This is not a rare event. For example, the matrix keypad driver blocks
> >> suspend when a key is down so it can scan the matrix.
> >
> > Sure, but how many times per day are you suspending?
> 
> How many times we successfully suspend is irrelevant here. If the
> driver blocks suspend the number of suspend attempts depend on your
> poll frequency.

Actually, this is quite interesting question I'd like answer here:

"Sure, but how many times per day are you suspending?"

I suspect it may be in 1000s, but it would be cool to get better
answer -- so that people knew what we are talking about here.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 11:43 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> >> How often would we retry suspending?
>> >> >
>> >> > Well based on some timer, the same way the screen blanks? Or five
>> >> > seconds of no audio play? So if the suspend fails, then reset whatever
>> >> > userspace suspend policy timers.
>> >> >
>> >> >> If we fail to suspend, don't we have to resume all the drivers that
>> >> >> suspended before the one that failed?  (Maybe I'm mistaken here)
>> >> >
>> >> > Sure, but I guess that should be a rare event that only happens when
>> >> > you try to suspend and something interrupts the suspend.
>> >> >
>> >>
>> >> This is not a rare event. For example, the matrix keypad driver blocks
>> >> suspend when a key is down so it can scan the matrix.
>> >
>> > Sure, but how many times per day are you suspending?
>>
>> How many times we successfully suspend is irrelevant here. If the
>> driver blocks suspend the number of suspend attempts depend on your
>> poll frequency.
>
> Actually, this is quite interesting question I'd like answer here:
>
> "Sure, but how many times per day are you suspending?"
>
> I suspect it may be in 1000s, but it would be cool to get better
> answer -- so that people knew what we are talking about here.

This is highly variable. 1000s would mean that you wake about once
every minute which is not uncommon, but more often than what typically
happens on an idle device. The nexus one has to wake up every 10
minutes to check the battery status check means your at least in the
100s, but the G1 could stay suspended for much longer than that.

The original question was about a driver blocking suspend though, and
if we were to just retry suspend until it succeeds in that case you
could easily get to 100000s suspend attempts in a day.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Wed, May 05, 2010 at 04:47:55PM -0700, Tony Lindgren wrote:

> How about instead the modem driver fails to suspend until it's done?

Because every attempted suspend requires freezing userspace, suspending 
devices until you hit one that refuses to suspend, resuming the devies 
that did suspend and then unfreezing userspace. That's not an attractive 
option.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100506 06:35]:
> On Wed, May 05, 2010 at 04:47:55PM -0700, Tony Lindgren wrote:
> 
> > How about instead the modem driver fails to suspend until it's done?
> 
> Because every attempted suspend requires freezing userspace, suspending 
> devices until you hit one that refuses to suspend, resuming the devies 
> that did suspend and then unfreezing userspace. That's not an attractive 
> option.

But how many times per day are you really suspending? Maybe few tens
of times at most if it's based on some user activity?

Or are you suspending constantly, tens of times per minute even if
there's no user activity?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:

> Or are you suspending constantly, tens of times per minute even if
> there's no user activity?

In this case you'd be repeatedly trying to suspend until the modem 
driver stopped blocking it. It's pretty much a waste.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> 
> > Or are you suspending constantly, tens of times per minute even if
> > there's no user activity?
> 
> In this case you'd be repeatedly trying to suspend until the modem 
> driver stopped blocking it. It's pretty much a waste.

But then the userspace knows you're getting data from the modem, and
it can kick some inactivity timer that determines when to try to
suspend next.

Why would you need to constantly try to suspend in that case?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Thu, May 06, 2010 at 10:14:53AM -0700, Tony Lindgren wrote:

> Why would you need to constantly try to suspend in that case?

Because otherwise you're awake for longer than you need to be.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Thu, 2010-05-06 at 10:14 -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> > 
> > > Or are you suspending constantly, tens of times per minute even if
> > > there's no user activity?
> > 
> > In this case you'd be repeatedly trying to suspend until the modem 
> > driver stopped blocking it. It's pretty much a waste.
> 
> But then the userspace knows you're getting data from the modem, and
> it can kick some inactivity timer that determines when to try to
> suspend next.

If the idle thread was doing the suspending then the inactivity timer by
it's self could block suspend. As long as the idle thread was setup to
check for timers. I'm sure that _isn't_ the point your trying to make.
It just makes gobs more sense to me that the idle thread does the
suspending .. Your idle, so depending on how long your idle then you
suspend.

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100506 10:17]:
> On Thu, May 06, 2010 at 10:14:53AM -0700, Tony Lindgren wrote:
> 
> > Why would you need to constantly try to suspend in that case?
> 
> Because otherwise you're awake for longer than you need to be.

If your system is idle and your hardware supports off-while-idle,
then that really does not matter. There's not much of a difference
in power savings, we're already talking over 10 days on batteries
with just off-while-idle on omaps.

If your userspace keeps polling and has runaway timers, then you
could suspend it's parent process to idle the system?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote:

> If your userspace keeps polling and has runaway timers, then you
> could suspend it's parent process to idle the system?

If your userspace is suspended, how does it process the events that 
generated a system wakeup? If we had a good answer to that then suspend 
blockers would be much less necessary.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100506 10:39]:
> On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote:
> 
> > If your userspace keeps polling and has runaway timers, then you
> > could suspend it's parent process to idle the system?
> 
> If your userspace is suspended, how does it process the events that 
> generated a system wakeup? If we had a good answer to that then suspend 
> blockers would be much less necessary.

Well if your hardware runs off-while-idle or even just
retention-while-idle, then the basic shell works just fine waking up
every few seconds or so.

Then you could keep init/shell/suspend policy deamon running until
it's time to suspend the whole device. To cut down runaway timers,
you could already freeze the desktop/GUI/whatever earlier.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Thu, May 06, 2010 at 11:33:35AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100506 10:39]:
> > On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote:
> > 
> > > If your userspace keeps polling and has runaway timers, then you
> > > could suspend it's parent process to idle the system?
> > 
> > If your userspace is suspended, how does it process the events that 
> > generated a system wakeup? If we had a good answer to that then suspend 
> > blockers would be much less necessary.
> 
> Well if your hardware runs off-while-idle or even just
> retention-while-idle, then the basic shell works just fine waking up
> every few seconds or so.

And the untrusted userspace code that's waiting for a network packet? 
Adding a few seconds of latency isn't an option here.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Thu, 6 May 2010, Tony Lindgren wrote:

> Well if your hardware runs off-while-idle or even just
> retention-while-idle, then the basic shell works just fine waking up
> every few seconds or so.
> 
> Then you could keep init/shell/suspend policy deamon running until
> it's time to suspend the whole device. To cut down runaway timers,
> you could already freeze the desktop/GUI/whatever earlier.

This comes down mostly to efficiency.  Although the suspend blocker
patch does the actual suspending in a workqueue thread, AFAIK there's
no reason it couldn't use a user thread instead.

The important difference lies in what happens when a suspend fails
because a driver is busy.  Without suspend blockers, the kernel has to
go through the whole procedure of freezing userspace and kernel threads
and then suspending a bunch of drivers before hitting the one that's
busy.  Then all that work has to be undone.  By contrast, with suspend
blockers the suspend attempt can fail right away with minimal overhead.

There's also a question of reliability.  With suspends controlled by 
userspace there is a possibility of races, which could lead the system 
to suspend when it shouldn't.  With control in the kernel, these races 
can be eliminated.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100506 11:39]:
> On Thu, May 06, 2010 at 11:33:35AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100506 10:39]:
> > > On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote:
> > > 
> > > > If your userspace keeps polling and has runaway timers, then you
> > > > could suspend it's parent process to idle the system?
> > > 
> > > If your userspace is suspended, how does it process the events that 
> > > generated a system wakeup? If we had a good answer to that then suspend 
> > > blockers would be much less necessary.
> > 
> > Well if your hardware runs off-while-idle or even just
> > retention-while-idle, then the basic shell works just fine waking up
> > every few seconds or so.
> 
> And the untrusted userspace code that's waiting for a network packet? 
> Adding a few seconds of latency isn't an option here.

Hmm well hitting retention and wake you can basically do between
jiffies. Hitting off mode in idle has way longer latencies,
but still in few hundred milliseconds or so, not seconds.

And cpuidle pretty much takes care of hitting the desired C state
for you. This setup is totally working on Nokia N900 for example,
it's hitting off modes in idle and running all the time, it never
suspends.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Thu, May 06, 2010 at 07:05:41PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100506 11:39]:
> > And the untrusted userspace code that's waiting for a network packet? 
> > Adding a few seconds of latency isn't an option here.
> 
> Hmm well hitting retention and wake you can basically do between
> jiffies. Hitting off mode in idle has way longer latencies,
> but still in few hundred milliseconds or so, not seconds.

The situation is this. You've frozen most of your userspace because you 
don't trust the applications. One of those applications has an open 
network socket, and policy indicates that receiving a network packet 
should generate a wakeup, allow the userspace application to handle the 
packet and then return to sleep. What mechanism do you use to do that?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 10:08]:
> On Thu, May 06, 2010 at 07:05:41PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100506 11:39]:
> > > And the untrusted userspace code that's waiting for a network packet? 
> > > Adding a few seconds of latency isn't an option here.
> > 
> > Hmm well hitting retention and wake you can basically do between
> > jiffies. Hitting off mode in idle has way longer latencies,
> > but still in few hundred milliseconds or so, not seconds.
> 
> The situation is this. You've frozen most of your userspace because you 
> don't trust the applications. One of those applications has an open 
> network socket, and policy indicates that receiving a network packet 
> should generate a wakeup, allow the userspace application to handle the 
> packet and then return to sleep. What mechanism do you use to do that?

I think the ideal way of doing this would be to have the system running
and hitting some deeper idle states using cpuidle. Then fix the apps
so timers don't wake up the system too often. Then everything would
just run in a normal way.

For the misbehaving stopped apps, maybe they could be woken
to deal with the incoming network data with sysfs_notify?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 10:35:49AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 10:08]:
> > The situation is this. You've frozen most of your userspace because you 
> > don't trust the applications. One of those applications has an open 
> > network socket, and policy indicates that receiving a network packet 
> > should generate a wakeup, allow the userspace application to handle the 
> > packet and then return to sleep. What mechanism do you use to do that?
> 
> I think the ideal way of doing this would be to have the system running
> and hitting some deeper idle states using cpuidle. Then fix the apps
> so timers don't wake up the system too often. Then everything would
> just run in a normal way.

Effective power management in the face of real-world applications is a 
reasonable usecase.

> For the misbehaving stopped apps, maybe they could be woken
> to deal with the incoming network data with sysfs_notify?

How would that work? Have the kernel send a sysfs_notify on every netwrk 
packet and have a monitor app listen for it and unfreeze the rest of 
userspace if it's frozen? That sounds expensive.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> On Fri, May 07, 2010 at 10:35:49AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100507 10:08]:
> > > The situation is this. You've frozen most of your userspace because you 
> > > don't trust the applications. One of those applications has an open 
> > > network socket, and policy indicates that receiving a network packet 
> > > should generate a wakeup, allow the userspace application to handle the 
> > > packet and then return to sleep. What mechanism do you use to do that?
> > 
> > I think the ideal way of doing this would be to have the system running
> > and hitting some deeper idle states using cpuidle. Then fix the apps
> > so timers don't wake up the system too often. Then everything would
> > just run in a normal way.
> 
> Effective power management in the face of real-world applications is a 
> reasonable usecase.

Sure there's no easy solution to misbehaving apps.

> > For the misbehaving stopped apps, maybe they could be woken
> > to deal with the incoming network data with sysfs_notify?
> 
> How would that work? Have the kernel send a sysfs_notify on every netwrk 
> packet and have a monitor app listen for it and unfreeze the rest of 
> userspace if it's frozen? That sounds expensive.

Yeah maybe there are better ways of dealing with this.

Maybe deferred timers would help some so all the apps could
be allowed to run until some power management policy decides
to suspend the whole device.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> > Effective power management in the face of real-world applications is a 
> > reasonable usecase.
> 
> Sure there's no easy solution to misbehaving apps.

That's the point of the suspend blockers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 11:23]:
> On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> > > Effective power management in the face of real-world applications is a 
> > > reasonable usecase.
> > 
> > Sure there's no easy solution to misbehaving apps.
> 
> That's the point of the suspend blockers.

To me it sounds like suspending the whole system to deal with
some misbehaving apps is an overkill. Sounds like kill -STOP
the misbehaving apps should do the trick?

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 11:43:33AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 11:23]:
> > On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote:
> > > * Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> > > > Effective power management in the face of real-world applications is a 
> > > > reasonable usecase.
> > > 
> > > Sure there's no easy solution to misbehaving apps.
> > 
> > That's the point of the suspend blockers.
> 
> To me it sounds like suspending the whole system to deal with
> some misbehaving apps is an overkill. Sounds like kill -STOP
> the misbehaving apps should do the trick?

Freezer cgroups would work better, but it doesn't really change the 
point - if that application has an open network socket, how do you know 
to resume that application when a packet comes in?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote:
> On Fri, May 07, 2010 at 11:43:33AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100507 11:23]:
> > > On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote:
> > > > * Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> > > > > Effective power management in the face of real-world applications is a 
> > > > > reasonable usecase.
> > > > 
> > > > Sure there's no easy solution to misbehaving apps.
> > > 
> > > That's the point of the suspend blockers.
> > 
> > To me it sounds like suspending the whole system to deal with
> > some misbehaving apps is an overkill. Sounds like kill -STOP
> > the misbehaving apps should do the trick?
> 
> Freezer cgroups would work better, but it doesn't really change the 
> point - if that application has an open network socket, how do you know 
> to resume that application when a packet comes in?

suspend blockers can get abused also .. I had my phone in my pocket and
accidentally ran "Google Talk" or something. It must have kept the
screen on or kept the phone from suspending, so the battery drained
completely over the course of an hour or so.

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100507 12:01]:
> On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote:
> > On Fri, May 07, 2010 at 11:43:33AM -0700, Tony Lindgren wrote:
> > > * Matthew Garrett <mjg@redhat.com> [100507 11:23]:
> > > > On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote:
> > > > > * Matthew Garrett <mjg@redhat.com> [100507 10:46]:
> > > > > > Effective power management in the face of real-world applications is a 
> > > > > > reasonable usecase.
> > > > > 
> > > > > Sure there's no easy solution to misbehaving apps.
> > > > 
> > > > That's the point of the suspend blockers.
> > > 
> > > To me it sounds like suspending the whole system to deal with
> > > some misbehaving apps is an overkill. Sounds like kill -STOP
> > > the misbehaving apps should do the trick?
> > 
> > Freezer cgroups would work better, but it doesn't really change the 
> > point - if that application has an open network socket, how do you know 
> > to resume that application when a packet comes in?

No idea, but that still sounds a better situation to me than
trying to deal with that for a suspended system! :)
 
> suspend blockers can get abused also .. I had my phone in my pocket and
> accidentally ran "Google Talk" or something. It must have kept the
> screen on or kept the phone from suspending, so the battery drained
> completely over the course of an hour or so.

Yeah I guess there's nothing stopping that.

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote:
> * Daniel Walker <dwalker@fifo99.com> [100507 12:01]:
> > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote:
> > > Freezer cgroups would work better, but it doesn't really change the 
> > > point - if that application has an open network socket, how do you know 
> > > to resume that application when a packet comes in?
> 
> No idea, but that still sounds a better situation to me than
> trying to deal with that for a suspended system! :)

Suspend blocks deal with that problem. Nobody has yet demonstrated a 
workable alternative solution.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 12:29]:
> On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote:
> > * Daniel Walker <dwalker@fifo99.com> [100507 12:01]:
> > > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote:
> > > > Freezer cgroups would work better, but it doesn't really change the 
> > > > point - if that application has an open network socket, how do you know 
> > > > to resume that application when a packet comes in?
> > 
> > No idea, but that still sounds a better situation to me than
> > trying to deal with that for a suspended system! :)
> 
> Suspend blocks deal with that problem. Nobody has yet demonstrated a 
> workable alternative solution.

Well there are obviously two paths to take, I think both of
them should work. The alternative to suspend blockers is:

- Implement a decent kernel idle function for the hardware and
  use cpuidle to change the c states. The dyntick stuff should
  already work for most hardware.

- Fix the core userspace apps to minimize timers.

- Deal with broken apps whichever way you want in the userspace.

- Optionally, do echo mem > /sys/power/state based on some
  product specific logic in the userspace.

The advantage of this is that no kernel changes are needed,
except for implementing the custom idle function for the
hardware. And this kind of setup has been in use for about
five years.

And, you can keep the system running constantly if you have
hardware that supports good idle modes, then you don't even
need to suspend at all.

The core problems I see with suspend blockers are following,
please correct me if I'm wrong:

- It is caching the value of echo mem > /sys/power/state and
  misusing it for runtime power management as the system still
  keeps running after trying to suspend. Instead, the kernel
  idle function and cpuidle should be used if the kernel keeps
  running.

- They require patching all over the drivers and userspace.

- Once the system is suspended, it does not run. And the apps
  don't behave in a standard way because the system does not
  wake to timer interrupts.

I agree that we need to be able to echo mem > /sys/power/state
in an atomic way. So if there are problems with that, those
issues should be fixed.

Cheers,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 12:55:48PM -0700, Tony Lindgren wrote:

> - Deal with broken apps whichever way you want in the userspace.

If we could do this then there would be no real need for suspend 
blockers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 13:24]:
> On Fri, May 07, 2010 at 12:55:48PM -0700, Tony Lindgren wrote:
> 
> > - Deal with broken apps whichever way you want in the userspace.
> 
> If we could do this then there would be no real need for suspend 
> blockers.

OK, I guess I don't understand all the details, need some kind
of common example I guess.

So for example, if I leave ping running in a a terminal, do you
have some way of preventing that from eating the battery?

In my scenario that program would keep on running until the
battery runs out, or something stops the program. But the system
keeps hitting retention mode in the idle loop.

How do you deal with programs like that?

Do you just suspend the whole system anyways at some point,
or do you have some other trick?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 01:53:29PM -0700, Tony Lindgren wrote:

> So for example, if I leave ping running in a a terminal, do you
> have some way of preventing that from eating the battery?

It depends on policy. If all network packets generate wakeup events then 
no, that will carry on eating battery. If ICMP doesn't generate a wakeup 
event then the process won't be run.

> Do you just suspend the whole system anyways at some point,
> or do you have some other trick?

If nothing's holding any suspend blocks then the system will enter 
suspend. If the packet generates a wakeup then the kernel would block 
suspend until userspace has had the opportunity to do so. Once userspace 
has handled the packet then it could release the block and the system 
will immediately transition back into suspend.

Here's a different example. A process is waiting for a keypress, but 
because it's badly written it's also drawing to the screen at 60 frames 
per second and preventing the system from every going to idle. How do 
you quiesce the system while still ensuring that the keypress will be 
delivered to the application?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 13:58]:
> On Fri, May 07, 2010 at 01:53:29PM -0700, Tony Lindgren wrote:
> 
> > So for example, if I leave ping running in a a terminal, do you
> > have some way of preventing that from eating the battery?
> 
> It depends on policy. If all network packets generate wakeup events then 
> no, that will carry on eating battery. If ICMP doesn't generate a wakeup 
> event then the process won't be run.
> 
> > Do you just suspend the whole system anyways at some point,
> > or do you have some other trick?
> 
> If nothing's holding any suspend blocks then the system will enter 
> suspend. If the packet generates a wakeup then the kernel would block 
> suspend until userspace has had the opportunity to do so. Once userspace 
> has handled the packet then it could release the block and the system 
> will immediately transition back into suspend.

OK, then what would I need to do to keep that ping running if I wanted to?

> Here's a different example. A process is waiting for a keypress, but 
> because it's badly written it's also drawing to the screen at 60 frames 
> per second and preventing the system from every going to idle. How do 
> you quiesce the system while still ensuring that the keypress will be 
> delivered to the application?

I guess it depends. If it's a game and I'm waiting to hit the fire
button, then I don't want the system to suspend!

It's starting to sound like you're really using suspend blocks
to "certify" that the app is safe to keep running.

Maybe it could be done with some kind of process flag instead that
would tell "this process is safe to keep running from timer point of view"
and if that flag is not set, then assume it's OK to stop the process
at any point?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote:

> Here's a different example. A process is waiting for a keypress, but 
> because it's badly written it's also drawing to the screen at 60 frames 
> per second and preventing the system from every going to idle. How do 
> you quiesce the system while still ensuring that the keypress will be 
> delivered to the application?

To me it's somewhat of a negative for suspend blockers. Since to solve
the problem you give above you would have to use a suspend blocker in an
asynchronous way (locked in an interrupt, released in a thread too)
assuming I understand your example. I've had my share of semaphore
nightmares, and I'm not too excited to see a protection scheme (i.e. a
lock) which allows asynchronous usage like suspend blockers. 

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Fri, May 7, 2010 at 2:25 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 13:58]:
>> On Fri, May 07, 2010 at 01:53:29PM -0700, Tony Lindgren wrote:
>>
>> > So for example, if I leave ping running in a a terminal, do you
>> > have some way of preventing that from eating the battery?
>>
>> It depends on policy. If all network packets generate wakeup events then
>> no, that will carry on eating battery. If ICMP doesn't generate a wakeup
>> event then the process won't be run.
>>
>> > Do you just suspend the whole system anyways at some point,
>> > or do you have some other trick?
>>
>> If nothing's holding any suspend blocks then the system will enter
>> suspend. If the packet generates a wakeup then the kernel would block
>> suspend until userspace has had the opportunity to do so. Once userspace
>> has handled the packet then it could release the block and the system
>> will immediately transition back into suspend.
>
> OK, then what would I need to do to keep that ping running if I wanted to?
>

Use a suspend blocker. For instance: "runsuspendblock ping <addr>".

>> Here's a different example. A process is waiting for a keypress, but
>> because it's badly written it's also drawing to the screen at 60 frames
>> per second and preventing the system from every going to idle. How do
>> you quiesce the system while still ensuring that the keypress will be
>> delivered to the application?
>
> I guess it depends. If it's a game and I'm waiting to hit the fire
> button, then I don't want the system to suspend!
>

We don't suspend while the screen is on. If the user pressed the power
button to turn the screen off, then I would not want the game to
prevent suspend.

> It's starting to sound like you're really using suspend blocks
> to "certify" that the app is safe to keep running.
>
> Maybe it could be done with some kind of process flag instead that
> would tell "this process is safe to keep running from timer point of view"
> and if that flag is not set, then assume it's OK to stop the process
> at any point?
>
> Regards,
>
> Tony
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 02:25:56PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 13:58]:
> > Here's a different example. A process is waiting for a keypress, but 
> > because it's badly written it's also drawing to the screen at 60 frames 
> > per second and preventing the system from every going to idle. How do 
> > you quiesce the system while still ensuring that the keypress will be 
> > delivered to the application?
> 
> I guess it depends. If it's a game and I'm waiting to hit the fire
> button, then I don't want the system to suspend!
> 
> It's starting to sound like you're really using suspend blocks
> to "certify" that the app is safe to keep running.
> 
> Maybe it could be done with some kind of process flag instead that
> would tell "this process is safe to keep running from timer point of view"
> and if that flag is not set, then assume it's OK to stop the process
> at any point?

How do you know to wake the process up in response to the keypress?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 14:34]:
> On Fri, May 07, 2010 at 02:25:56PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100507 13:58]:
> > > Here's a different example. A process is waiting for a keypress, but 
> > > because it's badly written it's also drawing to the screen at 60 frames 
> > > per second and preventing the system from every going to idle. How do 
> > > you quiesce the system while still ensuring that the keypress will be 
> > > delivered to the application?
> > 
> > I guess it depends. If it's a game and I'm waiting to hit the fire
> > button, then I don't want the system to suspend!
> > 
> > It's starting to sound like you're really using suspend blocks
> > to "certify" that the app is safe to keep running.
> > 
> > Maybe it could be done with some kind of process flag instead that
> > would tell "this process is safe to keep running from timer point of view"
> > and if that flag is not set, then assume it's OK to stop the process
> > at any point?
> 
> How do you know to wake the process up in response to the keypress?

Does it matter for processes that are not "certified"? Maybe you
could assume that you can keep it stopped until the screen is on
again, or some other policy.

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 02:42:11PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100507 14:34]:
> > How do you know to wake the process up in response to the keypress?
> 
> Does it matter for processes that are not "certified"? Maybe you
> could assume that you can keep it stopped until the screen is on
> again, or some other policy.

Yes, it matters. You don't necessarily know whether to turn the screen 
on until the app has had an opportunity to process the event. This is 
exactly the kind of use case that suspend blocks are intended to allow, 
so alternatives that don't permit that kind of use case aren't really 
adequate alternatives.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100507 14:44]:
> On Fri, May 07, 2010 at 02:42:11PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100507 14:34]:
> > > How do you know to wake the process up in response to the keypress?
> > 
> > Does it matter for processes that are not "certified"? Maybe you
> > could assume that you can keep it stopped until the screen is on
> > again, or some other policy.
> 
> Yes, it matters. You don't necessarily know whether to turn the screen 
> on until the app has had an opportunity to process the event. This is 
> exactly the kind of use case that suspend blocks are intended to allow, 
> so alternatives that don't permit that kind of use case aren't really 
> adequate alternatives.

Hmm, I'm thinking there would not be any need to turn the screen on
for the broken apps until some other event such as a tap on the screen
triggers the need to turn the screen on.

If it's a critical app, then it should be fixed so it's safe to keep
running.

And yeah, I guess you could cgroups to categorize "timer certified"
and "broken" apps.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 03:00:26PM -0700, Tony Lindgren wrote:

> Hmm, I'm thinking there would not be any need to turn the screen on
> for the broken apps until some other event such as a tap on the screen
> triggers the need to turn the screen on.
> 
> If it's a critical app, then it should be fixed so it's safe to keep
> running.
> 
> And yeah, I guess you could cgroups to categorize "timer certified"
> and "broken" apps.

This is a perfectly valid model, but it's not one that matches Android.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Fri, May 7, 2010 at 2:30 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote:
>
>> Here's a different example. A process is waiting for a keypress, but
>> because it's badly written it's also drawing to the screen at 60 frames
>> per second and preventing the system from every going to idle. How do
>> you quiesce the system while still ensuring that the keypress will be
>> delivered to the application?
>
> To me it's somewhat of a negative for suspend blockers. Since to solve
> the problem you give above you would have to use a suspend blocker in an
> asynchronous way (locked in an interrupt, released in a thread too)
> assuming I understand your example. I've had my share of semaphore
> nightmares, and I'm not too excited to see a protection scheme (i.e. a
> lock) which allows asynchronous usage like suspend blockers.
>

Why do you think this? The example in the documentation describe how
we handle key events.


-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 02:30:20PM -0700, Daniel Walker wrote:
> On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote:
> 
> > Here's a different example. A process is waiting for a keypress, but 
> > because it's badly written it's also drawing to the screen at 60 frames 
> > per second and preventing the system from every going to idle. How do 
> > you quiesce the system while still ensuring that the keypress will be 
> > delivered to the application?
> 
> To me it's somewhat of a negative for suspend blockers. Since to solve
> the problem you give above you would have to use a suspend blocker in an
> asynchronous way (locked in an interrupt, released in a thread too)
> assuming I understand your example. I've had my share of semaphore
> nightmares, and I'm not too excited to see a protection scheme (i.e. a
> lock) which allows asynchronous usage like suspend blockers. 

Check the input patch for an example of this.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Fri, 2010-05-07 at 14:35 -0700, Arve Hjønnevåg wrote:
> On Fri, May 7, 2010 at 2:30 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote:
> >
> >> Here's a different example. A process is waiting for a keypress, but
> >> because it's badly written it's also drawing to the screen at 60 frames
> >> per second and preventing the system from every going to idle. How do
> >> you quiesce the system while still ensuring that the keypress will be
> >> delivered to the application?
> >
> > To me it's somewhat of a negative for suspend blockers. Since to solve
> > the problem you give above you would have to use a suspend blocker in an
> > asynchronous way (locked in an interrupt, released in a thread too)
> > assuming I understand your example. I've had my share of semaphore
> > nightmares, and I'm not too excited to see a protection scheme (i.e. a
> > lock) which allows asynchronous usage like suspend blockers.
> >
> 
> Why do you think this? The example in the documentation describe how
> we handle key events.

+- The Keypad driver gets an interrupt. It then calls suspend_block on the
+  keypad-scan suspend_blocker 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 calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should leave the screen off, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.

This? Isn't this asynchronous on the input-event-queue since it's taken
in the interrupt , and release in the userspace thread?

Daniel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100506 11:42]:
> On Thu, 6 May 2010, Tony Lindgren wrote:
> 
> > Well if your hardware runs off-while-idle or even just
> > retention-while-idle, then the basic shell works just fine waking up
> > every few seconds or so.
> > 
> > Then you could keep init/shell/suspend policy deamon running until
> > it's time to suspend the whole device. To cut down runaway timers,
> > you could already freeze the desktop/GUI/whatever earlier.
> 
> This comes down mostly to efficiency.  Although the suspend blocker
> patch does the actual suspending in a workqueue thread, AFAIK there's
> no reason it couldn't use a user thread instead.
> 
> The important difference lies in what happens when a suspend fails
> because a driver is busy.  Without suspend blockers, the kernel has to
> go through the whole procedure of freezing userspace and kernel threads
> and then suspending a bunch of drivers before hitting the one that's
> busy.  Then all that work has to be undone.  By contrast, with suspend
> blockers the suspend attempt can fail right away with minimal overhead.

But does that really matter if you're only few tens of times times per
day or so? I don't understand why you would want to try to suspend except
after some timeout of no user or network activity.
 
> There's also a question of reliability.  With suspends controlled by 
> userspace there is a possibility of races, which could lead the system 
> to suspend when it shouldn't.  With control in the kernel, these races 
> can be eliminated.

I agree the suspend needs to happen without races. But I think the
logic for when to suspend should be done in the userspace as it
can be device or user specific.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> > > Why would you need to constantly try to suspend in that case?
> > 
> > Because otherwise you're awake for longer than you need to be.
> 
> If your system is idle and your hardware supports off-while-idle,
> then that really does not matter. There's not much of a difference
> in power savings, we're already talking over 10 days on batteries
> with just off-while-idle on omaps.

Makes me wish g1 was omap based... it looks like you have superior hw.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Brian Swetland]

On Fri, May 28, 2010 at 6:29 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > > Why would you need to constantly try to suspend in that case?
>> >
>> > Because otherwise you're awake for longer than you need to be.
>>
>> If your system is idle and your hardware supports off-while-idle,
>> then that really does not matter. There's not much of a difference
>> in power savings, we're already talking over 10 days on batteries
>> with just off-while-idle on omaps.
>
> Makes me wish g1 was omap based... it looks like you have superior hw.

G1 will happily do 10 days idle (radio on) under typical network
conditions (roughly 4-5mA draw at the battery average in paging mode)
if you have data disabled and there's no reason for it to wake up,
process events, chat on the data network etc.  It'll go 25-30 days in
"airplane mode" (radio off) provided there are not excessive wakeups.

If you happen to be running a perfect userspace where every thread in
every process is blocked on something, it'll hit the exact same power
state out of idle.  If you have a less optimal userspace or random
third party nonoptimal apps, this becomes much harder, of course.
Which is why we do the wakelock thing.

OMAP does have a lot of nice auto-clock-down features compared to some
other SoCs, sometimes simplifying other parts of power management.

Brian

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100506 10:30]:
> On Thu, 2010-05-06 at 10:14 -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> > > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> > > 
> > > > Or are you suspending constantly, tens of times per minute even if
> > > > there's no user activity?
> > > 
> > > In this case you'd be repeatedly trying to suspend until the modem 
> > > driver stopped blocking it. It's pretty much a waste.
> > 
> > But then the userspace knows you're getting data from the modem, and
> > it can kick some inactivity timer that determines when to try to
> > suspend next.
> 
> If the idle thread was doing the suspending then the inactivity timer by
> it's self could block suspend. As long as the idle thread was setup to
> check for timers. I'm sure that _isn't_ the point your trying to make.
> It just makes gobs more sense to me that the idle thread does the
> suspending .. Your idle, so depending on how long your idle then you
> suspend.

The alternative logic I'm suggesting is get the GUI into idle mode as
soon as possible, then limp along with off-while-idle or
retention-while-idle until some timer expires, then suspend the whole
device.

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Thu, 2010-05-06 at 11:36 -0700, Tony Lindgren wrote:
> * Daniel Walker <dwalker@fifo99.com> [100506 10:30]:
> > On Thu, 2010-05-06 at 10:14 -0700, Tony Lindgren wrote:
> > > * Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> > > > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> > > > 
> > > > > Or are you suspending constantly, tens of times per minute even if
> > > > > there's no user activity?
> > > > 
> > > > In this case you'd be repeatedly trying to suspend until the modem 
> > > > driver stopped blocking it. It's pretty much a waste.
> > > 
> > > But then the userspace knows you're getting data from the modem, and
> > > it can kick some inactivity timer that determines when to try to
> > > suspend next.
> > 
> > If the idle thread was doing the suspending then the inactivity timer by
> > it's self could block suspend. As long as the idle thread was setup to
> > check for timers. I'm sure that _isn't_ the point your trying to make.
> > It just makes gobs more sense to me that the idle thread does the
> > suspending .. Your idle, so depending on how long your idle then you
> > suspend.
> 
> The alternative logic I'm suggesting is get the GUI into idle mode as
> soon as possible, then limp along with off-while-idle or
> retention-while-idle until some timer expires, then suspend the whole
> device.

Could you elaborate on "off-while-idle" and "retention-while-idle" ? I'm
not sure I follow what you mean.

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100506 12:07]:
> On Thu, 2010-05-06 at 11:36 -0700, Tony Lindgren wrote:
> > * Daniel Walker <dwalker@fifo99.com> [100506 10:30]:
> > > On Thu, 2010-05-06 at 10:14 -0700, Tony Lindgren wrote:
> > > > * Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> > > > > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> > > > > 
> > > > > > Or are you suspending constantly, tens of times per minute even if
> > > > > > there's no user activity?
> > > > > 
> > > > > In this case you'd be repeatedly trying to suspend until the modem 
> > > > > driver stopped blocking it. It's pretty much a waste.
> > > > 
> > > > But then the userspace knows you're getting data from the modem, and
> > > > it can kick some inactivity timer that determines when to try to
> > > > suspend next.
> > > 
> > > If the idle thread was doing the suspending then the inactivity timer by
> > > it's self could block suspend. As long as the idle thread was setup to
> > > check for timers. I'm sure that _isn't_ the point your trying to make.
> > > It just makes gobs more sense to me that the idle thread does the
> > > suspending .. Your idle, so depending on how long your idle then you
> > > suspend.
> > 
> > The alternative logic I'm suggesting is get the GUI into idle mode as
> > soon as possible, then limp along with off-while-idle or
> > retention-while-idle until some timer expires, then suspend the whole
> > device.
> 
> Could you elaborate on "off-while-idle" and "retention-while-idle" ? I'm
> not sure I follow what you mean.

Oh some SoC devices like omap hit retention or off modes in the idle loop.
That brings down the idle consumption of a running system to minimal
levels. It's basically the same as suspending the device in every idle loop.

The system wakes up every few seconds or so, but that already provides
battery life of over ten days or so on an idle system. Of course the
wakeup latencies are in milliseconds then.

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Thu, 2010-05-06 at 19:00 -0700, Tony Lindgren wrote:

> Oh some SoC devices like omap hit retention or off modes in the idle loop.
> That brings down the idle consumption of a running system to minimal
> levels. It's basically the same as suspending the device in every idle loop.
> 
> The system wakes up every few seconds or so, but that already provides
> battery life of over ten days or so on an idle system. Of course the
> wakeup latencies are in milliseconds then.

MSM doesn't have those power states unfortunately .. Your kind of
suggesting what I was suggesting in that we should suspend in idle. Your
hardware can do it easier tho since your have power states that are
equal to suspend.

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 10:20:37AM -0700, Daniel Walker wrote:

> MSM doesn't have those power states unfortunately .. Your kind of
> suggesting what I was suggesting in that we should suspend in idle. Your
> hardware can do it easier tho since your have power states that are
> equal to suspend.

If your wakeup latencies are sufficiently low and you have fine-grained 
enough control over your hardware then suspend in idle is a reasonable 
thing to do - but if you have a userspace app that's spinning then 
that doesn't solve the issue.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote:
> On Fri, May 07, 2010 at 10:20:37AM -0700, Daniel Walker wrote:
> 
> > MSM doesn't have those power states unfortunately .. Your kind of
> > suggesting what I was suggesting in that we should suspend in idle. Your
> > hardware can do it easier tho since your have power states that are
> > equal to suspend.
> 
> If your wakeup latencies are sufficiently low and you have fine-grained 
> enough control over your hardware then suspend in idle is a reasonable 
> thing to do - but if you have a userspace app that's spinning then 
> that doesn't solve the issue.

If there's a userspace app spinning then you don't go idle (or that's my
assumption anyway). You mean like repeatedly blocking and unblocking
right?

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Fri, May 07, 2010 at 10:40:43AM -0700, Daniel Walker wrote:
> On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote:
> > If your wakeup latencies are sufficiently low and you have fine-grained 
> > enough control over your hardware then suspend in idle is a reasonable 
> > thing to do - but if you have a userspace app that's spinning then 
> > that doesn't solve the issue.
> 
> If there's a userspace app spinning then you don't go idle (or that's my
> assumption anyway). You mean like repeatedly blocking and unblocking
> right?

Right, that's the problem. idle-based suspend works fine if your 
applications let the system go idle, but if your applications are 
anything other than absolutely perfect in this respect then you consume 
significant power even if the device is sitting unused in someone's 
pocket.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Daniel Walker]

On Fri, 2010-05-07 at 18:51 +0100, Matthew Garrett wrote:
> On Fri, May 07, 2010 at 10:40:43AM -0700, Daniel Walker wrote:
> > On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote:
> > > If your wakeup latencies are sufficiently low and you have fine-grained 
> > > enough control over your hardware then suspend in idle is a reasonable 
> > > thing to do - but if you have a userspace app that's spinning then 
> > > that doesn't solve the issue.
> > 
> > If there's a userspace app spinning then you don't go idle (or that's my
> > assumption anyway). You mean like repeatedly blocking and unblocking
> > right?
> 
> Right, that's the problem. idle-based suspend works fine if your 
> applications let the system go idle, but if your applications are 
> anything other than absolutely perfect in this respect then you consume 
> significant power even if the device is sitting unused in someone's 
> pocket.

True .. I'd wonder how an OMAP based devices deal with that issue, since
they would have that exact problem. According to what Tony is telling
us. Actually a bogus userspace can do a lot more than just consume power
you could hang the system too.

Daniel

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100507 10:56]:
> On Fri, 2010-05-07 at 18:51 +0100, Matthew Garrett wrote:
> > On Fri, May 07, 2010 at 10:40:43AM -0700, Daniel Walker wrote:
> > > On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote:
> > > > If your wakeup latencies are sufficiently low and you have fine-grained 
> > > > enough control over your hardware then suspend in idle is a reasonable 
> > > > thing to do - but if you have a userspace app that's spinning then 
> > > > that doesn't solve the issue.
> > > 
> > > If there's a userspace app spinning then you don't go idle (or that's my
> > > assumption anyway). You mean like repeatedly blocking and unblocking
> > > right?
> > 
> > Right, that's the problem. idle-based suspend works fine if your 
> > applications let the system go idle, but if your applications are 
> > anything other than absolutely perfect in this respect then you consume 
> > significant power even if the device is sitting unused in someone's 
> > pocket.
> 
> True .. I'd wonder how an OMAP based devices deal with that issue, since
> they would have that exact problem. According to what Tony is telling
> us. Actually a bogus userspace can do a lot more than just consume power
> you could hang the system too.

There's nothing being done on omaps specifically, up to the device
user space to deal with that. From the kernel point of view the
omaps just run, and if idle enough, the device starts hitting the
retention and off modes in idle. But the system keeps on running
all the time, no need to suspend really. 

I don't think there's a generic solution to the misbehaving apps.
I know a lot of work has been done over past five years or so
to minimize the timer usage in various apps. But if I installed
some app that keeps the system busy, it would drain the battery.

I guess some apps could be just stopped when the screen blanks
unless somehow certified for the timer usage or something similar..

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100507 10:15]:
> On Thu, 2010-05-06 at 19:00 -0700, Tony Lindgren wrote:
> 
> > Oh some SoC devices like omap hit retention or off modes in the idle loop.
> > That brings down the idle consumption of a running system to minimal
> > levels. It's basically the same as suspending the device in every idle loop.
> > 
> > The system wakes up every few seconds or so, but that already provides
> > battery life of over ten days or so on an idle system. Of course the
> > wakeup latencies are in milliseconds then.
> 
> MSM doesn't have those power states unfortunately .. Your kind of
> suggesting what I was suggesting in that we should suspend in idle. Your
> hardware can do it easier tho since your have power states that are
> equal to suspend.

You might be able to implement suspend-while-idle with cpuidle and
a custom idle function on MSM. That is if MSM supports waking to
a timer event and some device interrupts. However, if it only wakes
to pressing some power button, then you will get missed timers
and the system won't behave in a normal way.

Maybe you could still kill -STOP the misbehaving apps, then keep the
idle system running until some timer expires, then when no activity,
echo mem > /sys/power/state?

Regards,

Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[mgross]

On Thu, May 06, 2010 at 10:14:53AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100506 10:05]:
> > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> > 
> > > Or are you suspending constantly, tens of times per minute even if
> > > there's no user activity?
> > 
> > In this case you'd be repeatedly trying to suspend until the modem 
> > driver stopped blocking it. It's pretty much a waste.
> 
> But then the userspace knows you're getting data from the modem, and
> it can kick some inactivity timer that determines when to try to
> suspend next.

Thank you for thinking.

--mgross

> 
> Why would you need to constantly try to suspend in that case?
> 
> Regards,
> 
> Tony

Re: [PATCH 1/8] PM: Add suspend block api.

[mgross]

On Thu, May 06, 2010 at 06:09:56PM +0100, Matthew Garrett wrote:
> On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
> 
> > Or are you suspending constantly, tens of times per minute even if
> > there's no user activity?
> 
> In this case you'd be repeatedly trying to suspend until the modem 
> driver stopped blocking it. It's pretty much a waste.


lets not go off in the weeds for the wrong things now.  The answer to
the retry is at most one time.  The first time would be blocked, then
the suspend enable would need to re-enabled under user mode control that
would, buy that time, know it has to ack to the modem to stop rejecting
the suspend attempt.

duh.

--mgross

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Thu, May 6, 2010 at 8:45 PM, mgross <markgross@thegnar.org> wrote:
> On Thu, May 06, 2010 at 06:09:56PM +0100, Matthew Garrett wrote:
>> On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote:
>>
>> > Or are you suspending constantly, tens of times per minute even if
>> > there's no user activity?
>>
>> In this case you'd be repeatedly trying to suspend until the modem
>> driver stopped blocking it. It's pretty much a waste.
>
>
> lets not go off in the weeds for the wrong things now.  The answer to
> the retry is at most one time.  The first time would be blocked, then
> the suspend enable would need to re-enabled under user mode control that
> would, buy that time, know it has to ack to the modem to stop rejecting
> the suspend attempt.
>

This is incorrect in the general case. User-space has no way of
knowing which driver blocked suspend or when it will stop blocking
suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Tue, 4 May 2010, mark gross wrote:

> On Tue, May 04, 2010 at 09:59:59AM -0400, Alan Stern wrote:
> > On Mon, 3 May 2010, mark gross wrote:
> > 
> > > You know things would be so much easier if the policy was a one-shot
> > > styled thing.  i.e. when enabled it does what it does, but upon resume
> > > the policy must be re-enabled by user mode to get the opportunistic
> > > behavior.  That way we don't need to grab the suspend blocker from the
> > > wake up irq handler all the way up to user mode as the example below
> > > calls out.  I suppose doing this would put a burden on the user mode code
> > > to keep track of if it has no pending blockers registered after a wake
> > > up from the suspend.  but that seems nicer to me than sprinkling
> > > overlapping blocker critical sections from the mettle up to user mode.
> > > 
> > > Please consider making the policy a one shot API that needs to be
> > > re-enabled after resume by user mode.  That would remove my issue with
> > > the design.
> > 
> > This won't work right if a second IRQ arrives while the first is being
> > processed.  Suppose the kernel driver for the second IRQ doesn't
> > activate a suspend blocker, and suppose all the userspace handlers for
> > the first IRQ end (and the opportunistic policy is re-enabled) before
> > the userspace handler for the second IRQ can start.  Then the system
> > will go back to sleep before userspace can handle the second IRQ.
> >
> 
> What?  If the suspend blocker API was a one shot styled api, after the
> suspend, the one shot is over and the behavior is that you do not fall
> back into suspend again until user mode re-enables the one-shot
> behavior.  

I was referring to your sentence: "That way we don't need to grab the 
suspend blocker from the wake up irq handler all the way up to user 
mode..."  The problem arises when kernel handlers don't do _something_ 
to prevent another suspend from occurring too soon.

> With what I am proposing the next suspend would not happen until the
> user mode code re-enables the suspend blocking behavior.  It would much
> cleaner for everyone and I see zero down side WRT the example you just
> posted.  
> 
> If user mode triggers a suspend by releasing the last blocker, you have
> until pm_suspend('mem') turns off interrupts to cancel it.  That race
> will never go away. 

(Actually the kernel can cancel the suspend even after interrupts are
turned off, if it has a reason to do so.)

In theory the race between interrupts and suspend don't need to be a
problem.  In practice it still is -- the PM core needs a few changes to
allow wakeup interrupts to cancel a suspend in progress.  Regardless, 
that's not what I was talking about.

> Let me think this through, please check that I'm understanding the issue
> please:
> 1) one-shot policy enable blocker PM suspend behavior;
> 2) release last blocker and call pm_suspend('mem') and suspend all the
> way down.
> 3) get wake up event, one-shot policy over, no-blockers in list
> 4) go all the way to user mode, 
> 5) user mode decides to not grab a blocker, and re-enables one-shot
> policy
> 6) pm_suspend('mem') called
> 7) interrupt comes in (say the modem rings)
> 8) modem driver handler needs to returns fail from pm_suspend call back,
> device resumes (I am proposing changing the posted api for doing this.)
> 9) user mode figures out one-shot needs to be re-enabled and it grabs a
> blocker to handle the call and re-enables the one-shot.

This is not the scenario I was describing.  Here's what I had in mind:

1) The system is asleep
2) Wakeup event occurs, one-shot policy over
3) Go all the way to user mode
4) A second wakeup interrupt occurs (say the modem rings)
5) The modem driver does not enable any suspend blockers
6) The modem driver queues an input event for userspace
7) The userspace handler invoked during 3) finishes and re-enables
	the one-shot policy
8) No suspend blockers are enabled, so the system goes to sleep
9) The userspace handler for the input event in 6) doesn't get to run

> So the real problem grabbing blockers from ISR's trying to solve is to
> reduce the window of time where a pm_suspend('mem') can be canceled.

No.  The real problem is how ISRs should prevent the system from
suspending before the events they generate can be handled by userspace.

> My proposal is to;
> 1) change the kernel blocker api to be
> "cancel-one-shot-policy-enable" that can be called from the ISR's for
> the wake up devices before the IRQ's are disabled to cancel an in-flight
> suspend.  I would make it 2 macros one goes in the pm_suspend callback
> to return fail, and the other in the ISR to disable the one-shot-policy.
>  
> 2) make the policy a one shot that user mode must re-enable after each
> suspend attempted.

Neither of these solves the race I described.

> Would it help if I coded up the above proposal as patch to the current
> (rev-6) of the blocker patchset?  I'm offering.
> 
> Because this part of the current design is broken, in that it demands
> the sprinkling of blocker critical sections from the hardware up to the
> user mode.  Its ugly, hard to get right and if more folks would take a
> look at how well it worked out for the existing kernels on
> android.git.kernel.org/kernels/ perhaps it would get more attention.

I agree, it is ugly and probably hard to get right.  But something like 
it is necessary to solve this race.

> Finally, as an aside, lets look at the problem with the posted rev-6
> patches:
> 1) enable suspend blocker policy
> 2) release user-mode blocker
> 3) start suspend
> 4) get a modem interrupt (incoming call)
> 5) ooops, IRQ came in after pm_suspend('mem') turned off interrupts.
> bummer for you, thats life with this design.  Better hope your modem
> hardware is modified to keep pulling on that wake up line because you're
> past the point of no return now and going to suspend.

That is not a problem for level-sensitive IRQs.  If interrupts have
been turned off then the modem will not receive any commands telling
it to stop requesting an interrupt.  So the IRQ line will remain active 
until the system goes to sleep, at which point it will immediately 
wake up the system.

For edge-sensitive interrupts the situation isn't as simple.  The
low-level IRQ code must handle this somehow.

> Grabbing a blocker in the ISR doesn't solve this.  So your hardware
> needs to have a persistent wake up trigger that is robust against this
> scenario.  And, if you have such hardware then why are we killing
> ourselves to maximize the window of time between pm_suspend('mem') and
> platform suspend where you can cancel the suspend?  The hardware will
> simply wake up anyway.

That's not what we are killing ourselves for.  The point of suspend
blockers is not to prevent races with the hardware.  It is to prevent 
userspace from being frozen while there's still work to be done.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Tue, May 04, 2010 at 01:16:25PM -0400, Alan Stern wrote:
> On Tue, 4 May 2010, mark gross wrote:
> 
> > On Tue, May 04, 2010 at 09:59:59AM -0400, Alan Stern wrote:
> > > On Mon, 3 May 2010, mark gross wrote:
> > > 
> > > > You know things would be so much easier if the policy was a one-shot
> > > > styled thing.  i.e. when enabled it does what it does, but upon resume
> > > > the policy must be re-enabled by user mode to get the opportunistic
> > > > behavior.  That way we don't need to grab the suspend blocker from the
> > > > wake up irq handler all the way up to user mode as the example below
> > > > calls out.  I suppose doing this would put a burden on the user mode code
> > > > to keep track of if it has no pending blockers registered after a wake
> > > > up from the suspend.  but that seems nicer to me than sprinkling
> > > > overlapping blocker critical sections from the mettle up to user mode.
> > > > 
> > > > Please consider making the policy a one shot API that needs to be
> > > > re-enabled after resume by user mode.  That would remove my issue with
> > > > the design.
> > > 
> > > This won't work right if a second IRQ arrives while the first is being
> > > processed.  Suppose the kernel driver for the second IRQ doesn't
> > > activate a suspend blocker, and suppose all the userspace handlers for
> > > the first IRQ end (and the opportunistic policy is re-enabled) before
> > > the userspace handler for the second IRQ can start.  Then the system
> > > will go back to sleep before userspace can handle the second IRQ.
> > >
> > 
> > What?  If the suspend blocker API was a one shot styled api, after the
> > suspend, the one shot is over and the behavior is that you do not fall
> > back into suspend again until user mode re-enables the one-shot
> > behavior.  
> 
> I was referring to your sentence: "That way we don't need to grab the 
> suspend blocker from the wake up irq handler all the way up to user 
> mode..."  The problem arises when kernel handlers don't do _something_ 
> to prevent another suspend from occurring too soon.
> 
> > With what I am proposing the next suspend would not happen until the
> > user mode code re-enables the suspend blocking behavior.  It would much
> > cleaner for everyone and I see zero down side WRT the example you just
> > posted.  
> > 
> > If user mode triggers a suspend by releasing the last blocker, you have
> > until pm_suspend('mem') turns off interrupts to cancel it.  That race
> > will never go away. 
> 
> (Actually the kernel can cancel the suspend even after interrupts are
> turned off, if it has a reason to do so.)
> 
> In theory the race between interrupts and suspend don't need to be a
> problem.  In practice it still is -- the PM core needs a few changes to
> allow wakeup interrupts to cancel a suspend in progress.  Regardless, 
> that's not what I was talking about.
> 
> > Let me think this through, please check that I'm understanding the issue
> > please:
> > 1) one-shot policy enable blocker PM suspend behavior;
> > 2) release last blocker and call pm_suspend('mem') and suspend all the
> > way down.
> > 3) get wake up event, one-shot policy over, no-blockers in list
> > 4) go all the way to user mode, 
> > 5) user mode decides to not grab a blocker, and re-enables one-shot
> > policy
> > 6) pm_suspend('mem') called
> > 7) interrupt comes in (say the modem rings)
> > 8) modem driver handler needs to returns fail from pm_suspend call back,
> > device resumes (I am proposing changing the posted api for doing this.)
> > 9) user mode figures out one-shot needs to be re-enabled and it grabs a
> > blocker to handle the call and re-enables the one-shot.
> 
> This is not the scenario I was describing.  Here's what I had in mind:
> 
> 1) The system is asleep
> 2) Wakeup event occurs, one-shot policy over
> 3) Go all the way to user mode
> 4) A second wakeup interrupt occurs (say the modem rings)
> 5) The modem driver does not enable any suspend blockers
> 6) The modem driver queues an input event for userspace
> 7) The userspace handler invoked during 3) finishes and re-enables
> 	the one-shot policy
> 8) No suspend blockers are enabled, so the system goes to sleep
In my sequence above I had the modem driver "magically" knowing to fail
this suspend attempt.  (that "magic" wasn't fully thought out though.)
> 9) The userspace handler for the input event in 6) doesn't get to run
> 
> > So the real problem grabbing blockers from ISR's trying to solve is to
> > reduce the window of time where a pm_suspend('mem') can be canceled.
> 
> No.  The real problem is how ISRs should prevent the system from
> suspending before the events they generate can be handled by userspace.

Thanks, I think I'm starting to get it.  From this it seems that the
system integrator needs to identify those wake up sources that need to
be able to block a suspend, and figure out a way of acknowledging from
user mode, that its now ok to allow a suspend to happen.

The rev-6 proposed way is for the integrator to implement overlapping
blocker sections from ISR up to user mode for selected wake up devices
(i.e. the modem)

There *has* to be a better way.

Can't we have some notification based thing that supports user mode
acks through a misc device or sysfs thing?   Anything to avoid the
overlapping blocker sections. 


> > My proposal is to;
> > 1) change the kernel blocker api to be
> > "cancel-one-shot-policy-enable" that can be called from the ISR's for
> > the wake up devices before the IRQ's are disabled to cancel an in-flight
> > suspend.  I would make it 2 macros one goes in the pm_suspend callback
> > to return fail, and the other in the ISR to disable the one-shot-policy.
> >  
> > 2) make the policy a one shot that user mode must re-enable after each
> > suspend attempted.
> 
> Neither of these solves the race I described.

True, you need an ack back from user mode for when its ok to allow
suspend to happen.  This ack is device specific and needs to be custom
built per product to its wake up sources.

> 
> > Would it help if I coded up the above proposal as patch to the current
> > (rev-6) of the blocker patchset?  I'm offering.
> > 
> > Because this part of the current design is broken, in that it demands
> > the sprinkling of blocker critical sections from the hardware up to the
> > user mode.  Its ugly, hard to get right and if more folks would take a
> > look at how well it worked out for the existing kernels on
> > android.git.kernel.org/kernels/ perhaps it would get more attention.
> 
> I agree, it is ugly and probably hard to get right.  But something like 
> it is necessary to solve this race.
> 
> > Finally, as an aside, lets look at the problem with the posted rev-6
> > patches:
> > 1) enable suspend blocker policy
> > 2) release user-mode blocker
> > 3) start suspend
> > 4) get a modem interrupt (incoming call)
> > 5) ooops, IRQ came in after pm_suspend('mem') turned off interrupts.
> > bummer for you, thats life with this design.  Better hope your modem
> > hardware is modified to keep pulling on that wake up line because you're
> > past the point of no return now and going to suspend.
> 
> That is not a problem for level-sensitive IRQs.  If interrupts have
> been turned off then the modem will not receive any commands telling
> it to stop requesting an interrupt.  So the IRQ line will remain active 
> until the system goes to sleep, at which point it will immediately 
> wake up the system.
> 
> For edge-sensitive interrupts the situation isn't as simple.  The
> low-level IRQ code must handle this somehow.
> 
> > Grabbing a blocker in the ISR doesn't solve this.  So your hardware
> > needs to have a persistent wake up trigger that is robust against this
> > scenario.  And, if you have such hardware then why are we killing
> > ourselves to maximize the window of time between pm_suspend('mem') and
> > platform suspend where you can cancel the suspend?  The hardware will
> > simply wake up anyway.
> 
> That's not what we are killing ourselves for.  The point of suspend
> blockers is not to prevent races with the hardware.  It is to prevent 
> userspace from being frozen while there's still work to be done.
ok.

I'm going to think on this some more.  There must be a cleaner way to do
this.

--mgross
 

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Tue, May 04, 2010 at 06:50:50PM -0700, mark gross wrote:

> In my sequence above I had the modem driver "magically" knowing to fail
> this suspend attempt.  (that "magic" wasn't fully thought out though.)

If the modem driver knows to "magically" fail a suspend attempt until it 
knows that userspace has consumed the event, you have something that 
looks awfully like suspend blockers.

> There *has* to be a better way.

But nobody has reasonably proposed one and demonstrated that it works. 
We've had over a year to do so and failed, and I think it's pretty 
unreasonable to ask Google to attempt to rearchitect based on a 
hypothetical.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Tue, 4 May 2010, mark gross wrote:

> Thanks, I think I'm starting to get it.  From this it seems that the
> system integrator needs to identify those wake up sources that need to
> be able to block a suspend, and figure out a way of acknowledging from
> user mode, that its now ok to allow a suspend to happen.

The second part is easy.  Userspace doesn't need to do anything special 
to acknowledge that a suspend is now okay; it just has to remove the 
conditions that led the driver to block suspends in the first place.

For example, if suspends are blocked because some input event has been
queued, emptying the input event queue should unblock suspends.

> The rev-6 proposed way is for the integrator to implement overlapping
> blocker sections from ISR up to user mode for selected wake up devices
> (i.e. the modem)
> 
> There *has* to be a better way.

Why?  What's wrong with overlapping blockers?  It's a very common
idiom.  For example, the same sort of thing is used when locking
subtrees of a tree: You lock the root node, and then use overlapping
locks on the nodes leading down to the subtree you're interested in.

> Can't we have some notification based thing that supports user mode
> acks through a misc device or sysfs thing?   Anything to avoid the
> overlapping blocker sections. 

Userspace acks aren't the issue; the issue is how (and when) kernel 
drivers should initiate a blocker.  Switching to notifications, misc 
devices, or sysfs won't help solve this issue.

> True, you need an ack back from user mode for when its ok to allow
> suspend to happen.  This ack is device specific and needs to be custom
> built per product to its wake up sources.

No and no.  Nothing special is needed.  All userspace needs to do is 
remove the condition that led to the blocker being enabled initially -- 
which is exactly what userspace would do normally anyway.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Wed, May 05, 2010 at 02:31:31PM +0100, Matthew Garrett wrote:
> On Tue, May 04, 2010 at 06:50:50PM -0700, mark gross wrote:
> 
> > In my sequence above I had the modem driver "magically" knowing to fail
> > this suspend attempt.  (that "magic" wasn't fully thought out though.)
> 
> If the modem driver knows to "magically" fail a suspend attempt until it 
> knows that userspace has consumed the event, you have something that 
> looks awfully like suspend blockers.
> 
> > There *has* to be a better way.
> 
> But nobody has reasonably proposed one and demonstrated that it works. 
> We've had over a year to do so and failed, and I think it's pretty 
> unreasonable to ask Google to attempt to rearchitect based on a 
> hypothetical.
>

These are not new issues being raised. They've had over a year to
address them, and all thats really happened was some sed script changes
from wake_lock to suspend_blocker.  Nothing is really different
here.

Rearchitecting out of tree code is as silly thing for you to expect from
a community member.  

sigh, lets stop wasting time and just merge it then.

I'm finished with this thread until I do some rearchecting and post
something that looks better to me.  I'll look for this stuff in 2.6.34
or 35.

--mgross 
ps It think the name suspend blocker is worse than wake-lock.  I'd
change it back.

Re: [PATCH 1/8] PM: Add suspend block api.

[Matthew Garrett]

On Wed, May 05, 2010 at 01:09:06PM -0700, mark gross wrote:
> On Wed, May 05, 2010 at 02:31:31PM +0100, Matthew Garrett wrote:
> > But nobody has reasonably proposed one and demonstrated that it works. 
> > We've had over a year to do so and failed, and I think it's pretty 
> > unreasonable to ask Google to attempt to rearchitect based on a 
> > hypothetical.
> >
> 
> These are not new issues being raised. They've had over a year to
> address them, and all thats really happened was some sed script changes
> from wake_lock to suspend_blocker.  Nothing is really different
> here.

Our issues haven't been addressed because we've given no indication as 
to how they can be addressed. For better or worse, our runtime 
powermanagement story isn't sufficient to satisfy Google's usecases. 
That would be fine, if we could tell them what changes needed to be made 
to satisfy their usecases. The Android people have said that they don't 
see a cleaner way of doing this. Are we seriously saying that they 
should prove themselves wrong, and if they can't they don't get their 
code in the kernel? This seems... problematic.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Wed, May 05, 2010 at 11:44:39AM -0400, Alan Stern wrote:
> On Tue, 4 May 2010, mark gross wrote:
> 
> > Thanks, I think I'm starting to get it.  From this it seems that the
> > system integrator needs to identify those wake up sources that need to
> > be able to block a suspend, and figure out a way of acknowledging from
> > user mode, that its now ok to allow a suspend to happen.
> 
> The second part is easy.  Userspace doesn't need to do anything special 
> to acknowledge that a suspend is now okay; it just has to remove the 
> conditions that led the driver to block suspends in the first place.
> 
> For example, if suspends are blocked because some input event has been
> queued, emptying the input event queue should unblock suspends.
> 
> > The rev-6 proposed way is for the integrator to implement overlapping
> > blocker sections from ISR up to user mode for selected wake up devices
> > (i.e. the modem)
> > 
> > There *has* to be a better way.
> 
> Why?  What's wrong with overlapping blockers?  It's a very common
> idiom.  For example, the same sort of thing is used when locking
> subtrees of a tree: You lock the root node, and then use overlapping
> locks on the nodes leading down to the subtree you're interested in.

Because in the kenel there is only a partial ordering of calling
sequences from IRQ to usermode.  I see a lot of custom out of tree code
being developed to deal with getting the overlapping blocker sections
right, per device.

 
> > Can't we have some notification based thing that supports user mode
> > acks through a misc device or sysfs thing?   Anything to avoid the
> > overlapping blocker sections. 
> 
> Userspace acks aren't the issue; the issue is how (and when) kernel 
> drivers should initiate a blocker.  Switching to notifications, misc 
> devices, or sysfs won't help solve this issue.

communicating non-local knowledge back down to the blocking object to
tell it that it can unblock is the issue
 
> > True, you need an ack back from user mode for when its ok to allow
> > suspend to happen.  This ack is device specific and needs to be custom
> > built per product to its wake up sources.
> 
> No and no.  Nothing special is needed.  All userspace needs to do is 
> remove the condition that led to the blocker being enabled initially -- 
> which is exactly what userspace would do normally anyway.

Oh, like tell the modem that user mode has handled the ring event and
its ok to un-block?

--mgross

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Mon, 3 May 2010, Rafael J. Wysocki wrote:

> The main problem is that the entire suspend subsystem is going to work in a
> different way when suspend blockers are enforced.  Thus IMO it makes sense to
> provide a switch between the "opportunistic" and "forced" modes, because that
> clearly indicates to the user (or user space in general) how the whole suspend
> subsystem actually works at the moment.
> 
> As long as it's "opportunistic", the system will autosuspend if suspend
> blockers are not active and the behavior of "state" reflects that.  If you want
> to enforce a transition, switch to "forced" first.
> 
> That's not at all confusing if you know what you're doing.  The defailt mode is
> "forced", so the suspend subsystem works "as usual" by default.  You have to
> directly switch it to "opportunistic" to change the behavior and once you've
> done that, you shouldn't really be surprised that the behavior has changed.
> That's what you've requested after all.

How about changing the contents of /sys/power/state depending on the 
current policy?  When the policy is "forced" it should look the same as 
it does now.  When the policy is "opportunistic" it should contain 
"mem" and "on".

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Mon, May 3, 2010 at 3:11 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, 3 May 2010, Rafael J. Wysocki wrote:
>
>> The main problem is that the entire suspend subsystem is going to work in a
>> different way when suspend blockers are enforced.  Thus IMO it makes sense to
>> provide a switch between the "opportunistic" and "forced" modes, because that
>> clearly indicates to the user (or user space in general) how the whole suspend
>> subsystem actually works at the moment.
>>
>> As long as it's "opportunistic", the system will autosuspend if suspend
>> blockers are not active and the behavior of "state" reflects that.  If you want
>> to enforce a transition, switch to "forced" first.
>>
>> That's not at all confusing if you know what you're doing.  The defailt mode is
>> "forced", so the suspend subsystem works "as usual" by default.  You have to
>> directly switch it to "opportunistic" to change the behavior and once you've
>> done that, you shouldn't really be surprised that the behavior has changed.
>> That's what you've requested after all.
>
> How about changing the contents of /sys/power/state depending on the
> current policy?  When the policy is "forced" it should look the same as
> it does now.  When the policy is "opportunistic" it should contain
> "mem" and "on".

It already does this.

-- 
Arve Hjønnevåg

[PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

Adds /sys/power/policy that selects the behaviour of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/opportunistic-suspend.txt |  119 +++++++++++
 include/linux/suspend_blocker.h               |   64 ++++++
 kernel/power/Kconfig                          |   16 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/main.c                           |   92 ++++++++-
 kernel/power/power.h                          |    9 +
 kernel/power/suspend.c                        |    4 +-
 kernel/power/suspend_blocker.c                |  261 +++++++++++++++++++++++++
 8 files changed, 559 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/power/opportunistic-suspend.txt
 create mode 100755 include/linux/suspend_blocker.h
 create mode 100644 kernel/power/suspend_blocker.c

diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
new file mode 100644
index 0000000..3d060e8
--- /dev/null
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -0,0 +1,119 @@
+Opportunistic Suspend
+=====================
+
+Opportunistic suspend is a feature allowing the system to be suspended (ie. put
+into one of the available sleep states) automatically whenever it is regarded
+as idle.  The suspend blockers framework described below is used to determine
+when that happens.
+
+The /sys/power/policy sysfs attribute is used to switch the system between the
+opportunistic and "forced" suspend behavior, where in the latter case the
+system is only suspended if a specific value, corresponding to one of the
+available system sleep states, is written into /sys/power/state.  However, in
+the former, opportunistic, case the system is put into the sleep state
+corresponding to the value written to /sys/power/state whenever there are no
+active suspend blockers. The default policy is "forced". Also, suspend blockers
+do not affect sleep states entered from idle.
+
+When the policy is "opportunisic", there is a special value, "on", that can be
+written to /sys/power/state. This will block the automatic sleep request, as if
+a suspend blocker was used by a device driver. This way the opportunistic
+suspend may be blocked by user space whithout switching back to the "forced"
+mode.
+
+A suspend blocker is an object used to inform the PM subsystem when the system
+can or cannot be suspended in the "opportunistic" mode (the "forced" mode
+ignores suspend blockers).  To use it, a device driver creates a struct
+suspend_blocker that must be initialized with suspend_blocker_init(). Before
+freeing the suspend_blocker structure or its name, suspend_blocker_destroy()
+must be called on it.
+
+A suspend blocker is activated using suspend_block(), which prevents the PM
+subsystem from putting the system into the requested sleep state in the
+"opportunistic" mode until the suspend blocker is deactivated with
+suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
+the system will not suspend as long as at least one of them is active.
+
+If opportunistic suspend is already in progress when suspend_block() is called,
+it will abort the suspend, unless suspend_ops->enter has already been
+executed. If suspend is aborted this way, the system is usually not fully
+operational at that point. The suspend callbacks of some drivers may still be
+running and it usually takes time to restore the system to the fully operational
+state.
+
+Here's an example showing how a cell phone or other embedded system can handle
+keystrokes (or other input events) in the presence of suspend blockers. 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 calls suspend_block on the
+  keypad-scan suspend_blocker 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 calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should be ignored, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.
+
+If the key that was pressed instead should preform a simple action (for example,
+adjusting the volume), this action can be performed right before calling
+suspend_unblock on the process_input_events suspend_blocker. However, if the key
+triggers a longer-running action, that action needs its own suspend_blocker and
+suspend_block must be called on that suspend blocker before calling
+suspend_unblock on the process_input_events suspend_blocker.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block api by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init. For instance:
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
+}
+
+Before freeing the memory, suspend_blocker_destroy must be called:
+
+uninit() {
+	suspend_blocker_destroy(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block:
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock:
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block when the suspend blocker is active or suspend_unblock when
+it is not active has no effect (i.e., these functions don't nest). This allows
+drivers to update their state and call suspend suspend_block or suspend_unblock
+based on the result.
+For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
+
diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
new file mode 100755
index 0000000..f9928cc
--- /dev/null
+++ b/include/linux/suspend_blocker.h
@@ -0,0 +1,64 @@
+/* include/linux/suspend_blocker.h
+ *
+ * Copyright (C) 2007-2009 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_SUSPEND_BLOCKER_H
+#define _LINUX_SUSPEND_BLOCKER_H
+
+#include <linux/list.h>
+
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @link:	List entry for active or inactive list.
+ * @flags:	Tracks initialized and active state.
+ * @name:	Name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * opportunistic suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
+ */
+
+struct suspend_blocker {
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct list_head    link;
+	int                 flags;
+	const char         *name;
+#endif
+};
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
+void suspend_blocker_destroy(struct suspend_blocker *blocker);
+void suspend_block(struct suspend_blocker *blocker);
+void suspend_unblock(struct suspend_blocker *blocker);
+bool suspend_blocker_is_active(struct suspend_blocker *blocker);
+bool suspend_is_blocked(void);
+
+#else
+
+static inline void suspend_blocker_init(struct suspend_blocker *blocker,
+					const char *name) {}
+static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
+static inline void suspend_block(struct suspend_blocker *blocker) {}
+static inline void suspend_unblock(struct suspend_blocker *blocker) {}
+static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
+								{ return 0; }
+static inline bool suspend_is_blocked(void) { return 0; }
+
+#endif
+
+#endif
+
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5c36ea9..55a06a1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -130,6 +130,22 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config OPPORTUNISTIC_SUSPEND
+	bool "Suspend blockers"
+	depends on PM_SLEEP
+	select RTC_LIB
+	default n
+	---help---
+	  Opportunistic sleep support.  Allows the system to be put into a sleep
+	  state opportunistically, if it doesn't do any useful work at the
+	  moment. The PM subsystem is switched into this mode of operation by
+	  writing "opportunistic" into /sys/power/policy, while writing
+	  "forced" to this file turns the opportunistic suspend feature off.
+	  In the "opportunistic" mode suspend blockers are used to determine
+	  when to suspend the system and the value written to /sys/power/state
+	  determines the sleep state the system will be put into when there are
+	  no active suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4319181..ee5276d 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
+obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= suspend_blocker.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/main.c b/kernel/power/main.c
index b58800b..030ecdc 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -12,6 +12,7 @@
 #include <linux/string.h>
 #include <linux/resume-trace.h>
 #include <linux/workqueue.h>
+#include <linux/suspend_blocker.h>
 
 #include "power.h"
 
@@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
 unsigned int pm_flags;
 EXPORT_SYMBOL(pm_flags);
 
+struct policy {
+	const char *name;
+	bool (*valid_state)(suspend_state_t state);
+	int (*set_state)(suspend_state_t state);
+};
+static struct policy policies[] = {
+	{
+		.name		= "forced",
+		.valid_state	= valid_state,
+		.set_state	= enter_state,
+	},
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	{
+		.name		= "opportunistic",
+		.valid_state	= request_suspend_valid_state,
+		.set_state	= request_suspend_state,
+	},
+#endif
+};
+static int policy;
+
 #ifdef CONFIG_PM_SLEEP
 
 /* Routines for PM-transition notifications */
@@ -146,6 +168,12 @@ struct kobject *power_kobj;
  *
  *	store() accepts one of those strings, translates it into the 
  *	proper enumerated value, and initiates a suspend transition.
+ *
+ *	If policy is set to opportunistic, store() does not block until the
+ *	system resumes, and it will try to re-enter the state until another
+ *	state is requested. Suspend blockers are respected and the requested
+ *	state will only be entered when no suspend blockers are active.
+ *	Write "on" to cancel.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
@@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 
 	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
+		if (pm_states[i] && policies[policy].valid_state(i))
 			s += sprintf(s,"%s ", pm_states[i]);
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (!policy)
+		s += sprintf(s, "%s\n", "disk");
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
@@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_ON;
 	const char * const *s;
 #endif
 	char *p;
@@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 	len = p ? p - buf : n;
 
 	/* First, check if we are requested to hibernate */
-	if (len == 4 && !strncmp(buf, "disk", len)) {
+	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
 		error = hibernate();
   goto Exit;
 	}
@@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
-		error = enter_state(state);
+		error = policies[policy].set_state(state);
 #endif
 
  Exit:
@@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+/**
+ *	policy - set policy for state
+ */
+
+static ssize_t policy_show(struct kobject *kobj,
+			   struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		if (i == policy)
+			s += sprintf(s, "[%s] ", policies[i].name);
+		else
+			s += sprintf(s, "%s ", policies[i].name);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t policy_store(struct kobject *kobj,
+			    struct kobj_attribute *attr,
+			    const char *buf, size_t n)
+{
+	const char *s;
+	char *p;
+	int len;
+	int i;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		s = policies[i].name;
+		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
+			mutex_lock(&pm_mutex);
+			policies[policy].set_state(PM_SUSPEND_ON);
+			policy = i;
+			mutex_unlock(&pm_mutex);
+			return n;
+		}
+	}
+	return -EINVAL;
+}
+
+power_attr(policy);
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -231,6 +309,7 @@ power_attr(pm_trace);
 
 static struct attribute * g[] = {
 	&state_attr.attr,
+	&policy_attr.attr,
 #ifdef CONFIG_PM_TRACE
 	&pm_trace_attr.attr,
 #endif
@@ -247,7 +326,7 @@ static struct attribute_group attr_group = {
 	.attrs = g,
 };
 
-#ifdef CONFIG_PM_RUNTIME
+#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
 struct workqueue_struct *pm_wq;
 EXPORT_SYMBOL_GPL(pm_wq);
 
@@ -266,6 +345,7 @@ static int __init pm_init(void)
 	int error = pm_start_workqueue();
 	if (error)
 		return error;
+	suspend_block_init();
 	power_kobj = kobject_create_and_add("power", NULL);
 	if (!power_kobj)
 		return -ENOMEM;
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46c5a26..67d10fd 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+/* kernel/power/suspend_block.c */
+extern int request_suspend_state(suspend_state_t state);
+extern bool request_suspend_valid_state(suspend_state_t state);
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+extern void __init suspend_block_init(void);
+#else
+static inline void suspend_block_init(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..dc42006 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -16,10 +16,12 @@
 #include <linux/cpu.h>
 #include <linux/syscalls.h>
 #include <linux/gfp.h>
+#include <linux/suspend_blocker.h>
 
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_ON]		= "on",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -157,7 +159,7 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
 			error = suspend_ops->enter(state);
 		sysdev_resume();
 	}
diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
new file mode 100644
index 0000000..2c58b21
--- /dev/null
+++ b/kernel/power/suspend_blocker.c
@@ -0,0 +1,261 @@
+/* kernel/power/suspend_blocker.c
+ *
+ * Copyright (C) 2005-2010 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/rtc.h>
+#include <linux/suspend.h>
+#include <linux/suspend_blocker.h>
+#include "power.h"
+
+extern struct workqueue_struct *pm_wq;
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+static DEFINE_SPINLOCK(list_lock);
+static DEFINE_SPINLOCK(state_lock);
+static LIST_HEAD(inactive_blockers);
+static LIST_HEAD(active_blockers);
+static int current_event_num;
+struct suspend_blocker main_suspend_blocker;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+
+#define pr_info_time(fmt, args...) \
+	do { \
+		struct timespec ts; \
+		struct rtc_time tm; \
+		getnstimeofday(&ts); \
+		rtc_time_to_tm(ts.tv_sec, &tm); \
+		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+			args, \
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+	} while (0);
+
+static void print_active_blockers_locked(void)
+{
+	struct suspend_blocker *blocker;
+
+	list_for_each_entry(blocker, &active_blockers, link)
+		pr_info("active suspend blocker %s\n", blocker->name);
+}
+
+/**
+ * suspend_is_blocked() - Check if suspend should be blocked
+ *
+ * suspend_is_blocked can be used by generic power management code to abort
+ * suspend.
+ *
+ * To preserve backward compatibility suspend_is_blocked returns 0 unless it
+ * is called during suspend initiated from the suspend_block code.
+ */
+bool suspend_is_blocked(void)
+{
+	if (!enable_suspend_blockers)
+		return 0;
+	return !list_empty(&active_blockers);
+}
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = true;
+	while (!suspend_is_blocked()) {
+		entry_event_num = current_event_num;
+
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: enter suspend\n");
+
+		ret = pm_suspend(requested_suspend_state);
+
+		if (debug_mask & DEBUG_EXIT_SUSPEND)
+			pr_info_time("suspend: exit suspend, ret = %d ", ret);
+
+		if (current_event_num == entry_event_num)
+			pr_info("suspend: pm_suspend returned with no event\n");
+	}
+	enable_suspend_blockers = false;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+/**
+ * suspend_blocker_init() - Initialize a suspend blocker
+ * @blocker:	The suspend blocker to initialize.
+ * @name:	The name of the suspend blocker to show in debug messages.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_destroy.
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	unsigned long irqflags = 0;
+
+	WARN_ON(!name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_init name=%s\n", name);
+
+	blocker->name = name;
+	blocker->flags = SB_INITIALIZED;
+	INIT_LIST_HEAD(&blocker->link);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&blocker->link, &inactive_blockers);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_destroy() - Destroy a suspend blocker
+ * @blocker:	The suspend blocker to destroy.
+ */
+void suspend_blocker_destroy(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags &= ~SB_INITIALIZED;
+	list_del(&blocker->link);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_destroy);
+
+/**
+ * suspend_block() - Block suspend
+ * @blocker:	The suspend blocker to use
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_block: %s\n", blocker->name);
+
+	blocker->flags |= SB_ACTIVE;
+	list_move(&blocker->link, &active_blockers);
+	current_event_num++;
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock() - Unblock suspend
+ * @blocker:	The suspend blocker to unblock.
+ *
+ * If no other suspend blockers block suspend, the system will suspend.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_unblock: %s\n", blocker->name);
+
+	list_move(&blocker->link, &inactive_blockers);
+
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	blocker->flags &= ~(SB_ACTIVE);
+	if (blocker == &main_suspend_blocker) {
+		if (debug_mask & DEBUG_SUSPEND)
+			print_active_blockers_locked();
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
+ * @blocker:	The suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
+ */
+bool suspend_blocker_is_active(struct suspend_blocker *blocker)
+{
+	WARN_ON(!(blocker->flags & SB_INITIALIZED));
+
+	return !!(blocker->flags & SB_ACTIVE);
+}
+EXPORT_SYMBOL(suspend_blocker_is_active);
+
+bool request_suspend_valid_state(suspend_state_t state)
+{
+	return (state == PM_SUSPEND_ON) || valid_state(state);
+}
+
+int request_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+
+	if (!request_suspend_valid_state(state))
+		return -ENODEV;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+
+	if (debug_mask & DEBUG_USER_STATE)
+		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
+			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			     requested_suspend_state, state,
+			     ktime_to_ns(ktime_get()));
+
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+	spin_unlock_irqrestore(&state_lock, irqflags);
+	return 0;
+}
+
+void __init suspend_block_init(void)
+{
+	suspend_blocker_init(&main_suspend_blocker, "main");
+	suspend_block(&main_suspend_blocker);
+}
-- 
1.6.5.1

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.

As I explained before (and got no reply),  the proposed interface is
ugly. It uses one sysfs file to change semantics of another one.

> Signed-off-by: Arve Hj??nnev??g <arve@android.com>

NAK.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

On Fri 2010-04-30 15:36:54, Arve Hj??nnev??g wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hj??nnev??g <arve@android.com>

Also note that this patch mixes up adding new in-kernel interface with
adding new userland API.

The in-kernel interface seems to be sane and it would be nice to merge
it soon, unfortunately the strange userland API is in the same patch :-(.

> ---
>  Documentation/power/opportunistic-suspend.txt |  119 +++++++++++
>  include/linux/suspend_blocker.h               |   64 ++++++
>  kernel/power/Kconfig                          |   16 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/main.c                           |   92 ++++++++-
>  kernel/power/power.h                          |    9 +
>  kernel/power/suspend.c                        |    4 +-
>  kernel/power/suspend_blocker.c                |  261 +++++++++++++++++++++++++
>  8 files changed, 559 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/power/opportunistic-suspend.txt
>  create mode 100755 include/linux/suspend_blocker.h
>  create mode 100644 kernel/power/suspend_blocker.c
> 
> diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
> new file mode 100644
> index 0000000..3d060e8
> --- /dev/null
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -0,0 +1,119 @@
> +Opportunistic Suspend
> +=====================
> +
> +Opportunistic suspend is a feature allowing the system to be suspended (ie. put
> +into one of the available sleep states) automatically whenever it is regarded
> +as idle.  The suspend blockers framework described below is used to determine
> +when that happens.
> +
> +The /sys/power/policy sysfs attribute is used to switch the system between the
> +opportunistic and "forced" suspend behavior, where in the latter case the
> +system is only suspended if a specific value, corresponding to one of the
> +available system sleep states, is written into /sys/power/state.  However, in
> +the former, opportunistic, case the system is put into the sleep state
> +corresponding to the value written to /sys/power/state whenever there are no
> +active suspend blockers. The default policy is "forced". Also, suspend blockers
> +do not affect sleep states entered from idle.
> +
> +When the policy is "opportunisic", there is a special value, "on", that can be
> +written to /sys/power/state. This will block the automatic sleep request, as if
> +a suspend blocker was used by a device driver. This way the opportunistic
> +suspend may be blocked by user space whithout switching back to the "forced"
> +mode.
> +
> +A suspend blocker is an object used to inform the PM subsystem when the system
> +can or cannot be suspended in the "opportunistic" mode (the "forced" mode
> +ignores suspend blockers).  To use it, a device driver creates a struct
> +suspend_blocker that must be initialized with suspend_blocker_init(). Before
> +freeing the suspend_blocker structure or its name, suspend_blocker_destroy()
> +must be called on it.
> +
> +A suspend blocker is activated using suspend_block(), which prevents the PM
> +subsystem from putting the system into the requested sleep state in the
> +"opportunistic" mode until the suspend blocker is deactivated with
> +suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
> +the system will not suspend as long as at least one of them is active.
> +
> +If opportunistic suspend is already in progress when suspend_block() is called,
> +it will abort the suspend, unless suspend_ops->enter has already been
> +executed. If suspend is aborted this way, the system is usually not fully
> +operational at that point. The suspend callbacks of some drivers may still be
> +running and it usually takes time to restore the system to the fully operational
> +state.
> +
> +Here's an example showing how a cell phone or other embedded system can handle
> +keystrokes (or other input events) in the presence of suspend blockers. 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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. If it determines that
> +  the key should be ignored, it calls suspend_unblock on the
> +  process_input_events suspend_blocker and then calls select or poll. The
> +  system will automatically suspend again, since now no suspend blockers are
> +  active.
> +
> +If the key that was pressed instead should preform a simple action (for example,
> +adjusting the volume), this action can be performed right before calling
> +suspend_unblock on the process_input_events suspend_blocker. However, if the key
> +triggers a longer-running action, that action needs its own suspend_blocker and
> +suspend_block must be called on that suspend blocker before calling
> +suspend_unblock on the process_input_events suspend_blocker.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++
> +
> +
> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);
> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);
> +
> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
> +it is not active has no effect (i.e., these functions don't nest). This allows
> +drivers to update their state and call suspend suspend_block or suspend_unblock
> +based on the result.
> +For instance:
> +
> +if (list_empty(&state->pending_work))
> +	suspend_unblock(&state->suspend_blocker);
> +else
> +	suspend_block(&state->suspend_blocker);
> +
> diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
> new file mode 100755
> index 0000000..f9928cc
> --- /dev/null
> +++ b/include/linux/suspend_blocker.h
> @@ -0,0 +1,64 @@
> +/* include/linux/suspend_blocker.h
> + *
> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCKER_H
> +#define _LINUX_SUSPEND_BLOCKER_H
> +
> +#include <linux/list.h>
> +
> +/**
> + * struct suspend_blocker - the basic suspend_blocker structure
> + * @link:	List entry for active or inactive list.
> + * @flags:	Tracks initialized and active state.
> + * @name:	Name used for debugging.
> + *
> + * When a suspend_blocker is active it prevents the system from entering
> + * opportunistic suspend.
> + *
> + * The suspend_blocker structure must be initialized by suspend_blocker_init()
> + */
> +
> +struct suspend_blocker {
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	struct list_head    link;
> +	int                 flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker);
> +bool suspend_is_blocked(void);
> +
> +#else
> +
> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
> +					const char *name) {}
> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
> +static inline void suspend_block(struct suspend_blocker *blocker) {}
> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
> +static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
> +								{ return 0; }
> +static inline bool suspend_is_blocked(void) { return 0; }
> +
> +#endif
> +
> +#endif
> +
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 5c36ea9..55a06a1 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -130,6 +130,22 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config OPPORTUNISTIC_SUSPEND
> +	bool "Suspend blockers"
> +	depends on PM_SLEEP
> +	select RTC_LIB
> +	default n
> +	---help---
> +	  Opportunistic sleep support.  Allows the system to be put into a sleep
> +	  state opportunistically, if it doesn't do any useful work at the
> +	  moment. The PM subsystem is switched into this mode of operation by
> +	  writing "opportunistic" into /sys/power/policy, while writing
> +	  "forced" to this file turns the opportunistic suspend feature off.
> +	  In the "opportunistic" mode suspend blockers are used to determine
> +	  when to suspend the system and the value written to /sys/power/state
> +	  determines the sleep state the system will be put into when there are
> +	  no active suspend blockers.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index 4319181..ee5276d 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
>  obj-$(CONFIG_PM_SLEEP)		+= console.o
>  obj-$(CONFIG_FREEZER)		+= process.o
>  obj-$(CONFIG_SUSPEND)		+= suspend.o
> +obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= suspend_blocker.o
>  obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
>  obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
>  obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index b58800b..030ecdc 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -12,6 +12,7 @@
>  #include <linux/string.h>
>  #include <linux/resume-trace.h>
>  #include <linux/workqueue.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
> @@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
>  unsigned int pm_flags;
>  EXPORT_SYMBOL(pm_flags);
>  
> +struct policy {
> +	const char *name;
> +	bool (*valid_state)(suspend_state_t state);
> +	int (*set_state)(suspend_state_t state);
> +};
> +static struct policy policies[] = {
> +	{
> +		.name		= "forced",
> +		.valid_state	= valid_state,
> +		.set_state	= enter_state,
> +	},
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	{
> +		.name		= "opportunistic",
> +		.valid_state	= request_suspend_valid_state,
> +		.set_state	= request_suspend_state,
> +	},
> +#endif
> +};
> +static int policy;
> +
>  #ifdef CONFIG_PM_SLEEP
>  
>  /* Routines for PM-transition notifications */
> @@ -146,6 +168,12 @@ struct kobject *power_kobj;
>   *
>   *	store() accepts one of those strings, translates it into the 
>   *	proper enumerated value, and initiates a suspend transition.
> + *
> + *	If policy is set to opportunistic, store() does not block until the
> + *	system resumes, and it will try to re-enter the state until another
> + *	state is requested. Suspend blockers are respected and the requested
> + *	state will only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
>   */
>  static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			  char *buf)
> @@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  	int i;
>  
>  	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> -		if (pm_states[i] && valid_state(i))
> +		if (pm_states[i] && policies[policy].valid_state(i))
>  			s += sprintf(s,"%s ", pm_states[i]);
>  	}
>  #endif
>  #ifdef CONFIG_HIBERNATION
> -	s += sprintf(s, "%s\n", "disk");
> +	if (!policy)
> +		s += sprintf(s, "%s\n", "disk");
>  #else
>  	if (s != buf)
>  		/* convert the last space to a newline */
> @@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			   const char *buf, size_t n)
>  {
>  #ifdef CONFIG_SUSPEND
> -	suspend_state_t state = PM_SUSPEND_STANDBY;
> +	suspend_state_t state = PM_SUSPEND_ON;
>  	const char * const *s;
>  #endif
>  	char *p;
> @@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  	len = p ? p - buf : n;
>  
>  	/* First, check if we are requested to hibernate */
> -	if (len == 4 && !strncmp(buf, "disk", len)) {
> +	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
>  		error = hibernate();
>    goto Exit;
>  	}
> @@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			break;
>  	}
>  	if (state < PM_SUSPEND_MAX && *s)
> -		error = enter_state(state);
> +		error = policies[policy].set_state(state);
>  #endif
>  
>   Exit:
> @@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	policy - set policy for state
> + */
> +
> +static ssize_t policy_show(struct kobject *kobj,
> +			   struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		if (i == policy)
> +			s += sprintf(s, "[%s] ", policies[i].name);
> +		else
> +			s += sprintf(s, "%s ", policies[i].name);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t policy_store(struct kobject *kobj,
> +			    struct kobj_attribute *attr,
> +			    const char *buf, size_t n)
> +{
> +	const char *s;
> +	char *p;
> +	int len;
> +	int i;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		s = policies[i].name;
> +		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
> +			mutex_lock(&pm_mutex);
> +			policies[policy].set_state(PM_SUSPEND_ON);
> +			policy = i;
> +			mutex_unlock(&pm_mutex);
> +			return n;
> +		}
> +	}
> +	return -EINVAL;
> +}
> +
> +power_attr(policy);
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  
> @@ -231,6 +309,7 @@ power_attr(pm_trace);
>  
>  static struct attribute * g[] = {
>  	&state_attr.attr,
> +	&policy_attr.attr,
>  #ifdef CONFIG_PM_TRACE
>  	&pm_trace_attr.attr,
>  #endif
> @@ -247,7 +326,7 @@ static struct attribute_group attr_group = {
>  	.attrs = g,
>  };
>  
> -#ifdef CONFIG_PM_RUNTIME
> +#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
>  struct workqueue_struct *pm_wq;
>  EXPORT_SYMBOL_GPL(pm_wq);
>  
> @@ -266,6 +345,7 @@ static int __init pm_init(void)
>  	int error = pm_start_workqueue();
>  	if (error)
>  		return error;
> +	suspend_block_init();
>  	power_kobj = kobject_create_and_add("power", NULL);
>  	if (!power_kobj)
>  		return -ENOMEM;
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 46c5a26..67d10fd 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
>  {
>  }
>  #endif
> +
> +/* kernel/power/suspend_block.c */
> +extern int request_suspend_state(suspend_state_t state);
> +extern bool request_suspend_valid_state(suspend_state_t state);
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +extern void __init suspend_block_init(void);
> +#else
> +static inline void suspend_block_init(void) {}
> +#endif
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 56e7dbb..dc42006 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -16,10 +16,12 @@
>  #include <linux/cpu.h>
>  #include <linux/syscalls.h>
>  #include <linux/gfp.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
>  const char *const pm_states[PM_SUSPEND_MAX] = {
> +	[PM_SUSPEND_ON]		= "on",
>  	[PM_SUSPEND_STANDBY]	= "standby",
>  	[PM_SUSPEND_MEM]	= "mem",
>  };
> @@ -157,7 +159,7 @@ static int suspend_enter(suspend_state_t state)
>  
>  	error = sysdev_suspend(PMSG_SUSPEND);
>  	if (!error) {
> -		if (!suspend_test(TEST_CORE))
> +		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
>  			error = suspend_ops->enter(state);
>  		sysdev_resume();
>  	}
> diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
> new file mode 100644
> index 0000000..2c58b21
> --- /dev/null
> +++ b/kernel/power/suspend_blocker.c
> @@ -0,0 +1,261 @@
> +/* kernel/power/suspend_blocker.c
> + *
> + * Copyright (C) 2005-2010 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/rtc.h>
> +#include <linux/suspend.h>
> +#include <linux/suspend_blocker.h>
> +#include "power.h"
> +
> +extern struct workqueue_struct *pm_wq;
> +
> +enum {
> +	DEBUG_EXIT_SUSPEND = 1U << 0,
> +	DEBUG_WAKEUP = 1U << 1,
> +	DEBUG_USER_STATE = 1U << 2,
> +	DEBUG_SUSPEND = 1U << 3,
> +	DEBUG_SUSPEND_BLOCKER = 1U << 4,
> +};
> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
> +
> +#define SB_INITIALIZED            (1U << 8)
> +#define SB_ACTIVE                 (1U << 9)
> +
> +static DEFINE_SPINLOCK(list_lock);
> +static DEFINE_SPINLOCK(state_lock);
> +static LIST_HEAD(inactive_blockers);
> +static LIST_HEAD(active_blockers);
> +static int current_event_num;
> +struct suspend_blocker main_suspend_blocker;
> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
> +static bool enable_suspend_blockers;
> +
> +#define pr_info_time(fmt, args...) \
> +	do { \
> +		struct timespec ts; \
> +		struct rtc_time tm; \
> +		getnstimeofday(&ts); \
> +		rtc_time_to_tm(ts.tv_sec, &tm); \
> +		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
> +			args, \
> +			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
> +			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
> +	} while (0);
> +
> +static void print_active_blockers_locked(void)
> +{
> +	struct suspend_blocker *blocker;
> +
> +	list_for_each_entry(blocker, &active_blockers, link)
> +		pr_info("active suspend blocker %s\n", blocker->name);
> +}
> +
> +/**
> + * suspend_is_blocked() - Check if suspend should be blocked
> + *
> + * suspend_is_blocked can be used by generic power management code to abort
> + * suspend.
> + *
> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
> + * is called during suspend initiated from the suspend_block code.
> + */
> +bool suspend_is_blocked(void)
> +{
> +	if (!enable_suspend_blockers)
> +		return 0;
> +	return !list_empty(&active_blockers);
> +}
> +
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = true;
> +	while (!suspend_is_blocked()) {
> +		entry_event_num = current_event_num;
> +
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: enter suspend\n");
> +
> +		ret = pm_suspend(requested_suspend_state);
> +
> +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> +
> +		if (current_event_num == entry_event_num)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +	}
> +	enable_suspend_blockers = false;
> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in debug messages.
> + *
> + * The suspend blocker struct and name must not be freed before calling
> + * suspend_blocker_destroy.
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	unsigned long irqflags = 0;
> +
> +	WARN_ON(!name);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", name);
> +
> +	blocker->name = name;
> +	blocker->flags = SB_INITIALIZED;
> +	INIT_LIST_HEAD(&blocker->link);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	list_add(&blocker->link, &inactive_blockers);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);
> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags &= ~SB_INITIALIZED;
> +	list_del(&blocker->link);
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(pm_wq, &suspend_work);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +
> +	blocker->flags |= SB_ACTIVE;
> +	list_move(&blocker->link, &active_blockers);
> +	current_event_num++;
> +
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	list_move(&blocker->link, &inactive_blockers);
> +
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(pm_wq, &suspend_work);
> +	blocker->flags &= ~(SB_ACTIVE);
> +	if (blocker == &main_suspend_blocker) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			print_active_blockers_locked();
> +	}
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + *
> + * Returns true if the suspend_blocker is currently active.
> + */
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker)
> +{
> +	WARN_ON(!(blocker->flags & SB_INITIALIZED));
> +
> +	return !!(blocker->flags & SB_ACTIVE);
> +}
> +EXPORT_SYMBOL(suspend_blocker_is_active);
> +
> +bool request_suspend_valid_state(suspend_state_t state)
> +{
> +	return (state == PM_SUSPEND_ON) || valid_state(state);
> +}
> +
> +int request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +
> +	if (!request_suspend_valid_state(state))
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&state_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_USER_STATE)
> +		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
> +			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			     requested_suspend_state, state,
> +			     ktime_to_ns(ktime_get()));
> +
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +	return 0;
> +}
> +
> +void __init suspend_block_init(void)
> +{
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +}

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Sunday 02 May 2010, Pavel Machek wrote:
> Hi!
> 
> > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > After setting the policy to opportunistic, writes to /sys/power/state
> > become non-blocking requests that specify which suspend state to enter
> > when no suspend blockers are active. A special state, "on", stops the
> > process by activating the "main" suspend blocker.
> 
> As I explained before (and got no reply),  the proposed interface is
> ugly. It uses one sysfs file to change semantics of another one.

In fact this behavior was discussed at the LF Collab Summit and no one
involved had any problem with that.

> > Signed-off-by: Arve Hj??nnev??g <arve@android.com>
> 
> NAK.

Ignored.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

On Sun 2010-05-02 22:10:53, Rafael J. Wysocki wrote:
> On Sunday 02 May 2010, Pavel Machek wrote:
> > Hi!
> > 
> > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > After setting the policy to opportunistic, writes to /sys/power/state
> > > become non-blocking requests that specify which suspend state to enter
> > > when no suspend blockers are active. A special state, "on", stops the
> > > process by activating the "main" suspend blocker.
> > 
> > As I explained before (and got no reply),  the proposed interface is
> > ugly. It uses one sysfs file to change semantics of another one.
> 
> In fact this behavior was discussed at the LF Collab Summit and no one
> involved had any problem with that.

Well, I explained why I disliked in previous mail in more details, and
neither you nor Arve explained why it is good solution.

I was not on LF Collab summit, so unfortunately I can't comment on that.

> > > Signed-off-by: Arve Hj??nnev??g <arve@android.com>
> > 
> > NAK.
> 
> Ignored.

WTF?
									Pavel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Sunday 02 May 2010, Pavel Machek wrote:
> On Sun 2010-05-02 22:10:53, Rafael J. Wysocki wrote:
> > On Sunday 02 May 2010, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > > After setting the policy to opportunistic, writes to /sys/power/state
> > > > become non-blocking requests that specify which suspend state to enter
> > > > when no suspend blockers are active. A special state, "on", stops the
> > > > process by activating the "main" suspend blocker.
> > > 
> > > As I explained before (and got no reply),  the proposed interface is
> > > ugly. It uses one sysfs file to change semantics of another one.
> > 
> > In fact this behavior was discussed at the LF Collab Summit and no one
> > involved had any problem with that.
> 
> Well, I explained why I disliked in previous mail in more details,

We do exactly the same thing with 'pm_test', so I'm not sure what the problem is.

> and neither you nor Arve explained why it is good solution.

Because it's less confusing.  Having two different attributes returning
almost the same contents and working in a slightly different way wouldn't be
too clean IMO.

Also it reduces code duplication slightly.

> I was not on LF Collab summit, so unfortunately I can't comment on that.
> 
> > > > Signed-off-by: Arve Hj??nnev??g <arve@android.com>
> > > 
> > > NAK.
> > 
> > Ignored.
> 
> WTF?

Literally.  I'm not going to take that NAK into consideration.

Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> > > > As I explained before (and got no reply),  the proposed interface is
> > > > ugly. It uses one sysfs file to change semantics of another one.
> > > 
> > > In fact this behavior was discussed at the LF Collab Summit and no one
> > > involved had any problem with that.
> > 
> > Well, I explained why I disliked in previous mail in more details,
> 
> We do exactly the same thing with 'pm_test', so I'm not sure what the problem is.
> 
> > and neither you nor Arve explained why it is good solution.
> 
> Because it's less confusing.  Having two different attributes returning
> almost the same contents and working in a slightly different way wouldn't be
> too clean IMO.

No, I don't think it is similar to pm_test. pm_test is debug-only, and
orthogonal to state -- all combinations make sense.

With 'oportunistic > policy', state changes from blocking to
nonblocking (surprise!). Plus, it is not orthogonal:

(assume we added s-t-flash on android for powersaving... or imagine I
get oportunistic suspend working on PC --I was there with limited
config on x60).

policy: oportunistic forced

state: on mem disk

First disadvantage of proposed interface is that while 'opportunistic
mem' is active, I can't do 'forced disk' to save bit more power.

Next, not all combinations make sense.

oportunistic on == forced <nothing>

oportunistic disk -- probably something that will not be implemented
any time soon.

oportunistic mem -- makes sense.

forced on -- NOP

forced mem  -- makes sense.

forced disk -- makes sense.

So we have matrix of 7 possibilities, but only 4 make sense... IMO its confusing.



								Pavel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Monday 03 May 2010, Pavel Machek wrote:
> Hi!
> 
> > > > > As I explained before (and got no reply),  the proposed interface is
> > > > > ugly. It uses one sysfs file to change semantics of another one.
> > > > 
> > > > In fact this behavior was discussed at the LF Collab Summit and no one
> > > > involved had any problem with that.
> > > 
> > > Well, I explained why I disliked in previous mail in more details,
> > 
> > We do exactly the same thing with 'pm_test', so I'm not sure what the problem is.
> > 
> > > and neither you nor Arve explained why it is good solution.
> > 
> > Because it's less confusing.  Having two different attributes returning
> > almost the same contents and working in a slightly different way wouldn't be
> > too clean IMO.
> 
> No, I don't think it is similar to pm_test. pm_test is debug-only, and
> orthogonal to state -- all combinations make sense.
> 
> With 'oportunistic > policy', state changes from blocking to
> nonblocking (surprise!). Plus, it is not orthogonal:
> 
> (assume we added s-t-flash on android for powersaving... or imagine I
> get oportunistic suspend working on PC --I was there with limited
> config on x60).
> 
> policy: oportunistic forced
> 
> state: on mem disk
> 
> First disadvantage of proposed interface is that while 'opportunistic
> mem' is active, I can't do 'forced disk' to save bit more power.
> 
> Next, not all combinations make sense.
> 
> oportunistic on == forced <nothing>

That's correct, but the "opportunistic on" thing is there to avoid switching
back and forth from "opportunistic" to "forced".  So that's a matter of
convenience rather than anything else.

> oportunistic disk -- probably something that will not be implemented
> any time soon.

Yes, and that's why "disk" won't work with "opportunistic" for now.

> oportunistic mem -- makes sense.
> 
> forced on -- NOP

There won't be "on" with "forced" (that probably needs changing at the moment).

> forced mem  -- makes sense.
> 
> forced disk -- makes sense.
> 
> So we have matrix of 7 possibilities, but only 4 make sense... IMO its confusing.

The main problem is that the entire suspend subsystem is going to work in a
different way when suspend blockers are enforced.  Thus IMO it makes sense to
provide a switch between the "opportunistic" and "forced" modes, because that
clearly indicates to the user (or user space in general) how the whole suspend
subsystem actually works at the moment.

As long as it's "opportunistic", the system will autosuspend if suspend
blockers are not active and the behavior of "state" reflects that.  If you want
to enforce a transition, switch to "forced" first.

That's not at all confusing if you know what you're doing.  The defailt mode is
"forced", so the suspend subsystem works "as usual" by default.  You have to
directly switch it to "opportunistic" to change the behavior and once you've
done that, you shouldn't really be surprised that the behavior has changed.
That's what you've requested after all.

So no, I don't really think it's confusing.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Fri, Apr 30, 2010 at 03:36:54PM -0700, Arve Hjønnevåg wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  Documentation/power/opportunistic-suspend.txt |  119 +++++++++++
>  include/linux/suspend_blocker.h               |   64 ++++++
>  kernel/power/Kconfig                          |   16 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/main.c                           |   92 ++++++++-
>  kernel/power/power.h                          |    9 +
>  kernel/power/suspend.c                        |    4 +-
>  kernel/power/suspend_blocker.c                |  261 +++++++++++++++++++++++++
>  8 files changed, 559 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/power/opportunistic-suspend.txt
>  create mode 100755 include/linux/suspend_blocker.h
>  create mode 100644 kernel/power/suspend_blocker.c
> 
> diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
> new file mode 100644
> index 0000000..3d060e8
> --- /dev/null
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -0,0 +1,119 @@
> +Opportunistic Suspend
> +=====================
> +
> +Opportunistic suspend is a feature allowing the system to be suspended (ie. put
> +into one of the available sleep states) automatically whenever it is regarded
> +as idle.  The suspend blockers framework described below is used to determine
> +when that happens.
> +
> +The /sys/power/policy sysfs attribute is used to switch the system between the
> +opportunistic and "forced" suspend behavior, where in the latter case the
> +system is only suspended if a specific value, corresponding to one of the
> +available system sleep states, is written into /sys/power/state.  However, in
> +the former, opportunistic, case the system is put into the sleep state
> +corresponding to the value written to /sys/power/state whenever there are no
> +active suspend blockers. The default policy is "forced". Also, suspend blockers
> +do not affect sleep states entered from idle.
> +
> +When the policy is "opportunisic", there is a special value, "on", that can be
> +written to /sys/power/state. This will block the automatic sleep request, as if
> +a suspend blocker was used by a device driver. This way the opportunistic
> +suspend may be blocked by user space whithout switching back to the "forced"
> +mode.

You know things would be so much easier if the policy was a one-shot
styled thing.  i.e. when enabled it does what it does, but upon resume
the policy must be re-enabled by user mode to get the opportunistic
behavior.  That way we don't need to grab the suspend blocker from the
wake up irq handler all the way up to user mode as the example below
calls out.  I suppose doing this would put a burden on the user mode code
to keep track of if it has no pending blockers registered after a wake
up from the suspend.  but that seems nicer to me than sprinkling
overlapping blocker critical sections from the mettle up to user mode.

Please consider making the policy a one shot API that needs to be
re-enabled after resume by user mode.  That would remove my issue with
the design.

--mgross

> +
> +A suspend blocker is an object used to inform the PM subsystem when the system
> +can or cannot be suspended in the "opportunistic" mode (the "forced" mode
> +ignores suspend blockers).  To use it, a device driver creates a struct
> +suspend_blocker that must be initialized with suspend_blocker_init(). Before
> +freeing the suspend_blocker structure or its name, suspend_blocker_destroy()
> +must be called on it.
> +
> +A suspend blocker is activated using suspend_block(), which prevents the PM
> +subsystem from putting the system into the requested sleep state in the
> +"opportunistic" mode until the suspend blocker is deactivated with
> +suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
> +the system will not suspend as long as at least one of them is active.
> +
> +If opportunistic suspend is already in progress when suspend_block() is called,
> +it will abort the suspend, unless suspend_ops->enter has already been
> +executed. If suspend is aborted this way, the system is usually not fully
> +operational at that point. The suspend callbacks of some drivers may still be
> +running and it usually takes time to restore the system to the fully operational
> +state.
> +
> +Here's an example showing how a cell phone or other embedded system can handle
> +keystrokes (or other input events) in the presence of suspend blockers. 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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. If it determines that
> +  the key should be ignored, it calls suspend_unblock on the
> +  process_input_events suspend_blocker and then calls select or poll. The
> +  system will automatically suspend again, since now no suspend blockers are
> +  active.
> +
> +If the key that was pressed instead should preform a simple action (for example,
> +adjusting the volume), this action can be performed right before calling
> +suspend_unblock on the process_input_events suspend_blocker. However, if the key
> +triggers a longer-running action, that action needs its own suspend_blocker and
> +suspend_block must be called on that suspend blocker before calling
> +suspend_unblock on the process_input_events suspend_blocker.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++
> +
> +
> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);
> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);
> +
> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
> +it is not active has no effect (i.e., these functions don't nest). This allows
> +drivers to update their state and call suspend suspend_block or suspend_unblock
> +based on the result.
> +For instance:
> +
> +if (list_empty(&state->pending_work))
> +	suspend_unblock(&state->suspend_blocker);
> +else
> +	suspend_block(&state->suspend_blocker);
> +
> diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
> new file mode 100755
> index 0000000..f9928cc
> --- /dev/null
> +++ b/include/linux/suspend_blocker.h
> @@ -0,0 +1,64 @@
> +/* include/linux/suspend_blocker.h
> + *
> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCKER_H
> +#define _LINUX_SUSPEND_BLOCKER_H
> +
> +#include <linux/list.h>
> +
> +/**
> + * struct suspend_blocker - the basic suspend_blocker structure
> + * @link:	List entry for active or inactive list.
> + * @flags:	Tracks initialized and active state.
> + * @name:	Name used for debugging.
> + *
> + * When a suspend_blocker is active it prevents the system from entering
> + * opportunistic suspend.
> + *
> + * The suspend_blocker structure must be initialized by suspend_blocker_init()
> + */
> +
> +struct suspend_blocker {
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	struct list_head    link;
> +	int                 flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker);
> +bool suspend_is_blocked(void);
> +
> +#else
> +
> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
> +					const char *name) {}
> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
> +static inline void suspend_block(struct suspend_blocker *blocker) {}
> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
> +static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
> +								{ return 0; }
> +static inline bool suspend_is_blocked(void) { return 0; }
> +
> +#endif
> +
> +#endif
> +
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 5c36ea9..55a06a1 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -130,6 +130,22 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config OPPORTUNISTIC_SUSPEND
> +	bool "Suspend blockers"
> +	depends on PM_SLEEP
> +	select RTC_LIB
> +	default n
> +	---help---
> +	  Opportunistic sleep support.  Allows the system to be put into a sleep
> +	  state opportunistically, if it doesn't do any useful work at the
> +	  moment. The PM subsystem is switched into this mode of operation by
> +	  writing "opportunistic" into /sys/power/policy, while writing
> +	  "forced" to this file turns the opportunistic suspend feature off.
> +	  In the "opportunistic" mode suspend blockers are used to determine
> +	  when to suspend the system and the value written to /sys/power/state
> +	  determines the sleep state the system will be put into when there are
> +	  no active suspend blockers.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index 4319181..ee5276d 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
>  obj-$(CONFIG_PM_SLEEP)		+= console.o
>  obj-$(CONFIG_FREEZER)		+= process.o
>  obj-$(CONFIG_SUSPEND)		+= suspend.o
> +obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= suspend_blocker.o
>  obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
>  obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
>  obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index b58800b..030ecdc 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -12,6 +12,7 @@
>  #include <linux/string.h>
>  #include <linux/resume-trace.h>
>  #include <linux/workqueue.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
> @@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
>  unsigned int pm_flags;
>  EXPORT_SYMBOL(pm_flags);
>  
> +struct policy {
> +	const char *name;
> +	bool (*valid_state)(suspend_state_t state);
> +	int (*set_state)(suspend_state_t state);
> +};
> +static struct policy policies[] = {
> +	{
> +		.name		= "forced",
> +		.valid_state	= valid_state,
> +		.set_state	= enter_state,
> +	},
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	{
> +		.name		= "opportunistic",
> +		.valid_state	= request_suspend_valid_state,
> +		.set_state	= request_suspend_state,
> +	},
> +#endif
> +};
> +static int policy;
> +
>  #ifdef CONFIG_PM_SLEEP
>  
>  /* Routines for PM-transition notifications */
> @@ -146,6 +168,12 @@ struct kobject *power_kobj;
>   *
>   *	store() accepts one of those strings, translates it into the 
>   *	proper enumerated value, and initiates a suspend transition.
> + *
> + *	If policy is set to opportunistic, store() does not block until the
> + *	system resumes, and it will try to re-enter the state until another
> + *	state is requested. Suspend blockers are respected and the requested
> + *	state will only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
>   */
>  static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			  char *buf)
> @@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  	int i;
>  
>  	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> -		if (pm_states[i] && valid_state(i))
> +		if (pm_states[i] && policies[policy].valid_state(i))
>  			s += sprintf(s,"%s ", pm_states[i]);
>  	}
>  #endif
>  #ifdef CONFIG_HIBERNATION
> -	s += sprintf(s, "%s\n", "disk");
> +	if (!policy)
> +		s += sprintf(s, "%s\n", "disk");
>  #else
>  	if (s != buf)
>  		/* convert the last space to a newline */
> @@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			   const char *buf, size_t n)
>  {
>  #ifdef CONFIG_SUSPEND
> -	suspend_state_t state = PM_SUSPEND_STANDBY;
> +	suspend_state_t state = PM_SUSPEND_ON;
>  	const char * const *s;
>  #endif
>  	char *p;
> @@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  	len = p ? p - buf : n;
>  
>  	/* First, check if we are requested to hibernate */
> -	if (len == 4 && !strncmp(buf, "disk", len)) {
> +	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
>  		error = hibernate();
>    goto Exit;
>  	}
> @@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			break;
>  	}
>  	if (state < PM_SUSPEND_MAX && *s)
> -		error = enter_state(state);
> +		error = policies[policy].set_state(state);
>  #endif
>  
>   Exit:
> @@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	policy - set policy for state
> + */
> +
> +static ssize_t policy_show(struct kobject *kobj,
> +			   struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		if (i == policy)
> +			s += sprintf(s, "[%s] ", policies[i].name);
> +		else
> +			s += sprintf(s, "%s ", policies[i].name);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t policy_store(struct kobject *kobj,
> +			    struct kobj_attribute *attr,
> +			    const char *buf, size_t n)
> +{
> +	const char *s;
> +	char *p;
> +	int len;
> +	int i;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		s = policies[i].name;
> +		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
> +			mutex_lock(&pm_mutex);
> +			policies[policy].set_state(PM_SUSPEND_ON);
> +			policy = i;
> +			mutex_unlock(&pm_mutex);
> +			return n;
> +		}
> +	}
> +	return -EINVAL;
> +}
> +
> +power_attr(policy);
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  
> @@ -231,6 +309,7 @@ power_attr(pm_trace);
>  
>  static struct attribute * g[] = {
>  	&state_attr.attr,
> +	&policy_attr.attr,
>  #ifdef CONFIG_PM_TRACE
>  	&pm_trace_attr.attr,
>  #endif
> @@ -247,7 +326,7 @@ static struct attribute_group attr_group = {
>  	.attrs = g,
>  };
>  
> -#ifdef CONFIG_PM_RUNTIME
> +#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
>  struct workqueue_struct *pm_wq;
>  EXPORT_SYMBOL_GPL(pm_wq);
>  
> @@ -266,6 +345,7 @@ static int __init pm_init(void)
>  	int error = pm_start_workqueue();
>  	if (error)
>  		return error;
> +	suspend_block_init();
>  	power_kobj = kobject_create_and_add("power", NULL);
>  	if (!power_kobj)
>  		return -ENOMEM;
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 46c5a26..67d10fd 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
>  {
>  }
>  #endif
> +
> +/* kernel/power/suspend_block.c */
> +extern int request_suspend_state(suspend_state_t state);
> +extern bool request_suspend_valid_state(suspend_state_t state);
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +extern void __init suspend_block_init(void);
> +#else
> +static inline void suspend_block_init(void) {}
> +#endif
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 56e7dbb..dc42006 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -16,10 +16,12 @@
>  #include <linux/cpu.h>
>  #include <linux/syscalls.h>
>  #include <linux/gfp.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
>  const char *const pm_states[PM_SUSPEND_MAX] = {
> +	[PM_SUSPEND_ON]		= "on",
>  	[PM_SUSPEND_STANDBY]	= "standby",
>  	[PM_SUSPEND_MEM]	= "mem",
>  };
> @@ -157,7 +159,7 @@ static int suspend_enter(suspend_state_t state)
>  
>  	error = sysdev_suspend(PMSG_SUSPEND);
>  	if (!error) {
> -		if (!suspend_test(TEST_CORE))
> +		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
>  			error = suspend_ops->enter(state);
>  		sysdev_resume();
>  	}
> diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
> new file mode 100644
> index 0000000..2c58b21
> --- /dev/null
> +++ b/kernel/power/suspend_blocker.c
> @@ -0,0 +1,261 @@
> +/* kernel/power/suspend_blocker.c
> + *
> + * Copyright (C) 2005-2010 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/rtc.h>
> +#include <linux/suspend.h>
> +#include <linux/suspend_blocker.h>
> +#include "power.h"
> +
> +extern struct workqueue_struct *pm_wq;
> +
> +enum {
> +	DEBUG_EXIT_SUSPEND = 1U << 0,
> +	DEBUG_WAKEUP = 1U << 1,
> +	DEBUG_USER_STATE = 1U << 2,
> +	DEBUG_SUSPEND = 1U << 3,
> +	DEBUG_SUSPEND_BLOCKER = 1U << 4,
> +};
> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
> +
> +#define SB_INITIALIZED            (1U << 8)
> +#define SB_ACTIVE                 (1U << 9)
> +
> +static DEFINE_SPINLOCK(list_lock);
> +static DEFINE_SPINLOCK(state_lock);
> +static LIST_HEAD(inactive_blockers);
> +static LIST_HEAD(active_blockers);
> +static int current_event_num;
> +struct suspend_blocker main_suspend_blocker;
> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
> +static bool enable_suspend_blockers;
> +
> +#define pr_info_time(fmt, args...) \
> +	do { \
> +		struct timespec ts; \
> +		struct rtc_time tm; \
> +		getnstimeofday(&ts); \
> +		rtc_time_to_tm(ts.tv_sec, &tm); \
> +		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
> +			args, \
> +			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
> +			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
> +	} while (0);
> +
> +static void print_active_blockers_locked(void)
> +{
> +	struct suspend_blocker *blocker;
> +
> +	list_for_each_entry(blocker, &active_blockers, link)
> +		pr_info("active suspend blocker %s\n", blocker->name);
> +}
> +
> +/**
> + * suspend_is_blocked() - Check if suspend should be blocked
> + *
> + * suspend_is_blocked can be used by generic power management code to abort
> + * suspend.
> + *
> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
> + * is called during suspend initiated from the suspend_block code.
> + */
> +bool suspend_is_blocked(void)
> +{
> +	if (!enable_suspend_blockers)
> +		return 0;
> +	return !list_empty(&active_blockers);
> +}
> +
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = true;
> +	while (!suspend_is_blocked()) {
> +		entry_event_num = current_event_num;
> +
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: enter suspend\n");
> +
> +		ret = pm_suspend(requested_suspend_state);
> +
> +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> +
> +		if (current_event_num == entry_event_num)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +	}
> +	enable_suspend_blockers = false;
> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in debug messages.
> + *
> + * The suspend blocker struct and name must not be freed before calling
> + * suspend_blocker_destroy.
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	unsigned long irqflags = 0;
> +
> +	WARN_ON(!name);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", name);
> +
> +	blocker->name = name;
> +	blocker->flags = SB_INITIALIZED;
> +	INIT_LIST_HEAD(&blocker->link);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	list_add(&blocker->link, &inactive_blockers);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);
> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags &= ~SB_INITIALIZED;
> +	list_del(&blocker->link);
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(pm_wq, &suspend_work);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +
> +	blocker->flags |= SB_ACTIVE;
> +	list_move(&blocker->link, &active_blockers);
> +	current_event_num++;
> +
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	list_move(&blocker->link, &inactive_blockers);
> +
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(pm_wq, &suspend_work);
> +	blocker->flags &= ~(SB_ACTIVE);
> +	if (blocker == &main_suspend_blocker) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			print_active_blockers_locked();
> +	}
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + *
> + * Returns true if the suspend_blocker is currently active.
> + */
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker)
> +{
> +	WARN_ON(!(blocker->flags & SB_INITIALIZED));
> +
> +	return !!(blocker->flags & SB_ACTIVE);
> +}
> +EXPORT_SYMBOL(suspend_blocker_is_active);
> +
> +bool request_suspend_valid_state(suspend_state_t state)
> +{
> +	return (state == PM_SUSPEND_ON) || valid_state(state);
> +}
> +
> +int request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +
> +	if (!request_suspend_valid_state(state))
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&state_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_USER_STATE)
> +		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
> +			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			     requested_suspend_state, state,
> +			     ktime_to_ns(ktime_get()));
> +
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +	return 0;
> +}
> +
> +void __init suspend_block_init(void)
> +{
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +}
> -- 
> 1.6.5.1
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Mon, 3 May 2010, mark gross wrote:

> You know things would be so much easier if the policy was a one-shot
> styled thing.  i.e. when enabled it does what it does, but upon resume
> the policy must be re-enabled by user mode to get the opportunistic
> behavior.  That way we don't need to grab the suspend blocker from the
> wake up irq handler all the way up to user mode as the example below
> calls out.  I suppose doing this would put a burden on the user mode code
> to keep track of if it has no pending blockers registered after a wake
> up from the suspend.  but that seems nicer to me than sprinkling
> overlapping blocker critical sections from the mettle up to user mode.
> 
> Please consider making the policy a one shot API that needs to be
> re-enabled after resume by user mode.  That would remove my issue with
> the design.

This won't work right if a second IRQ arrives while the first is being
processed.  Suppose the kernel driver for the second IRQ doesn't
activate a suspend blocker, and suppose all the userspace handlers for
the first IRQ end (and the opportunistic policy is re-enabled) before
the userspace handler for the second IRQ can start.  Then the system
will go back to sleep before userspace can handle the second IRQ.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Tue, May 04, 2010 at 09:59:59AM -0400, Alan Stern wrote:
> On Mon, 3 May 2010, mark gross wrote:
> 
> > You know things would be so much easier if the policy was a one-shot
> > styled thing.  i.e. when enabled it does what it does, but upon resume
> > the policy must be re-enabled by user mode to get the opportunistic
> > behavior.  That way we don't need to grab the suspend blocker from the
> > wake up irq handler all the way up to user mode as the example below
> > calls out.  I suppose doing this would put a burden on the user mode code
> > to keep track of if it has no pending blockers registered after a wake
> > up from the suspend.  but that seems nicer to me than sprinkling
> > overlapping blocker critical sections from the mettle up to user mode.
> > 
> > Please consider making the policy a one shot API that needs to be
> > re-enabled after resume by user mode.  That would remove my issue with
> > the design.
> 
> This won't work right if a second IRQ arrives while the first is being
> processed.  Suppose the kernel driver for the second IRQ doesn't
> activate a suspend blocker, and suppose all the userspace handlers for
> the first IRQ end (and the opportunistic policy is re-enabled) before
> the userspace handler for the second IRQ can start.  Then the system
> will go back to sleep before userspace can handle the second IRQ.
>

What?  If the suspend blocker API was a one shot styled api, after the
suspend, the one shot is over and the behavior is that you do not fall
back into suspend again until user mode re-enables the one-shot
behavior.  

With what I am proposing the next suspend would not happen until the
user mode code re-enables the suspend blocking behavior.  It would much
cleaner for everyone and I see zero down side WRT the example you just
posted.  

If user mode triggers a suspend by releasing the last blocker, you have
until pm_suspend('mem') turns off interrupts to cancel it.  That race
will never go away. 

Let me think this through, please check that I'm understanding the issue
please:
1) one-shot policy enable blocker PM suspend behavior;
2) release last blocker and call pm_suspend('mem') and suspend all the
way down.
3) get wake up event, one-shot policy over, no-blockers in list
4) go all the way to user mode, 
5) user mode decides to not grab a blocker, and re-enables one-shot
policy
6) pm_suspend('mem') called
7) interrupt comes in (say the modem rings)
8) modem driver handler needs to returns fail from pm_suspend call back,
device resumes (I am proposing changing the posted api for doing this.)
9) user mode figures out one-shot needs to be re-enabled and it grabs a
blocker to handle the call and re-enables the one-shot.

So the real problem grabbing blockers from ISR's trying to solve is to
reduce the window of time where a pm_suspend('mem') can be canceled.

My proposal is to;
1) change the kernel blocker api to be
"cancel-one-shot-policy-enable" that can be called from the ISR's for
the wake up devices before the IRQ's are disabled to cancel an in-flight
suspend.  I would make it 2 macros one goes in the pm_suspend callback
to return fail, and the other in the ISR to disable the one-shot-policy.
 
2) make the policy a one shot that user mode must re-enable after each
suspend attempted.

Would it help if I coded up the above proposal as patch to the current
(rev-6) of the blocker patchset?  I'm offering.

Because this part of the current design is broken, in that it demands
the sprinkling of blocker critical sections from the hardware up to the
user mode.  Its ugly, hard to get right and if more folks would take a
look at how well it worked out for the existing kernels on
android.git.kernel.org/kernels/ perhaps it would get more attention.

Finally, as an aside, lets look at the problem with the posted rev-6
patches:
1) enable suspend blocker policy
2) release user-mode blocker
3) start suspend
4) get a modem interrupt (incoming call)
5) ooops, IRQ came in after pm_suspend('mem') turned off interrupts.
bummer for you, thats life with this design.  Better hope your modem
hardware is modified to keep pulling on that wake up line because you're
past the point of no return now and going to suspend.

Grabbing a blocker in the ISR doesn't solve this.  So your hardware
needs to have a persistent wake up trigger that is robust against this
scenario.  And, if you have such hardware then why are we killing
ourselves to maximize the window of time between pm_suspend('mem') and
platform suspend where you can cancel the suspend?  The hardware will
simply wake up anyway.

(further, on my hardware I would modify the platform suspend call back
to make one last check to see if an IRQ came in, and cancel the suspend
there as a last chance.)

 
--mgross

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2010/5/3 mark gross <640e9920@gmail.com>:
> On Fri, Apr 30, 2010 at 03:36:54PM -0700, Arve Hjønnevåg wrote:
...
>> +When the policy is "opportunisic", there is a special value, "on", that can be
>> +written to /sys/power/state. This will block the automatic sleep request, as if
>> +a suspend blocker was used by a device driver. This way the opportunistic
>> +suspend may be blocked by user space whithout switching back to the "forced"
>> +mode.
>
> You know things would be so much easier if the policy was a one-shot
> styled thing.  i.e. when enabled it does what it does, but upon resume
> the policy must be re-enabled by user mode to get the opportunistic
> behavior.  That way we don't need to grab the suspend blocker from the
> wake up irq handler all the way up to user mode as the example below
> calls out.  I suppose doing this would put a burden on the user mode code
> to keep track of if it has no pending blockers registered after a wake
> up from the suspend.  but that seems nicer to me than sprinkling
> overlapping blocker critical sections from the mettle up to user mode.
>
> Please consider making the policy a one shot API that needs to be
> re-enabled after resume by user mode.  That would remove my issue with
> the design.
>

Making it one shot does not change where kernel code needs to block
suspend, but it does force user space to poll trying to suspend while
suspend is blocked by a driver.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6285 bytes --]

Hi,

Some comments on the opportunistic suspend portion of this patch.

On Fri, 30 Apr 2010, Arve Hjønnevåg wrote:

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  Documentation/power/opportunistic-suspend.txt |  119 +++++++++++
>  include/linux/suspend_blocker.h               |   64 ++++++
>  kernel/power/Kconfig                          |   16 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/main.c                           |   92 ++++++++-
>  kernel/power/power.h                          |    9 +
>  kernel/power/suspend.c                        |    4 +-
>  kernel/power/suspend_blocker.c                |  261 +++++++++++++++++++++++++
>  8 files changed, 559 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/power/opportunistic-suspend.txt
>  create mode 100755 include/linux/suspend_blocker.h
>  create mode 100644 kernel/power/suspend_blocker.c


While reading the patch, it seemed that this opportunistic suspend
mechanism is a degenerate case of a system-wide form of CPUIdle.  I'll
call it "SystemIdle," for lack of a better term.  The main difference
between this and the CPUIdle design is that this patch's SystemIdle is
not integrated with any of the existing Linux mechanisms for limiting
idle duration or depth.  This is a major problem with the current
patch and should prevent it from being merged in its current state.
But if some SystemIdle-type code were to be written that did work with
the rest of the Linux kernel, it would be very useful.

To take an example from the current Linux-OMAP kernels: right now, the
Linux-OMAP code handles system-level idle through CPUIdle.[1] To
borrow ACPI terminology, some of the S-states are implemented as
C-states.  That isn't right, for several reasons:

- There are other constraints on system-level idle modes beyond those
  that apply to the CPU.  To take an OMAP example, on boards that
  support it, OMAP2+ chips can cut power to the external SoC
  high-frequency clock oscillator ("HF oscillator").[2] This is the
  clock that is later used to drive the CPU clock, bus clock, etc., on
  the SoC, but can also be used to drive other chips on the board,
  such as external audio codec chips, GPS receivers, etc.)  If power
  is cut to the HF oscillator, it can take several milliseconds to
  stabilize once power is reapplied.  Part of the decision as to
  whether to cut power to the HF oscillator is a classic idle
  balancing test between power economy and wakeup latency.  But this
  occurs on a system level - the CPU may not even be involved.

  Consider a low-power audio playback use-case.  The CPU may be only
  rarely involved, but other devices on the SoC may need to be active.
  For example, if a large number of audio samples are loaded into main
  memory, the CPU can go into a very deep sleep state while the DMA
  controller transfers the samples to the audio serial interface
  device.  But the DMA controller and audio serial interface need to
  run occasionally, so depending on FIFO depths in the system, the HF
  oscillator clock may need to be kept on, even if the CPU idle level
  would suggest that it could be disabled.

  Additionally, other external chips outside the SoC, may be clocked
  by that HF oscillator.  Continuing the low-power audio playback
  use-case, the external audio codec chip may also be clocked from the
  HF oscillator.  If the HF oscillator is cut when the SoC is idle,
  but the audio codec has samples in its buffer, audio playback will
  be disrupted.

- There should be only one system-level governor.  Since all of the
  production OMAPs so far have been single-CPU systems, we've been
  able to get away with this.  But on multi-CPU systems, there is one
  CPUIdle governor per CPU.  So reusing the CPUIdle governor to do this
  won't work the same way as it has for us in the past.

So some good SystemIdle-type code would be really useful for us.  But a 
significant part of what "good" means is that such a SystemIdle needs to 
be driven from the bottom up, rather than from the top down. In other 
words, both the 'policy' (i.e., the choice of metrics to use to determine 
the system idle state), and the 'implementation of that policy' (i.e., the 
way to enter those idle states), should be left up to the underlying chip 
architecture code that would implement SystemIdle client drivers.  (In 
this regard, it would be even more different than CPUIdle, which hardcodes 
the policy.)

This way, at least initially, there will be minimal top-down
restrictions on what architectures need to do to implement to their
chip's power management features.  As common features are identified,
by individual architectures implementing working code, then the
architecture developers can collaborate, and common components can be
proposed for merging into the top-level SystemIdle code.

Such a SystemIdle implementation should also work for Android's
opportunistic suspend code.  Google developers could choose the system
metrics that they wish to use to control system idle levels.  If they
want to ignore timers and the scheduler, that's fine - that design
decision can be confined to their policy driver, and the suspend-block
code can be activated the moment that some driver sets a PM
constraint, rather than doing anything more refined.  Similarly,
Google can change the way that the policy decisions are implemented.
Google could use a driver that does not take any advantage of
fine-grained power management aside from CPUIdle.  This driver could
simply enter full system suspend whenever the policy driver authorizes
it to do.

This approach - or some similar approach - should allow Android to do what 
it needs, while still allowing other, more finely-grained power management 
approaches to do something different.


regards,

- Paul

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Paul Walmsley]

On Thu, 13 May 2010, Paul Walmsley wrote:

> Some comments on the opportunistic suspend portion of this patch.

...

> While reading the patch, it seemed that this opportunistic suspend
> mechanism is a degenerate case of a system-wide form of CPUIdle.  I'll
> call it "SystemIdle," for lack of a better term.

The footnotes for this E-mail were inadvertently omitted.  Sorry about 
that.  They are:


1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/cpuidle34xx.c;h=3d3d035db9aff62ce522e0080e570cfdbf8e70cc;hb=4462dc02842698f173f518c1f5ce79c0fb89395a#l292

2. OMAP35x Technical Reference Manual Rev. F, section 4.7.5.2 "System
   Clock Oscillator Control": http://www.ti.com/litv/pdf/spruf98f

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Wed, 28 Apr 2010, Arve Hjønnevåg wrote:

> >> >  suspend blockers can be used to allow
> >> > +user-space to decide whether a keystroke received while the system is suspended
> >> > +should cause the screen to be turned back on or allow the system to go back into
> >> > +suspend.
> >>
> >> That's not right.  Handling the screen doesn't need suspend blockers:
> >> The program decides what to do and then either turns on the screen or
> >> else writes "mem" to /sys/power/state.
> 
> That does not work though. Unless every key turns the screen on you
> will have a race every time the user presses a key you want to ignore.

Of course.  You are confirming what I wrote immediately below: Suspend
blockers help resolve races.  Note that this race has nothing to do
with the _screen_ in particular -- exactly the same race occurs if you
decide to turn on the audio speaker or some other piece of hardware.

> >>  What suspend blockers add is
> >> the ability to resolve races and satisfy multiple constraints when
> >> going into suspend -- which has nothing to do with operating the
> >> screen.
> 
> I'm not sure I agree with this. You cannot reliably turn the screen on
> from user space when the user presses a wakeup-key without suspend
> blockers.

Let's say that it has nothing to do _specifically_ with the screen.  
_Any_ action you want to take in userspace is difficult to coordinate 
with system suspends if you don't have suspend blockers.

> >>
> >> I _think_ what you're trying to get at can be expressed this way:
> >>
> >>       Here's an example showing how a cell phone or other embedded
> >>       system can handle keystrokes (or other input events) in the
> >>       presence of suspend blockers.  Use set_irq_wake...
> 
> OK, but the last version was what you (Alan) suggested last year.

So at least my mental processes have remained consistent over the span
of a year.  Nice to know I haven't undergone a complete personality 
change...  :-)

> >>       ...
> >>
> >>       - The user-space input-event thread returns from read.  It
> >>       carries out whatever activities are appropriate (for example,
> >>       powering up the display screen, running other programs, and so
> >>       on).  When it is finished, it calls suspend_unblock on the
> >>       process_input_events suspend_blocker and then calls select or
> >>       poll.  The system will automatically suspend again when it is
> >>       idle and no suspend blockers remain active.
> >
> > Yeah, that sounds better.  Arve, what do you think?
> >
> 
> Idle is irrelevant and needs to be removed. This new last step is also
> no longer a concrete example, but if you really think is it better I
> can change it.

Perhaps you would prefer to change this completely.  Write up a 
description of what can go wrong when suspend blockers _aren't_ used, 
and show how suspend blockers can prevent the problem from occurring.

But whatever you do, don't make it appear that suspend blockers allow
user programs to make decisions (which is what you wrote before).  They 
don't -- programs can make whatever decisions they want.  Suspend 
blockers merely help them carry out the actions they have decided upon 
in a safe manner.

And don't make it appear that suspend blockers can only be used for
solving screen-related problems.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2010/4/29 Alan Stern <stern@rowland.harvard.edu>:
> On Wed, 28 Apr 2010, Arve Hjønnevåg wrote:
>
>> >> >  suspend blockers can be used to allow
>> >> > +user-space to decide whether a keystroke received while the system is suspended
>> >> > +should cause the screen to be turned back on or allow the system to go back into
>> >> > +suspend.
>> >>
>> >> That's not right.  Handling the screen doesn't need suspend blockers:
>> >> The program decides what to do and then either turns on the screen or
>> >> else writes "mem" to /sys/power/state.
>>
>> That does not work though. Unless every key turns the screen on you
>> will have a race every time the user presses a key you want to ignore.
>
> Of course.  You are confirming what I wrote immediately below: Suspend
Yet you offered it as an example of why "Handling the screen doesn't
need suspend blockers".

> blockers help resolve races.  Note that this race has nothing to do
> with the _screen_ in particular -- exactly the same race occurs if you
> decide to turn on the audio speaker or some other piece of hardware.
>
I agree with this, but that does not mean that describing how you can
handle the screen with suspend blockers is a bad example.

>> >>  What suspend blockers add is
>> >> the ability to resolve races and satisfy multiple constraints when
>> >> going into suspend -- which has nothing to do with operating the
>> >> screen.
>>
>> I'm not sure I agree with this. You cannot reliably turn the screen on
>> from user space when the user presses a wakeup-key without suspend
>> blockers.
>
> Let's say that it has nothing to do _specifically_ with the screen.
> _Any_ action you want to take in userspace is difficult to coordinate
> with system suspends if you don't have suspend blockers.
>
>> >>
>> >> I _think_ what you're trying to get at can be expressed this way:
>> >>
>> >>       Here's an example showing how a cell phone or other embedded
>> >>       system can handle keystrokes (or other input events) in the
>> >>       presence of suspend blockers.  Use set_irq_wake...
>>
>> OK, but the last version was what you (Alan) suggested last year.
>
> So at least my mental processes have remained consistent over the span
> of a year.  Nice to know I haven't undergone a complete personality
> change...  :-)
>
>> >>       ...
>> >>
>> >>       - The user-space input-event thread returns from read.  It
>> >>       carries out whatever activities are appropriate (for example,
>> >>       powering up the display screen, running other programs, and so
>> >>       on).  When it is finished, it calls suspend_unblock on the
>> >>       process_input_events suspend_blocker and then calls select or
>> >>       poll.  The system will automatically suspend again when it is
>> >>       idle and no suspend blockers remain active.
>> >
>> > Yeah, that sounds better.  Arve, what do you think?
>> >
>>
>> Idle is irrelevant and needs to be removed. This new last step is also
>> no longer a concrete example, but if you really think is it better I
>> can change it.
>
> Perhaps you would prefer to change this completely.  Write up a
> description of what can go wrong when suspend blockers _aren't_ used,
> and show how suspend blockers can prevent the problem from occurring.
>
> But whatever you do, don't make it appear that suspend blockers allow
> user programs to make decisions (which is what you wrote before).  They
> don't -- programs can make whatever decisions they want.  Suspend
> blockers merely help them carry out the actions they have decided upon
> in a safe manner.

I think suspend blockers do allow user programs to make decisions.
Without suspend blockers some decisions can only be safely be made in
the kernel/drivers.

>
> And don't make it appear that suspend blockers can only be used for
> solving screen-related problems.

How about:

- The user-space input-event thread returns from read. If it
determines that the key should be ignored, it calls suspend_unblock on
the process_input_events suspend_blocker and then calls select or
poll. The system will automatically suspend again, since now no
suspend blockers are active.

If the key that was pressed instead should preform a simple action
(for example, adjusting the volume), this action can be performed
right before calling suspend_unblock on the process_input_events
suspend_blocker. However, if the key triggers a longer-running action,
that action needs its own suspend_blocker and suspend_block must be
called on that suspend blocker before calling suspend_unblock on the
process_input_events suspend_blocker.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Thu, 29 Apr 2010, Arve Hjønnevåg wrote:

> >> That does not work though. Unless every key turns the screen on you
> >> will have a race every time the user presses a key you want to ignore.
> >
> > Of course.  You are confirming what I wrote immediately below: Suspend
> Yet you offered it as an example of why "Handling the screen doesn't
> need suspend blockers".

What I meant was this: Without suspend blockers you can still turn the
screen on and off, but you can't avoid races.  Therefore: You don't
need suspend blockers to handle the screen, but you do need them to
handle races.

> > blockers help resolve races.  Note that this race has nothing to do
> > with the _screen_ in particular -- exactly the same race occurs if you
> > decide to turn on the audio speaker or some other piece of hardware.
> >
> I agree with this, but that does not mean that describing how you can
> handle the screen with suspend blockers is a bad example.

Agreed; it's not a bad example.  My objection is to the way the example
is presented.

> I think suspend blockers do allow user programs to make decisions.
> Without suspend blockers some decisions can only be safely be made in
> the kernel/drivers.

This is our real disagreement -- it's mainly a question of the meaning
of words.  When one says "A allows B to make a decision", this means
that without A, B would literally be unable to decide what to do.  It
wouldn't be able to "make up its mind" (like the donkey that starves
while stuck halfway between two piles of hay because it can't decide 
which pile to eat).

That's not what you mean to say.  In your case there's no difficulty in
making the choice -- the program knows exactly what it wants to do.  
The problem is that without suspend blockers, it can't _carry out_ the
chosen action.  To put it another way, the suspend blockers don't help
with deciding which action to take; rather they help with taking the
action after it has been decided upon.

Or put this way: Suppose suspend blockers were not available.  Then the
desired action would not be safe, so the program wouldn't be able to
take it.  The decision would thus be even simpler, since one of the
choices would be eliminated.  In this way, lack of suspend blockers
makes the decision easier, not harder.  So you shouldn't say that
suspend blockers allow the program to make the decision.

What your example _really_ shows is how a program can carry out a 
prolonged action that requires the system to be awake for an extended 
period of time.  Even with suspend blockers, the right way to do this 
safely isn't necessarily obvious.  That's how the example helps.

> How about:
> 
> - The user-space input-event thread returns from read. If it
> determines that the key should be ignored, it calls suspend_unblock on
> the process_input_events suspend_blocker and then calls select or
> poll. The system will automatically suspend again, since now no
> suspend blockers are active.

Do you want to mention here that everything will work correctly even if 
the system suspends before the thread can call select or poll?

> If the key that was pressed instead should preform a simple action
> (for example, adjusting the volume), this action can be performed
> right before calling suspend_unblock on the process_input_events
> suspend_blocker. However, if the key triggers a longer-running action,
> that action needs its own suspend_blocker and suspend_block must be
> called on that suspend blocker before calling suspend_unblock on the
> process_input_events suspend_blocker.

That's good!  I like it.  Now if you can change the beginning of the
example, to say that it shows how programs should use suspend blockers
instead of showing that suspend blockers allow programs to make
decisions.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Wednesday 28 April 2010, Alan Stern wrote:
> On Tue, 27 Apr 2010, [UTF-8] Arve Hjønnevåg wrote:
> 
> > +For example, in cell phones or other embedded systems, where powering the screen
> > +is a significant drain on the battery, suspend blockers can be used to allow
> > +user-space to decide whether a keystroke received while the system is suspended
> > +should cause the screen to be turned back on or allow the system to go back into
> > +suspend. 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 calls suspend_block on the
> > +  keypad-scan suspend_blocker 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 calls
> > +  suspend_block on the input-event-queue suspend_blocker.
> > +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> > +  on the keypad-scan suspend_blocker.
> > +- The user-space input-event thread returns from select/poll, calls
> > +  suspend_block on the process-input-events suspend_blocker and then calls read
> > +  on the input-event device.
> > +- The input-event driver dequeues the key-event and, since the queue is now
> > +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> > +- The user-space input-event thread returns from read. If it determines that
> > +  the key should leave the screen off, it calls suspend_unblock on the
> > +  process_input_events suspend_blocker and then calls select or poll. The
> > +  system will automatically suspend again, since now no suspend blockers are
> > +  active.
> > +
> > +                 Key pressed   Key released
> > +                     |             |
> > +keypad-scan          ++++++++++++++++++
> > +input-event-queue        +++          +++
> > +process-input-events       +++          +++
> 
> This is better than before, but it still isn't ideal.  Here's what I 
> mean:
> 
> >  suspend blockers can be used to allow
> > +user-space to decide whether a keystroke received while the system is suspended
> > +should cause the screen to be turned back on or allow the system to go back into
> > +suspend.
> 
> That's not right.  Handling the screen doesn't need suspend blockers:
> The program decides what to do and then either turns on the screen or
> else writes "mem" to /sys/power/state.  What suspend blockers add is
> the ability to resolve races and satisfy multiple constraints when
> going into suspend -- which has nothing to do with operating the
> screen.
> 
> I _think_ what you're trying to get at can be expressed this way:
> 
> 	Here's an example showing how a cell phone or other embedded
> 	system can handle keystrokes (or other input events) in the 
> 	presence of suspend blockers.  Use set_irq_wake...
> 
> 	...
> 
>       - The user-space input-event thread returns from read.  It 
> 	carries out whatever activities are appropriate (for example,
> 	powering up the display screen, running other programs, and so 
> 	on).  When it is finished, it calls suspend_unblock on the
> 	process_input_events suspend_blocker and then calls select or
> 	poll.  The system will automatically suspend again when it is
> 	idle and no suspend blockers remain active.

Yeah, that sounds better.  Arve, what do you think?

> > +/**
> > + * suspend_block() - Block suspend
> > + * @blocker:	The suspend blocker to use
> > + *
> > + * It is safe to call this function from interrupt context.
> > + */
> > +void suspend_block(struct suspend_blocker *blocker)
> > +{
> > +	unsigned long irqflags;
> > +
> > +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> > +		return;
> > +
> > +	spin_lock_irqsave(&list_lock, irqflags);
> > +	blocker->flags |= SB_ACTIVE;
> > +	list_del(&blocker->link);
> > +
> > +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> > +		pr_info("suspend_block: %s\n", blocker->name);
> > +
> > +	list_add(&blocker->link, &active_blockers);
> 
> Here and in suspend_unblock(), you can use list_move() in place of 
> list_del() followed by list_add().

Indeed.  And the debug statement might be moved out of the critical section IMHO.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2010/4/28 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 28 April 2010, Alan Stern wrote:
>> On Tue, 27 Apr 2010, [UTF-8] Arve Hjønnevåg wrote:
>>
>> > +For example, in cell phones or other embedded systems, where powering the screen
>> > +is a significant drain on the battery, suspend blockers can be used to allow
>> > +user-space to decide whether a keystroke received while the system is suspended
>> > +should cause the screen to be turned back on or allow the system to go back into
>> > +suspend. 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 calls suspend_block on the
>> > +  keypad-scan suspend_blocker 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 calls
>> > +  suspend_block on the input-event-queue suspend_blocker.
>> > +- The keypad-scan code detects that no keys are held and calls suspend_unblock
>> > +  on the keypad-scan suspend_blocker.
>> > +- The user-space input-event thread returns from select/poll, calls
>> > +  suspend_block on the process-input-events suspend_blocker and then calls read
>> > +  on the input-event device.
>> > +- The input-event driver dequeues the key-event and, since the queue is now
>> > +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
>> > +- The user-space input-event thread returns from read. If it determines that
>> > +  the key should leave the screen off, it calls suspend_unblock on the
>> > +  process_input_events suspend_blocker and then calls select or poll. The
>> > +  system will automatically suspend again, since now no suspend blockers are
>> > +  active.
>> > +
>> > +                 Key pressed   Key released
>> > +                     |             |
>> > +keypad-scan          ++++++++++++++++++
>> > +input-event-queue        +++          +++
>> > +process-input-events       +++          +++
>>
>> This is better than before, but it still isn't ideal.  Here's what I
>> mean:
>>
>> >  suspend blockers can be used to allow
>> > +user-space to decide whether a keystroke received while the system is suspended
>> > +should cause the screen to be turned back on or allow the system to go back into
>> > +suspend.
>>
>> That's not right.  Handling the screen doesn't need suspend blockers:
>> The program decides what to do and then either turns on the screen or
>> else writes "mem" to /sys/power/state.

That does not work though. Unless every key turns the screen on you
will have a race every time the user presses a key you want to ignore.

>>  What suspend blockers add is
>> the ability to resolve races and satisfy multiple constraints when
>> going into suspend -- which has nothing to do with operating the
>> screen.

I'm not sure I agree with this. You cannot reliably turn the screen on
from user space when the user presses a wakeup-key without suspend
blockers.

>>
>> I _think_ what you're trying to get at can be expressed this way:
>>
>>       Here's an example showing how a cell phone or other embedded
>>       system can handle keystrokes (or other input events) in the
>>       presence of suspend blockers.  Use set_irq_wake...

OK, but the last version was what you (Alan) suggested last year.

>>
>>       ...
>>
>>       - The user-space input-event thread returns from read.  It
>>       carries out whatever activities are appropriate (for example,
>>       powering up the display screen, running other programs, and so
>>       on).  When it is finished, it calls suspend_unblock on the
>>       process_input_events suspend_blocker and then calls select or
>>       poll.  The system will automatically suspend again when it is
>>       idle and no suspend blockers remain active.
>
> Yeah, that sounds better.  Arve, what do you think?
>

Idle is irrelevant and needs to be removed. This new last step is also
no longer a concrete example, but if you really think is it better I
can change it.

>> > +/**
>> > + * suspend_block() - Block suspend
>> > + * @blocker:       The suspend blocker to use
>> > + *
>> > + * It is safe to call this function from interrupt context.
>> > + */
>> > +void suspend_block(struct suspend_blocker *blocker)
>> > +{
>> > +   unsigned long irqflags;
>> > +
>> > +   if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
>> > +           return;
>> > +
>> > +   spin_lock_irqsave(&list_lock, irqflags);
>> > +   blocker->flags |= SB_ACTIVE;
>> > +   list_del(&blocker->link);
>> > +
>> > +   if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> > +           pr_info("suspend_block: %s\n", blocker->name);
>> > +
>> > +   list_add(&blocker->link, &active_blockers);
>>
>> Here and in suspend_unblock(), you can use list_move() in place of
>> list_del() followed by list_add().
>

OK.

> Indeed.  And the debug statement might be moved out of the critical section IMHO.
>

If I move the debug statements out of the critical section you could
end entering suspend while the debug log claims a suspend blocker was
active, but I can move the debug statement to the start of the
critical section.

-- 
Arve Hjønnevåg

[PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

Adds /sys/power/policy that selects the behaviour of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/opportunistic-suspend.txt |  114 +++++++++++
 include/linux/suspend_blocker.h               |   64 ++++++
 kernel/power/Kconfig                          |   16 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/main.c                           |   89 ++++++++-
 kernel/power/power.h                          |    5 +
 kernel/power/suspend.c                        |    4 +-
 kernel/power/suspend_blocker.c                |  269 +++++++++++++++++++++++++
 8 files changed, 556 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/power/opportunistic-suspend.txt
 create mode 100755 include/linux/suspend_blocker.h
 create mode 100644 kernel/power/suspend_blocker.c

diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
new file mode 100644
index 0000000..1a29d10
--- /dev/null
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -0,0 +1,114 @@
+Opportunistic Suspend
+=====================
+
+Opportunistic suspend is a feature allowing the system to be suspended (ie. put
+into one of the available sleep states) automatically whenever it is regarded
+as idle.  The suspend blockers framework described below is used to determine
+when that happens.
+
+The /sys/power/policy sysfs attribute is used to switch the system between the
+opportunistic and "forced" suspend behavior, where in the latter case the
+system is only suspended if a specific value, corresponding to one of the
+available system sleep states, is written into /sys/power/state.  However, in
+the former, opportunistic, case the system is put into the sleep state
+corresponding to the value written to /sys/power/state whenever there are no
+active suspend blockers. The default policy is "forced". Also, suspend blockers
+do not affect sleep states entered from idle.
+
+When the policy is "opportunisic", there is a special value, "on", that can be
+written to /sys/power/state. This will block the automatic sleep request, as if
+a suspend blocker was used by a device driver. This way the opportunistic
+suspend may be blocked by user space whithout switching back to the "forced"
+mode.
+
+A suspend blocker is an object used to inform the PM subsystem when the system
+can or cannot be suspended in the "opportunistic" mode (the "forced" mode
+ignores suspend blockers).  To use it, a device driver creates a struct
+suspend_blocker that must be initialized with suspend_blocker_init(). Before
+freeing the suspend_blocker structure or its name, suspend_blocker_destroy()
+must be called on it.
+
+A suspend blocker is activated using suspend_block(), which prevents the PM
+subsystem from putting the system into the requested sleep state in the
+"opportunistic" mode until the suspend blocker is deactivated with
+suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
+the system will not suspend as long as at least one of them is active.
+
+If opportunistic suspend is already in progress when suspend_block() is called,
+it will abort the suspend, unless suspend_ops->enter has already been
+executed. If suspend is aborted this way, the system is usually not fully
+operational at that point. The suspend callbacks of some drivers may still be
+running and it usually takes time to restore the system to the fully operational
+state.
+
+For example, in cell phones or other embedded systems, where powering the screen
+is a significant drain on the battery, suspend blockers can be used to allow
+user-space to decide whether a keystroke received while the system is suspended
+should cause the screen to be turned back on or allow the system to go back into
+suspend. 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 calls suspend_block on the
+  keypad-scan suspend_blocker 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 calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should leave the screen off, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block api by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init. For instance:
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
+}
+
+Before freeing the memory, suspend_blocker_destroy must be called:
+
+uninit() {
+	suspend_blocker_destroy(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block:
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock:
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block when the suspend blocker is active or suspend_unblock when
+it is not active has no effect (i.e., these functions don't nest). This allows
+drivers to update their state and call suspend suspend_block or suspend_unblock
+based on the result.
+For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
+
diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
new file mode 100755
index 0000000..f9928cc
--- /dev/null
+++ b/include/linux/suspend_blocker.h
@@ -0,0 +1,64 @@
+/* include/linux/suspend_blocker.h
+ *
+ * Copyright (C) 2007-2009 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_SUSPEND_BLOCKER_H
+#define _LINUX_SUSPEND_BLOCKER_H
+
+#include <linux/list.h>
+
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @link:	List entry for active or inactive list.
+ * @flags:	Tracks initialized and active state.
+ * @name:	Name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * opportunistic suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
+ */
+
+struct suspend_blocker {
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct list_head    link;
+	int                 flags;
+	const char         *name;
+#endif
+};
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
+void suspend_blocker_destroy(struct suspend_blocker *blocker);
+void suspend_block(struct suspend_blocker *blocker);
+void suspend_unblock(struct suspend_blocker *blocker);
+bool suspend_blocker_is_active(struct suspend_blocker *blocker);
+bool suspend_is_blocked(void);
+
+#else
+
+static inline void suspend_blocker_init(struct suspend_blocker *blocker,
+					const char *name) {}
+static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
+static inline void suspend_block(struct suspend_blocker *blocker) {}
+static inline void suspend_unblock(struct suspend_blocker *blocker) {}
+static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
+								{ return 0; }
+static inline bool suspend_is_blocked(void) { return 0; }
+
+#endif
+
+#endif
+
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5c36ea9..55a06a1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -130,6 +130,22 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config OPPORTUNISTIC_SUSPEND
+	bool "Suspend blockers"
+	depends on PM_SLEEP
+	select RTC_LIB
+	default n
+	---help---
+	  Opportunistic sleep support.  Allows the system to be put into a sleep
+	  state opportunistically, if it doesn't do any useful work at the
+	  moment. The PM subsystem is switched into this mode of operation by
+	  writing "opportunistic" into /sys/power/policy, while writing
+	  "forced" to this file turns the opportunistic suspend feature off.
+	  In the "opportunistic" mode suspend blockers are used to determine
+	  when to suspend the system and the value written to /sys/power/state
+	  determines the sleep state the system will be put into when there are
+	  no active suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4319181..ee5276d 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
+obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= suspend_blocker.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/main.c b/kernel/power/main.c
index b58800b..5f0af6c 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -12,6 +12,7 @@
 #include <linux/string.h>
 #include <linux/resume-trace.h>
 #include <linux/workqueue.h>
+#include <linux/suspend_blocker.h>
 
 #include "power.h"
 
@@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
 unsigned int pm_flags;
 EXPORT_SYMBOL(pm_flags);
 
+struct policy {
+	const char *name;
+	bool (*valid_state)(suspend_state_t state);
+	int (*set_state)(suspend_state_t state);
+};
+static struct policy policies[] = {
+	{
+		.name		= "forced",
+		.valid_state	= valid_state,
+		.set_state	= enter_state,
+	},
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	{
+		.name		= "opportunistic",
+		.valid_state	= request_suspend_valid_state,
+		.set_state	= request_suspend_state,
+	},
+#endif
+};
+static int policy;
+
 #ifdef CONFIG_PM_SLEEP
 
 /* Routines for PM-transition notifications */
@@ -146,6 +168,12 @@ struct kobject *power_kobj;
  *
  *	store() accepts one of those strings, translates it into the 
  *	proper enumerated value, and initiates a suspend transition.
+ *
+ *	If policy is set to opportunistic, store() does not block until the
+ *	system resumes, and it will try to re-enter the state until another
+ *	state is requested. Suspend blockers are respected and the requested
+ *	state will only be entered when no suspend blockers are active.
+ *	Write "on" to cancel.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
@@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 
 	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
+		if (pm_states[i] && policies[policy].valid_state(i))
 			s += sprintf(s,"%s ", pm_states[i]);
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (!policy)
+		s += sprintf(s, "%s\n", "disk");
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
@@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_ON;
 	const char * const *s;
 #endif
 	char *p;
@@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 	len = p ? p - buf : n;
 
 	/* First, check if we are requested to hibernate */
-	if (len == 4 && !strncmp(buf, "disk", len)) {
+	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
 		error = hibernate();
   goto Exit;
 	}
@@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
-		error = enter_state(state);
+		error = policies[policy].set_state(state);
 #endif
 
  Exit:
@@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+/**
+ *	policy - set policy for state
+ */
+
+static ssize_t policy_show(struct kobject *kobj,
+			   struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		if (i == policy)
+			s += sprintf(s, "[%s] ", policies[i].name);
+		else
+			s += sprintf(s, "%s ", policies[i].name);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t policy_store(struct kobject *kobj,
+			    struct kobj_attribute *attr,
+			    const char *buf, size_t n)
+{
+	const char *s;
+	char *p;
+	int len;
+	int i;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		s = policies[i].name;
+		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
+			mutex_lock(&pm_mutex);
+			policies[policy].set_state(PM_SUSPEND_ON);
+			policy = i;
+			mutex_unlock(&pm_mutex);
+			return n;
+		}
+	}
+	return -EINVAL;
+}
+
+power_attr(policy);
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -231,6 +309,7 @@ power_attr(pm_trace);
 
 static struct attribute * g[] = {
 	&state_attr.attr,
+	&policy_attr.attr,
 #ifdef CONFIG_PM_TRACE
 	&pm_trace_attr.attr,
 #endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46c5a26..9b468d7 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -236,3 +236,8 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+/* kernel/power/suspend_block.c */
+extern int request_suspend_state(suspend_state_t state);
+extern bool request_suspend_valid_state(suspend_state_t state);
+
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..dc42006 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -16,10 +16,12 @@
 #include <linux/cpu.h>
 #include <linux/syscalls.h>
 #include <linux/gfp.h>
+#include <linux/suspend_blocker.h>
 
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_ON]		= "on",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -157,7 +159,7 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
 			error = suspend_ops->enter(state);
 		sysdev_resume();
 	}
diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
new file mode 100644
index 0000000..9459361
--- /dev/null
+++ b/kernel/power/suspend_blocker.c
@@ -0,0 +1,269 @@
+/* kernel/power/suspend_blocker.c
+ *
+ * Copyright (C) 2005-2010 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/rtc.h>
+#include <linux/suspend.h>
+#include <linux/suspend_blocker.h>
+#include "power.h"
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+static DEFINE_SPINLOCK(list_lock);
+static DEFINE_SPINLOCK(state_lock);
+static LIST_HEAD(inactive_blockers);
+static LIST_HEAD(active_blockers);
+static int current_event_num;
+struct workqueue_struct *suspend_work_queue;
+struct suspend_blocker main_suspend_blocker;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+
+#define pr_info_time(fmt, args...) \
+	do { \
+		struct timespec ts; \
+		struct rtc_time tm; \
+		getnstimeofday(&ts); \
+		rtc_time_to_tm(ts.tv_sec, &tm); \
+		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+			args, \
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+	} while (0);
+
+static void print_active_blockers_locked(void)
+{
+	struct suspend_blocker *blocker;
+
+	list_for_each_entry(blocker, &active_blockers, link)
+		pr_info("active suspend blocker %s\n", blocker->name);
+}
+
+/**
+ * suspend_is_blocked() - Check if suspend should be blocked
+ *
+ * suspend_is_blocked can be used by generic power management code to abort
+ * suspend.
+ *
+ * To preserve backward compatibility suspend_is_blocked returns 0 unless it
+ * is called during suspend initiated from the suspend_block code.
+ */
+bool suspend_is_blocked(void)
+{
+	if (!enable_suspend_blockers)
+		return 0;
+	return !list_empty(&active_blockers);
+}
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = true;
+	while (!suspend_is_blocked()) {
+		entry_event_num = current_event_num;
+
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: enter suspend\n");
+
+		ret = pm_suspend(requested_suspend_state);
+
+		if (debug_mask & DEBUG_EXIT_SUSPEND)
+			pr_info_time("suspend: exit suspend, ret = %d ", ret);
+
+		if (current_event_num == entry_event_num)
+			pr_info("suspend: pm_suspend returned with no event\n");
+	}
+	enable_suspend_blockers = false;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+/**
+ * suspend_blocker_init() - Initialize a suspend blocker
+ * @blocker:	The suspend blocker to initialize.
+ * @name:	The name of the suspend blocker to show in debug messages.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_destroy.
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	unsigned long irqflags = 0;
+
+	WARN_ON(!name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_init name=%s\n", name);
+
+	blocker->name = name;
+	blocker->flags = SB_INITIALIZED;
+	INIT_LIST_HEAD(&blocker->link);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&blocker->link, &inactive_blockers);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_destroy() - Destroy a suspend blocker
+ * @blocker:	The suspend blocker to destroy.
+ */
+void suspend_blocker_destroy(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags &= ~SB_INITIALIZED;
+	list_del(&blocker->link);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(suspend_work_queue, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_destroy);
+
+/**
+ * suspend_block() - Block suspend
+ * @blocker:	The suspend blocker to use
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags |= SB_ACTIVE;
+	list_del(&blocker->link);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_block: %s\n", blocker->name);
+
+	list_add(&blocker->link, &active_blockers);
+
+	current_event_num++;
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock() - Unblock suspend
+ * @blocker:	The suspend blocker to unblock.
+ *
+ * If no other suspend blockers block suspend, the system will suspend.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_unblock: %s\n", blocker->name);
+
+	list_del(&blocker->link);
+	list_add(&blocker->link, &inactive_blockers);
+
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(suspend_work_queue, &suspend_work);
+	blocker->flags &= ~(SB_ACTIVE);
+	if (blocker == &main_suspend_blocker) {
+		if (debug_mask & DEBUG_SUSPEND)
+			print_active_blockers_locked();
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
+ * @blocker:	The suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
+ */
+bool suspend_blocker_is_active(struct suspend_blocker *blocker)
+{
+	WARN_ON(!(blocker->flags & SB_INITIALIZED));
+
+	return !!(blocker->flags & SB_ACTIVE);
+}
+EXPORT_SYMBOL(suspend_blocker_is_active);
+
+bool request_suspend_valid_state(suspend_state_t state)
+{
+	return (state == PM_SUSPEND_ON) || valid_state(state);
+}
+
+int request_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+
+	if (!request_suspend_valid_state(state))
+		return -ENODEV;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+
+	if (debug_mask & DEBUG_USER_STATE)
+		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
+			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			     requested_suspend_state, state,
+			     ktime_to_ns(ktime_get()));
+
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+	spin_unlock_irqrestore(&state_lock, irqflags);
+	return 0;
+}
+
+static int __init suspend_block_init(void)
+{
+	suspend_work_queue = create_singlethread_workqueue("suspend");
+	if (!suspend_work_queue)
+		return -ENOMEM;
+
+	suspend_blocker_init(&main_suspend_blocker, "main");
+	suspend_block(&main_suspend_blocker);
+	return 0;
+}
+
+core_initcall(suspend_block_init);
-- 
1.6.5.1

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.

I really don't like how this changes semantics of 'state'. I guess I'd
prefer leaving state as is -- forced transition to hibernation while
system is set to opportunistically suspend seems sane -- and adding
something like

/sys/power/autosleep

with 'off' or 'suspend' values?


> 
> Signed-off-by: Arve Hj??nnev??g <arve@android.com>
> ---
>  Documentation/power/opportunistic-suspend.txt |  114 +++++++++++
>  include/linux/suspend_blocker.h               |   64 ++++++
>  kernel/power/Kconfig                          |   16 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/main.c                           |   89 ++++++++-
>  kernel/power/power.h                          |    5 +
>  kernel/power/suspend.c                        |    4 +-
>  kernel/power/suspend_blocker.c                |  269 +++++++++++++++++++++++++
>  8 files changed, 556 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/power/opportunistic-suspend.txt
>  create mode 100755 include/linux/suspend_blocker.h
>  create mode 100644 kernel/power/suspend_blocker.c
> 
> diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
> new file mode 100644
> index 0000000..1a29d10
> --- /dev/null
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -0,0 +1,114 @@
> +Opportunistic Suspend
> +=====================
> +
> +Opportunistic suspend is a feature allowing the system to be suspended (ie. put
> +into one of the available sleep states) automatically whenever it is regarded
> +as idle.  The suspend blockers framework described below is used to determine
> +when that happens.
> +
> +The /sys/power/policy sysfs attribute is used to switch the system between the
> +opportunistic and "forced" suspend behavior, where in the latter case the
> +system is only suspended if a specific value, corresponding to one of the
> +available system sleep states, is written into /sys/power/state.  However, in
> +the former, opportunistic, case the system is put into the sleep state
> +corresponding to the value written to /sys/power/state whenever there are no
> +active suspend blockers. The default policy is "forced". Also, suspend blockers
> +do not affect sleep states entered from idle.
> +
> +When the policy is "opportunisic", there is a special value, "on", that can be
> +written to /sys/power/state. This will block the automatic sleep request, as if
> +a suspend blocker was used by a device driver. This way the opportunistic
> +suspend may be blocked by user space whithout switching back to the "forced"
> +mode.
> +
> +A suspend blocker is an object used to inform the PM subsystem when the system
> +can or cannot be suspended in the "opportunistic" mode (the "forced" mode
> +ignores suspend blockers).  To use it, a device driver creates a struct
> +suspend_blocker that must be initialized with suspend_blocker_init(). Before
> +freeing the suspend_blocker structure or its name, suspend_blocker_destroy()
> +must be called on it.
> +
> +A suspend blocker is activated using suspend_block(), which prevents the PM
> +subsystem from putting the system into the requested sleep state in the
> +"opportunistic" mode until the suspend blocker is deactivated with
> +suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
> +the system will not suspend as long as at least one of them is active.
> +
> +If opportunistic suspend is already in progress when suspend_block() is called,
> +it will abort the suspend, unless suspend_ops->enter has already been
> +executed. If suspend is aborted this way, the system is usually not fully
> +operational at that point. The suspend callbacks of some drivers may still be
> +running and it usually takes time to restore the system to the fully operational
> +state.
> +
> +For example, in cell phones or other embedded systems, where powering the screen
> +is a significant drain on the battery, suspend blockers can be used to allow
> +user-space to decide whether a keystroke received while the system is suspended
> +should cause the screen to be turned back on or allow the system to go back into
> +suspend. 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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. If it determines that
> +  the key should leave the screen off, it calls suspend_unblock on the
> +  process_input_events suspend_blocker and then calls select or poll. The
> +  system will automatically suspend again, since now no suspend blockers are
> +  active.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++
> +
> +
> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);
> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);
> +
> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
> +it is not active has no effect (i.e., these functions don't nest). This allows
> +drivers to update their state and call suspend suspend_block or suspend_unblock
> +based on the result.
> +For instance:
> +
> +if (list_empty(&state->pending_work))
> +	suspend_unblock(&state->suspend_blocker);
> +else
> +	suspend_block(&state->suspend_blocker);
> +
> diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
> new file mode 100755
> index 0000000..f9928cc
> --- /dev/null
> +++ b/include/linux/suspend_blocker.h
> @@ -0,0 +1,64 @@
> +/* include/linux/suspend_blocker.h
> + *
> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCKER_H
> +#define _LINUX_SUSPEND_BLOCKER_H
> +
> +#include <linux/list.h>
> +
> +/**
> + * struct suspend_blocker - the basic suspend_blocker structure
> + * @link:	List entry for active or inactive list.
> + * @flags:	Tracks initialized and active state.
> + * @name:	Name used for debugging.
> + *
> + * When a suspend_blocker is active it prevents the system from entering
> + * opportunistic suspend.
> + *
> + * The suspend_blocker structure must be initialized by suspend_blocker_init()
> + */
> +
> +struct suspend_blocker {
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	struct list_head    link;
> +	int                 flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker);
> +bool suspend_is_blocked(void);
> +
> +#else
> +
> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
> +					const char *name) {}
> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
> +static inline void suspend_block(struct suspend_blocker *blocker) {}
> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
> +static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
> +								{ return 0; }
> +static inline bool suspend_is_blocked(void) { return 0; }
> +
> +#endif
> +
> +#endif
> +
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 5c36ea9..55a06a1 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -130,6 +130,22 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config OPPORTUNISTIC_SUSPEND
> +	bool "Suspend blockers"
> +	depends on PM_SLEEP
> +	select RTC_LIB
> +	default n
> +	---help---
> +	  Opportunistic sleep support.  Allows the system to be put into a sleep
> +	  state opportunistically, if it doesn't do any useful work at the
> +	  moment. The PM subsystem is switched into this mode of operation by
> +	  writing "opportunistic" into /sys/power/policy, while writing
> +	  "forced" to this file turns the opportunistic suspend feature off.
> +	  In the "opportunistic" mode suspend blockers are used to determine
> +	  when to suspend the system and the value written to /sys/power/state
> +	  determines the sleep state the system will be put into when there are
> +	  no active suspend blockers.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index 4319181..ee5276d 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
>  obj-$(CONFIG_PM_SLEEP)		+= console.o
>  obj-$(CONFIG_FREEZER)		+= process.o
>  obj-$(CONFIG_SUSPEND)		+= suspend.o
> +obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= suspend_blocker.o
>  obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
>  obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
>  obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index b58800b..5f0af6c 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -12,6 +12,7 @@
>  #include <linux/string.h>
>  #include <linux/resume-trace.h>
>  #include <linux/workqueue.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
> @@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
>  unsigned int pm_flags;
>  EXPORT_SYMBOL(pm_flags);
>  
> +struct policy {
> +	const char *name;
> +	bool (*valid_state)(suspend_state_t state);
> +	int (*set_state)(suspend_state_t state);
> +};
> +static struct policy policies[] = {
> +	{
> +		.name		= "forced",
> +		.valid_state	= valid_state,
> +		.set_state	= enter_state,
> +	},
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	{
> +		.name		= "opportunistic",
> +		.valid_state	= request_suspend_valid_state,
> +		.set_state	= request_suspend_state,
> +	},
> +#endif
> +};
> +static int policy;
> +
>  #ifdef CONFIG_PM_SLEEP
>  
>  /* Routines for PM-transition notifications */
> @@ -146,6 +168,12 @@ struct kobject *power_kobj;
>   *
>   *	store() accepts one of those strings, translates it into the 
>   *	proper enumerated value, and initiates a suspend transition.
> + *
> + *	If policy is set to opportunistic, store() does not block until the
> + *	system resumes, and it will try to re-enter the state until another
> + *	state is requested. Suspend blockers are respected and the requested
> + *	state will only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
>   */
>  static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			  char *buf)
> @@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  	int i;
>  
>  	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> -		if (pm_states[i] && valid_state(i))
> +		if (pm_states[i] && policies[policy].valid_state(i))
>  			s += sprintf(s,"%s ", pm_states[i]);
>  	}
>  #endif
>  #ifdef CONFIG_HIBERNATION
> -	s += sprintf(s, "%s\n", "disk");
> +	if (!policy)
> +		s += sprintf(s, "%s\n", "disk");
>  #else
>  	if (s != buf)
>  		/* convert the last space to a newline */
> @@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			   const char *buf, size_t n)
>  {
>  #ifdef CONFIG_SUSPEND
> -	suspend_state_t state = PM_SUSPEND_STANDBY;
> +	suspend_state_t state = PM_SUSPEND_ON;
>  	const char * const *s;
>  #endif
>  	char *p;
> @@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  	len = p ? p - buf : n;
>  
>  	/* First, check if we are requested to hibernate */
> -	if (len == 4 && !strncmp(buf, "disk", len)) {
> +	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
>  		error = hibernate();
>    goto Exit;
>  	}
> @@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			break;
>  	}
>  	if (state < PM_SUSPEND_MAX && *s)
> -		error = enter_state(state);
> +		error = policies[policy].set_state(state);
>  #endif
>  
>   Exit:
> @@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	policy - set policy for state
> + */
> +
> +static ssize_t policy_show(struct kobject *kobj,
> +			   struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		if (i == policy)
> +			s += sprintf(s, "[%s] ", policies[i].name);
> +		else
> +			s += sprintf(s, "%s ", policies[i].name);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t policy_store(struct kobject *kobj,
> +			    struct kobj_attribute *attr,
> +			    const char *buf, size_t n)
> +{
> +	const char *s;
> +	char *p;
> +	int len;
> +	int i;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		s = policies[i].name;
> +		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
> +			mutex_lock(&pm_mutex);
> +			policies[policy].set_state(PM_SUSPEND_ON);
> +			policy = i;
> +			mutex_unlock(&pm_mutex);
> +			return n;
> +		}
> +	}
> +	return -EINVAL;
> +}
> +
> +power_attr(policy);
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  
> @@ -231,6 +309,7 @@ power_attr(pm_trace);
>  
>  static struct attribute * g[] = {
>  	&state_attr.attr,
> +	&policy_attr.attr,
>  #ifdef CONFIG_PM_TRACE
>  	&pm_trace_attr.attr,
>  #endif
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 46c5a26..9b468d7 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -236,3 +236,8 @@ static inline void suspend_thaw_processes(void)
>  {
>  }
>  #endif
> +
> +/* kernel/power/suspend_block.c */
> +extern int request_suspend_state(suspend_state_t state);
> +extern bool request_suspend_valid_state(suspend_state_t state);
> +
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 56e7dbb..dc42006 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -16,10 +16,12 @@
>  #include <linux/cpu.h>
>  #include <linux/syscalls.h>
>  #include <linux/gfp.h>
> +#include <linux/suspend_blocker.h>
>  
>  #include "power.h"
>  
>  const char *const pm_states[PM_SUSPEND_MAX] = {
> +	[PM_SUSPEND_ON]		= "on",
>  	[PM_SUSPEND_STANDBY]	= "standby",
>  	[PM_SUSPEND_MEM]	= "mem",
>  };
> @@ -157,7 +159,7 @@ static int suspend_enter(suspend_state_t state)
>  
>  	error = sysdev_suspend(PMSG_SUSPEND);
>  	if (!error) {
> -		if (!suspend_test(TEST_CORE))
> +		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
>  			error = suspend_ops->enter(state);
>  		sysdev_resume();
>  	}
> diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
> new file mode 100644
> index 0000000..9459361
> --- /dev/null
> +++ b/kernel/power/suspend_blocker.c
> @@ -0,0 +1,269 @@
> +/* kernel/power/suspend_blocker.c
> + *
> + * Copyright (C) 2005-2010 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/rtc.h>
> +#include <linux/suspend.h>
> +#include <linux/suspend_blocker.h>
> +#include "power.h"
> +
> +enum {
> +	DEBUG_EXIT_SUSPEND = 1U << 0,
> +	DEBUG_WAKEUP = 1U << 1,
> +	DEBUG_USER_STATE = 1U << 2,
> +	DEBUG_SUSPEND = 1U << 3,
> +	DEBUG_SUSPEND_BLOCKER = 1U << 4,
> +};
> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
> +
> +#define SB_INITIALIZED            (1U << 8)
> +#define SB_ACTIVE                 (1U << 9)
> +
> +static DEFINE_SPINLOCK(list_lock);
> +static DEFINE_SPINLOCK(state_lock);
> +static LIST_HEAD(inactive_blockers);
> +static LIST_HEAD(active_blockers);
> +static int current_event_num;
> +struct workqueue_struct *suspend_work_queue;
> +struct suspend_blocker main_suspend_blocker;
> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
> +static bool enable_suspend_blockers;
> +
> +#define pr_info_time(fmt, args...) \
> +	do { \
> +		struct timespec ts; \
> +		struct rtc_time tm; \
> +		getnstimeofday(&ts); \
> +		rtc_time_to_tm(ts.tv_sec, &tm); \
> +		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
> +			args, \
> +			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
> +			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
> +	} while (0);
> +
> +static void print_active_blockers_locked(void)
> +{
> +	struct suspend_blocker *blocker;
> +
> +	list_for_each_entry(blocker, &active_blockers, link)
> +		pr_info("active suspend blocker %s\n", blocker->name);
> +}
> +
> +/**
> + * suspend_is_blocked() - Check if suspend should be blocked
> + *
> + * suspend_is_blocked can be used by generic power management code to abort
> + * suspend.
> + *
> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
> + * is called during suspend initiated from the suspend_block code.
> + */
> +bool suspend_is_blocked(void)
> +{
> +	if (!enable_suspend_blockers)
> +		return 0;
> +	return !list_empty(&active_blockers);
> +}
> +
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = true;
> +	while (!suspend_is_blocked()) {
> +		entry_event_num = current_event_num;
> +
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: enter suspend\n");
> +
> +		ret = pm_suspend(requested_suspend_state);
> +
> +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> +
> +		if (current_event_num == entry_event_num)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +	}
> +	enable_suspend_blockers = false;
> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in debug messages.
> + *
> + * The suspend blocker struct and name must not be freed before calling
> + * suspend_blocker_destroy.
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	unsigned long irqflags = 0;
> +
> +	WARN_ON(!name);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", name);
> +
> +	blocker->name = name;
> +	blocker->flags = SB_INITIALIZED;
> +	INIT_LIST_HEAD(&blocker->link);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	list_add(&blocker->link, &inactive_blockers);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);
> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags &= ~SB_INITIALIZED;
> +	list_del(&blocker->link);
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(suspend_work_queue, &suspend_work);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags |= SB_ACTIVE;
> +	list_del(&blocker->link);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +
> +	list_add(&blocker->link, &active_blockers);
> +
> +	current_event_num++;
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	list_del(&blocker->link);
> +	list_add(&blocker->link, &inactive_blockers);
> +
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(suspend_work_queue, &suspend_work);
> +	blocker->flags &= ~(SB_ACTIVE);
> +	if (blocker == &main_suspend_blocker) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			print_active_blockers_locked();
> +	}
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + *
> + * Returns true if the suspend_blocker is currently active.
> + */
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker)
> +{
> +	WARN_ON(!(blocker->flags & SB_INITIALIZED));
> +
> +	return !!(blocker->flags & SB_ACTIVE);
> +}
> +EXPORT_SYMBOL(suspend_blocker_is_active);
> +
> +bool request_suspend_valid_state(suspend_state_t state)
> +{
> +	return (state == PM_SUSPEND_ON) || valid_state(state);
> +}
> +
> +int request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +
> +	if (!request_suspend_valid_state(state))
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&state_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_USER_STATE)
> +		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
> +			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			     requested_suspend_state, state,
> +			     ktime_to_ns(ktime_get()));
> +
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +	return 0;
> +}
> +
> +static int __init suspend_block_init(void)
> +{
> +	suspend_work_queue = create_singlethread_workqueue("suspend");
> +	if (!suspend_work_queue)
> +		return -ENOMEM;
> +
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +	return 0;
> +}
> +
> +core_initcall(suspend_block_init);

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Tue, 27 Apr 2010, [UTF-8] Arve Hjønnevåg wrote:

> +For example, in cell phones or other embedded systems, where powering the screen
> +is a significant drain on the battery, suspend blockers can be used to allow
> +user-space to decide whether a keystroke received while the system is suspended
> +should cause the screen to be turned back on or allow the system to go back into
> +suspend. 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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. If it determines that
> +  the key should leave the screen off, it calls suspend_unblock on the
> +  process_input_events suspend_blocker and then calls select or poll. The
> +  system will automatically suspend again, since now no suspend blockers are
> +  active.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++

This is better than before, but it still isn't ideal.  Here's what I 
mean:

>  suspend blockers can be used to allow
> +user-space to decide whether a keystroke received while the system is suspended
> +should cause the screen to be turned back on or allow the system to go back into
> +suspend.

That's not right.  Handling the screen doesn't need suspend blockers:
The program decides what to do and then either turns on the screen or
else writes "mem" to /sys/power/state.  What suspend blockers add is
the ability to resolve races and satisfy multiple constraints when
going into suspend -- which has nothing to do with operating the
screen.

I _think_ what you're trying to get at can be expressed this way:

	Here's an example showing how a cell phone or other embedded
	system can handle keystrokes (or other input events) in the 
	presence of suspend blockers.  Use set_irq_wake...

	...

      - The user-space input-event thread returns from read.  It 
	carries out whatever activities are appropriate (for example,
	powering up the display screen, running other programs, and so 
	on).  When it is finished, it calls suspend_unblock on the
	process_input_events suspend_blocker and then calls select or
	poll.  The system will automatically suspend again when it is
	idle and no suspend blockers remain active.


> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags |= SB_ACTIVE;
> +	list_del(&blocker->link);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +
> +	list_add(&blocker->link, &active_blockers);

Here and in suspend_unblock(), you can use list_move() in place of 
list_del() followed by list_add().

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Wednesday 28 April 2010, Arve Hjønnevåg wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
...
> @@ -20,6 +21,27 @@ DEFINE_MUTEX(pm_mutex);
>  unsigned int pm_flags;
>  EXPORT_SYMBOL(pm_flags);
>  
> +struct policy {
> +	const char *name;
> +	bool (*valid_state)(suspend_state_t state);
> +	int (*set_state)(suspend_state_t state);
> +};
> +static struct policy policies[] = {
> +	{
> +		.name		= "forced",
> +		.valid_state	= valid_state,
> +		.set_state	= enter_state,
> +	},
> +#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
> +	{
> +		.name		= "opportunistic",
> +		.valid_state	= request_suspend_valid_state,
> +		.set_state	= request_suspend_state,
> +	},
> +#endif
> +};
> +static int policy;
> +
>  #ifdef CONFIG_PM_SLEEP
>  
>  /* Routines for PM-transition notifications */
> @@ -146,6 +168,12 @@ struct kobject *power_kobj;
>   *
>   *	store() accepts one of those strings, translates it into the 
>   *	proper enumerated value, and initiates a suspend transition.
> + *
> + *	If policy is set to opportunistic, store() does not block until the
> + *	system resumes, and it will try to re-enter the state until another
> + *	state is requested. Suspend blockers are respected and the requested
> + *	state will only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
>   */
>  static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			  char *buf)
> @@ -155,12 +183,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  	int i;
>  
>  	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> -		if (pm_states[i] && valid_state(i))
> +		if (pm_states[i] && policies[policy].valid_state(i))
>  			s += sprintf(s,"%s ", pm_states[i]);
>  	}
>  #endif
>  #ifdef CONFIG_HIBERNATION
> -	s += sprintf(s, "%s\n", "disk");
> +	if (!policy)
> +		s += sprintf(s, "%s\n", "disk");
>  #else
>  	if (s != buf)
>  		/* convert the last space to a newline */
> @@ -173,7 +202,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			   const char *buf, size_t n)
>  {
>  #ifdef CONFIG_SUSPEND
> -	suspend_state_t state = PM_SUSPEND_STANDBY;
> +	suspend_state_t state = PM_SUSPEND_ON;
>  	const char * const *s;
>  #endif
>  	char *p;
> @@ -184,7 +213,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  	len = p ? p - buf : n;
>  
>  	/* First, check if we are requested to hibernate */
> -	if (len == 4 && !strncmp(buf, "disk", len)) {
> +	if (len == 4 && !strncmp(buf, "disk", len) && !policy) {
>  		error = hibernate();
>    goto Exit;
>  	}
> @@ -195,7 +224,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  			break;
>  	}
>  	if (state < PM_SUSPEND_MAX && *s)
> -		error = enter_state(state);
> +		error = policies[policy].set_state(state);
>  #endif
>  
>   Exit:
> @@ -204,6 +233,55 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	policy - set policy for state
> + */
> +
> +static ssize_t policy_show(struct kobject *kobj,
> +			   struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		if (i == policy)
> +			s += sprintf(s, "[%s] ", policies[i].name);
> +		else
> +			s += sprintf(s, "%s ", policies[i].name);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t policy_store(struct kobject *kobj,
> +			    struct kobj_attribute *attr,
> +			    const char *buf, size_t n)
> +{
> +	const char *s;
> +	char *p;
> +	int len;
> +	int i;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (i = 0; i < ARRAY_SIZE(policies); i++) {
> +		s = policies[i].name;
> +		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
> +			mutex_lock(&pm_mutex);
> +			policies[policy].set_state(PM_SUSPEND_ON);
> +			policy = i;
> +			mutex_unlock(&pm_mutex);
> +			return n;
> +		}
> +	}
> +	return -EINVAL;
> +}
> +
> +power_attr(policy);
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  

Would you mind if I changed the above so that "policy" doesn't even show up
if CONFIG_OPPORTUNISTIC_SUSPEND is unset?

...
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = true;
> +	while (!suspend_is_blocked()) {
> +		entry_event_num = current_event_num;
> +
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: enter suspend\n");
> +
> +		ret = pm_suspend(requested_suspend_state);
> +
> +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> +
> +		if (current_event_num == entry_event_num)
> +			pr_info("suspend: pm_suspend returned with no event\n");

Hmm, what exactly is this for?  It looks like a debug thing to me.  I'd use
pr_debug() here and in both debug printk()s above.  Would you agree?

> +	}
> +	enable_suspend_blockers = false;
> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in debug messages.
> + *
> + * The suspend blocker struct and name must not be freed before calling
> + * suspend_blocker_destroy.
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	unsigned long irqflags = 0;
> +
> +	WARN_ON(!name);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", name);
> +
> +	blocker->name = name;
> +	blocker->flags = SB_INITIALIZED;
> +	INIT_LIST_HEAD(&blocker->link);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	list_add(&blocker->link, &inactive_blockers);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);

Is there a strong objection to changing that (and the other instances below) to
EXPORT_SYMBOL_GPL?

> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags &= ~SB_INITIALIZED;
> +	list_del(&blocker->link);
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(suspend_work_queue, &suspend_work);
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +	blocker->flags |= SB_ACTIVE;
> +	list_del(&blocker->link);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +
> +	list_add(&blocker->link, &active_blockers);
> +
> +	current_event_num++;
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + *
> + * It is safe to call this function from interrupt context.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	unsigned long irqflags;
> +
> +	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
> +		return;
> +
> +	spin_lock_irqsave(&list_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	list_del(&blocker->link);
> +	list_add(&blocker->link, &inactive_blockers);
> +
> +	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
> +		queue_work(suspend_work_queue, &suspend_work);
> +	blocker->flags &= ~(SB_ACTIVE);
> +	if (blocker == &main_suspend_blocker) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			print_active_blockers_locked();
> +	}
> +	spin_unlock_irqrestore(&list_lock, irqflags);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * suspend_blocker_is_active() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + *
> + * Returns true if the suspend_blocker is currently active.
> + */
> +bool suspend_blocker_is_active(struct suspend_blocker *blocker)
> +{
> +	WARN_ON(!(blocker->flags & SB_INITIALIZED));
> +
> +	return !!(blocker->flags & SB_ACTIVE);
> +}
> +EXPORT_SYMBOL(suspend_blocker_is_active);
> +
> +bool request_suspend_valid_state(suspend_state_t state)
> +{
> +	return (state == PM_SUSPEND_ON) || valid_state(state);
> +}
> +
> +int request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +
> +	if (!request_suspend_valid_state(state))
> +		return -ENODEV;
> +
> +	spin_lock_irqsave(&state_lock, irqflags);
> +
> +	if (debug_mask & DEBUG_USER_STATE)
> +		pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
> +			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			     requested_suspend_state, state,
> +			     ktime_to_ns(ktime_get()));
> +
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +	return 0;
> +}

I think the two functions above should be static, shouldn't they?

> +static int __init suspend_block_init(void)
> +{
> +	suspend_work_queue = create_singlethread_workqueue("suspend");
> +	if (!suspend_work_queue)
> +		return -ENOMEM;
> +
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +	return 0;
> +}
> +
> +core_initcall(suspend_block_init);

Hmm.  Why don't you want to put that initialization into pm_init() (in
kernel/power/main.c)?

Also, we already have one PM workqueue.  It is used for runtime PM, but I guess
it may be used just as well for the opportunistic suspend.  It is freezable,
but would it hurt?

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2010/4/28 Rafael J. Wysocki <rjw@sisk.pl>:
...
>>
>> +/**
>> + *   policy - set policy for state
>> + */
>> +
>> +static ssize_t policy_show(struct kobject *kobj,
>> +                        struct kobj_attribute *attr, char *buf)
>> +{
>> +     char *s = buf;
>> +     int i;
>> +
>> +     for (i = 0; i < ARRAY_SIZE(policies); i++) {
>> +             if (i == policy)
>> +                     s += sprintf(s, "[%s] ", policies[i].name);
>> +             else
>> +                     s += sprintf(s, "%s ", policies[i].name);
>> +     }
>> +     if (s != buf)
>> +             /* convert the last space to a newline */
>> +             *(s-1) = '\n';
>> +     return (s - buf);
>> +}
>> +
>> +static ssize_t policy_store(struct kobject *kobj,
>> +                         struct kobj_attribute *attr,
>> +                         const char *buf, size_t n)
>> +{
>> +     const char *s;
>> +     char *p;
>> +     int len;
>> +     int i;
>> +
>> +     p = memchr(buf, '\n', n);
>> +     len = p ? p - buf : n;
>> +
>> +     for (i = 0; i < ARRAY_SIZE(policies); i++) {
>> +             s = policies[i].name;
>> +             if (s && len == strlen(s) && !strncmp(buf, s, len)) {
>> +                     mutex_lock(&pm_mutex);
>> +                     policies[policy].set_state(PM_SUSPEND_ON);
>> +                     policy = i;
>> +                     mutex_unlock(&pm_mutex);
>> +                     return n;
>> +             }
>> +     }
>> +     return -EINVAL;
>> +}
>> +
>> +power_attr(policy);
>> +
>>  #ifdef CONFIG_PM_TRACE
>>  int pm_trace_enabled;
>>
>
> Would you mind if I changed the above so that "policy" doesn't even show up
> if CONFIG_OPPORTUNISTIC_SUSPEND is unset?
>
I don't mind, but It did not seem worth the trouble to hide it. It
will only list the supported policies, and it is easy to add or remove
policies this way.

> ...
>> +static void suspend_worker(struct work_struct *work)
>> +{
>> +     int ret;
>> +     int entry_event_num;
>> +
>> +     enable_suspend_blockers = true;
>> +     while (!suspend_is_blocked()) {
>> +             entry_event_num = current_event_num;
>> +
>> +             if (debug_mask & DEBUG_SUSPEND)
>> +                     pr_info("suspend: enter suspend\n");
>> +
>> +             ret = pm_suspend(requested_suspend_state);
>> +
>> +             if (debug_mask & DEBUG_EXIT_SUSPEND)
>> +                     pr_info_time("suspend: exit suspend, ret = %d ", ret);
>> +
>> +             if (current_event_num == entry_event_num)
>> +                     pr_info("suspend: pm_suspend returned with no event\n");
>
> Hmm, what exactly is this for?  It looks like a debug thing to me.  I'd use
> pr_debug() here and in both debug printk()s above.  Would you agree?
>

If the driver that caused the wakeup does not use suspend blockers, we
the only choice is to try to suspend again. I want to know if this
happened. The stats patch disable this printk by default since it will
show up in the stats, and the timeout patch (not included here) delays
the retry.

...
>> +EXPORT_SYMBOL(suspend_blocker_init);
>
> Is there a strong objection to changing that (and the other instances below) to
> EXPORT_SYMBOL_GPL?
>

I don't know if it is a strong objection, but I prefer that this api
is available to all drivers. I don't want to prevent a user from using
opportunistic suspend because a non-gpl driver could not use suspend
blockers. I changed the suspend blocking work functions to be gpl only
though, since they are not required, and the workqueue api is
available to gpl code anyway.

...
>> +bool request_suspend_valid_state(suspend_state_t state)
>> +{
>> +     return (state == PM_SUSPEND_ON) || valid_state(state);
>> +}
>> +
>> +int request_suspend_state(suspend_state_t state)
>> +{
>> +     unsigned long irqflags;
>> +
>> +     if (!request_suspend_valid_state(state))
>> +             return -ENODEV;
>> +
>> +     spin_lock_irqsave(&state_lock, irqflags);
>> +
>> +     if (debug_mask & DEBUG_USER_STATE)
>> +             pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
>> +                          state != PM_SUSPEND_ON ? "sleep" : "wakeup",
>> +                          requested_suspend_state, state,
>> +                          ktime_to_ns(ktime_get()));
>> +
>> +     requested_suspend_state = state;
>> +     if (state == PM_SUSPEND_ON)
>> +             suspend_block(&main_suspend_blocker);
>> +     else
>> +             suspend_unblock(&main_suspend_blocker);
>> +     spin_unlock_irqrestore(&state_lock, irqflags);
>> +     return 0;
>> +}
>
> I think the two functions above should be static, shouldn't they?

No, they are used from main.c.

>
>> +static int __init suspend_block_init(void)
>> +{
>> +     suspend_work_queue = create_singlethread_workqueue("suspend");
>> +     if (!suspend_work_queue)
>> +             return -ENOMEM;
>> +
>> +     suspend_blocker_init(&main_suspend_blocker, "main");
>> +     suspend_block(&main_suspend_blocker);
>> +     return 0;
>> +}
>> +
>> +core_initcall(suspend_block_init);
>
> Hmm.  Why don't you want to put that initialization into pm_init() (in
> kernel/power/main.c)?

It was not needed before, but I changed pm_init to call
suspend_block_init after creating pm_wq.

>
> Also, we already have one PM workqueue.  It is used for runtime PM, but I guess
> it may be used just as well for the opportunistic suspend.  It is freezable,
> but would it hurt?

No, it works, the freezable flag is just ignored when I call
pm_suspend and I don't run anything else on the workqueue while
threads are frozen. It does need to be a single threaded workqueue
though, so make sure you don't just change that.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Thursday 29 April 2010, Arve Hjønnevåg wrote:
> 2010/4/28 Rafael J. Wysocki <rjw@sisk.pl>:
> ...
> >>
> >> +/**
> >> + *   policy - set policy for state
> >> + */
> >> +
> >> +static ssize_t policy_show(struct kobject *kobj,
> >> +                        struct kobj_attribute *attr, char *buf)
> >> +{
> >> +     char *s = buf;
> >> +     int i;
> >> +
> >> +     for (i = 0; i < ARRAY_SIZE(policies); i++) {
> >> +             if (i == policy)
> >> +                     s += sprintf(s, "[%s] ", policies[i].name);
> >> +             else
> >> +                     s += sprintf(s, "%s ", policies[i].name);
> >> +     }
> >> +     if (s != buf)
> >> +             /* convert the last space to a newline */
> >> +             *(s-1) = '\n';
> >> +     return (s - buf);
> >> +}
> >> +
> >> +static ssize_t policy_store(struct kobject *kobj,
> >> +                         struct kobj_attribute *attr,
> >> +                         const char *buf, size_t n)
> >> +{
> >> +     const char *s;
> >> +     char *p;
> >> +     int len;
> >> +     int i;
> >> +
> >> +     p = memchr(buf, '\n', n);
> >> +     len = p ? p - buf : n;
> >> +
> >> +     for (i = 0; i < ARRAY_SIZE(policies); i++) {
> >> +             s = policies[i].name;
> >> +             if (s && len == strlen(s) && !strncmp(buf, s, len)) {
> >> +                     mutex_lock(&pm_mutex);
> >> +                     policies[policy].set_state(PM_SUSPEND_ON);
> >> +                     policy = i;
> >> +                     mutex_unlock(&pm_mutex);
> >> +                     return n;
> >> +             }
> >> +     }
> >> +     return -EINVAL;
> >> +}
> >> +
> >> +power_attr(policy);
> >> +
> >>  #ifdef CONFIG_PM_TRACE
> >>  int pm_trace_enabled;
> >>
> >
> > Would you mind if I changed the above so that "policy" doesn't even show up
> > if CONFIG_OPPORTUNISTIC_SUSPEND is unset?
> >
> I don't mind, but It did not seem worth the trouble to hide it. It
> will only list the supported policies, and it is easy to add or remove
> policies this way.
> 
> > ...
> >> +static void suspend_worker(struct work_struct *work)
> >> +{
> >> +     int ret;
> >> +     int entry_event_num;
> >> +
> >> +     enable_suspend_blockers = true;
> >> +     while (!suspend_is_blocked()) {
> >> +             entry_event_num = current_event_num;
> >> +
> >> +             if (debug_mask & DEBUG_SUSPEND)
> >> +                     pr_info("suspend: enter suspend\n");
> >> +
> >> +             ret = pm_suspend(requested_suspend_state);
> >> +
> >> +             if (debug_mask & DEBUG_EXIT_SUSPEND)
> >> +                     pr_info_time("suspend: exit suspend, ret = %d ", ret);
> >> +
> >> +             if (current_event_num == entry_event_num)
> >> +                     pr_info("suspend: pm_suspend returned with no event\n");
> >
> > Hmm, what exactly is this for?  It looks like a debug thing to me.  I'd use
> > pr_debug() here and in both debug printk()s above.  Would you agree?
> >
> 
> If the driver that caused the wakeup does not use suspend blockers, we
> the only choice is to try to suspend again. I want to know if this
> happened. The stats patch disable this printk by default since it will
> show up in the stats, and the timeout patch (not included here) delays
> the retry.
> 
> ...
> >> +EXPORT_SYMBOL(suspend_blocker_init);
> >
> > Is there a strong objection to changing that (and the other instances below) to
> > EXPORT_SYMBOL_GPL?
> >
> 
> I don't know if it is a strong objection, but I prefer that this api
> is available to all drivers. I don't want to prevent a user from using
> opportunistic suspend because a non-gpl driver could not use suspend
> blockers. I changed the suspend blocking work functions to be gpl only
> though, since they are not required, and the workqueue api is
> available to gpl code anyway.
> 
> ...
> >> +bool request_suspend_valid_state(suspend_state_t state)
> >> +{
> >> +     return (state == PM_SUSPEND_ON) || valid_state(state);
> >> +}
> >> +
> >> +int request_suspend_state(suspend_state_t state)
> >> +{
> >> +     unsigned long irqflags;
> >> +
> >> +     if (!request_suspend_valid_state(state))
> >> +             return -ENODEV;
> >> +
> >> +     spin_lock_irqsave(&state_lock, irqflags);
> >> +
> >> +     if (debug_mask & DEBUG_USER_STATE)
> >> +             pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
> >> +                          state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> >> +                          requested_suspend_state, state,
> >> +                          ktime_to_ns(ktime_get()));
> >> +
> >> +     requested_suspend_state = state;
> >> +     if (state == PM_SUSPEND_ON)
> >> +             suspend_block(&main_suspend_blocker);
> >> +     else
> >> +             suspend_unblock(&main_suspend_blocker);
> >> +     spin_unlock_irqrestore(&state_lock, irqflags);
> >> +     return 0;
> >> +}
> >
> > I think the two functions above should be static, shouldn't they?
> 
> No, they are used from main.c.
> 
> >
> >> +static int __init suspend_block_init(void)
> >> +{
> >> +     suspend_work_queue = create_singlethread_workqueue("suspend");
> >> +     if (!suspend_work_queue)
> >> +             return -ENOMEM;
> >> +
> >> +     suspend_blocker_init(&main_suspend_blocker, "main");
> >> +     suspend_block(&main_suspend_blocker);
> >> +     return 0;
> >> +}
> >> +
> >> +core_initcall(suspend_block_init);
> >
> > Hmm.  Why don't you want to put that initialization into pm_init() (in
> > kernel/power/main.c)?
> 
> It was not needed before, but I changed pm_init to call
> suspend_block_init after creating pm_wq.
> 
> >
> > Also, we already have one PM workqueue.  It is used for runtime PM, but I guess
> > it may be used just as well for the opportunistic suspend.  It is freezable,
> > but would it hurt?
> 
> No, it works, the freezable flag is just ignored when I call
> pm_suspend and I don't run anything else on the workqueue while
> threads are frozen. It does need to be a single threaded workqueue
> though, so make sure you don't just change that.

Freezable workqueues have to be singlethread or else there will be unfixable
races, so you can safely assume things will stay as they are in this respect.

Rafael


> 
> 

Re: [PATCH 1/8] PM: Add suspend block api.

[Tejun Heo]

Hello,

On 04/29/2010 11:16 PM, Rafael J. Wysocki wrote:
>>> Also, we already have one PM workqueue.  It is used for runtime PM, but I guess
>>> it may be used just as well for the opportunistic suspend.  It is freezable,
>>> but would it hurt?
>>
>> No, it works, the freezable flag is just ignored when I call
>> pm_suspend and I don't run anything else on the workqueue while
>> threads are frozen. It does need to be a single threaded workqueue
>> though, so make sure you don't just change that.
> 
> Freezable workqueues have to be singlethread or else there will be unfixable
> races, so you can safely assume things will stay as they are in this respect.

Rafael, can you elaborate a bit more on this?  Just in case I missed
something while doing cmwq as it currently doesn't have such limit.

Thanks.

-- 
tejun

Re: [PATCH 1/8] PM: Add suspend block api.

[Oleg Nesterov]

On 04/30, Tejun Heo wrote:
>
> On 04/29/2010 11:16 PM, Rafael J. Wysocki wrote:
> >>> Also, we already have one PM workqueue.  It is used for runtime PM, but I guess
> >>> it may be used just as well for the opportunistic suspend.  It is freezable,
> >>> but would it hurt?
> >>
> > Freezable workqueues have to be singlethread or else there will be unfixable
> > races, so you can safely assume things will stay as they are in this respect.
>
> Rafael, can you elaborate a bit more on this?  Just in case I missed
> something while doing cmwq as it currently doesn't have such limit.

Currently _cpu_down() can't flush and/or stop the frozen cwq->thread.

IIRC this is fixable, but needs the nasty complications. We should
thaw + stop the frozen cwq->thread, then move the pending works to
another CPU.

Oleg.

Re: [PATCH 1/8] PM: Add suspend block api.

[Tejun Heo]

Hello,

(sorry about late reply)

On 04/30/2010 07:26 PM, Oleg Nesterov wrote:
> Currently _cpu_down() can't flush and/or stop the frozen cwq->thread.
> 
> IIRC this is fixable, but needs the nasty complications. We should
> thaw + stop the frozen cwq->thread, then move the pending works to
> another CPU.

Oh, this isn't an issue w/ cmwq.  While frozen all new works are
collected into per-cpu delayed worklist and while frozen trustee in
charge of the cpu will keep waiting.  Once thawed, trustee will
execute all works including the delayed ones unbound to any cpu.

Thanks.

-- 
tejun

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Thursday 20 May 2010, Tejun Heo wrote:
> Hello,
> 
> (sorry about late reply)
> 
> On 04/30/2010 07:26 PM, Oleg Nesterov wrote:
> > Currently _cpu_down() can't flush and/or stop the frozen cwq->thread.
> > 
> > IIRC this is fixable, but needs the nasty complications. We should
> > thaw + stop the frozen cwq->thread, then move the pending works to
> > another CPU.
> 
> Oh, this isn't an issue w/ cmwq.  While frozen all new works are
> collected into per-cpu delayed worklist and while frozen trustee in
> charge of the cpu will keep waiting.  Once thawed, trustee will
> execute all works including the delayed ones unbound to any cpu.

So, does it require any intrusive changes to make it possible to create
multithread freezable workqueues?

Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Tejun Heo]

Hello,

On 05/21/2010 12:27 AM, Rafael J. Wysocki wrote:
>> Oh, this isn't an issue w/ cmwq.  While frozen all new works are
>> collected into per-cpu delayed worklist and while frozen trustee in
>> charge of the cpu will keep waiting.  Once thawed, trustee will
>> execute all works including the delayed ones unbound to any cpu.
> 
> So, does it require any intrusive changes to make it possible to create
> multithread freezable workqueues?

cmwq itself is quite intrusive changes but w/ cmwq it just takes
flipping a flag when creating the queue.

Thanks.

-- 
tejun

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Tue, 27 Apr 2010, [UTF-8] Arve Hjønnevåg wrote:

> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = true;
> +	while (!suspend_is_blocked()) {
> +		entry_event_num = current_event_num;
> +
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: enter suspend\n");
> +
> +		ret = pm_suspend(requested_suspend_state);
> +
> +		if (debug_mask & DEBUG_EXIT_SUSPEND)
> +			pr_info_time("suspend: exit suspend, ret = %d ", ret);
> +
> +		if (current_event_num == entry_event_num)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +	}
> +	enable_suspend_blockers = false;
> +}

Here's a completely new issue.  When using opportunistic suspends on an
SMP system, it could happen that the system gets a wakeup event and
this routine starts running again before the event's IRQ handler has
finished (or has enabled a suspend blocker).  The system would 
re-suspend too soon.

Is there anything in the PM core that waits until all outstanding IRQs 
have been handled before unfreezing processes?  If there is, I can't 
find it.  Should such a thing be added?

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api

[Sam Shang]

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


Arve,
 
I can see the usage of suspend blockers from the example you described below. I understand how applications can make use of suspend blockers to save power. Still, my first rule of their usage is don't use them unless necessary, as their misuse might cause increase of power usage.
 
I'm wondering whether you have a recommended rule of suspend blocker usage for both applications and drivers. From application and driver development point of view, I don't want to add suspend blockers everywhere.
 
Sam Shang
 
*******************
Date: Wed, 15 Apr 2009 17:34:43 -0700
From: Arve Hj?nnev?g <arve@android.com>
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.
To: Alan Stern <stern@rowland.harvard.edu>
Cc: ncunningham@crca.org.au, u.luckas@road.de, swetland@google.com,
        Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Message-ID:
        <d6200be20904151734o738c7a5dx52a800b97ebc2708@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
 
2009/4/15 Alan Stern <stern@rowland.harvard.edu>:
> On Tue, 14 Apr 2009, [utf-8] Arve Hj?nnev?g wrote:
> 
>> +Suspend blockers can be used to allow user-space to decide which keys should
> 
> Then in the last section, say this:
> 
> ? ? ?- The user-space input-event thread returns from read. If it
> ? ? ? ?determines that the key should leave the screen off, it
> ? ? ? ?calls suspend_unblock on the process_input_events
> ? ? ? ?suspend_blocker and then calls select or poll. ?The system
> ? ? ? ?will automatically suspend again, since now no suspend blockers
> ? ? ? ?are active.
> 
 
This sounds reasonable too me.
 
-- 
Arve Hj?nnev?g
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/

[-- Attachment #1.2: Type: text/html, Size: 7670 bytes --]

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

[RFC][PATCH 0/8] Suspend block api

[Arve Hjønnevåg]

This patch series adds a suspend-block api that provides the same
functionality as the android wakelock api from my last patch series,
Android PM extensions (version 3). As requested, wake_lock has been
renamed to suspend_block(er), and timeout support has been separated
into its own patch.

--
Arve Hjønnevåg

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

[PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

Adds /sys/power/request_state, a non-blocking interface that specifies
which suspend state to enter when no suspend blockers are active. A
special state, "on", stops the process by activating the "main" suspend
blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/suspend-blockers.txt |   76 +++++++++
 include/linux/suspend_block.h            |   61 +++++++
 kernel/power/Kconfig                     |   10 ++
 kernel/power/Makefile                    |    1 +
 kernel/power/main.c                      |   62 +++++++
 kernel/power/power.h                     |    6 +
 kernel/power/suspend_block.c             |  257 ++++++++++++++++++++++++++++++
 7 files changed, 473 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/power/suspend-blockers.txt
 create mode 100755 include/linux/suspend_block.h
 create mode 100644 kernel/power/suspend_block.c

diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
new file mode 100644
index 0000000..743b870
--- /dev/null
+++ b/Documentation/power/suspend-blockers.txt
@@ -0,0 +1,76 @@
+Suspend blockers
+================
+
+A suspend_blocker prevents the system from entering suspend.
+
+If the suspend operation has already started when calling suspend_block on a
+suspend_blocker, it will abort the suspend operation as long it has not already
+reached the sysdev suspend stage. This means that calling suspend_block from an
+interrupt handler or a freezeable thread always works, but if you call
+block_suspend from a sysdev suspend handler you must also return an error from
+that handler to abort suspend.
+
+Suspend blockers 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 calls suspend_block on the
+  keypad-scan suspend_blocker 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 calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. It determines that the
+  key should not wake up the full system, calls suspend_unblock on the
+  process-input-events suspend_blocker and calls select or poll.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block api by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init. For instance:
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
+}
+
+Before freeing the memory, suspend_blocker_destroy must be called:
+
+uninit() {
+	suspend_blocker_destroy(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block:
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock:
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block when the suspend blocker is active or suspend_unblock when
+it is not active has no effect. This allows drivers to update their state and
+call suspend suspend_block or suspend_unblock based on the result.
+For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
+
diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
new file mode 100755
index 0000000..7820c60
--- /dev/null
+++ b/include/linux/suspend_block.h
@@ -0,0 +1,61 @@
+/* include/linux/suspend_block.h
+ *
+ * Copyright (C) 2007-2009 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_SUSPEND_BLOCK_H
+#define _LINUX_SUSPEND_BLOCK_H
+
+/* A suspend_blocker prevents the system from entering suspend when active.
+ */
+
+struct suspend_blocker {
+#ifdef CONFIG_SUSPEND_BLOCK
+	atomic_t            flags;
+	const char         *name;
+#endif
+};
+
+#ifdef CONFIG_SUSPEND_BLOCK
+
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
+void suspend_blocker_destroy(struct suspend_blocker *blocker);
+void suspend_block(struct suspend_blocker *blocker);
+void suspend_unblock(struct suspend_blocker *blocker);
+
+/* is_blocking_suspend returns true if the suspend_blocker is currently active.
+ */
+bool is_blocking_suspend(struct suspend_blocker *blocker);
+
+/* suspend_is_blocked can be used by generic power management code to abort
+ * suspend.
+ *
+ * To preserve backward compatibility suspend_is_blocked returns 0 unless it
+ * is called during suspend initiated from the suspend_block code.
+ */
+bool suspend_is_blocked(void);
+
+#else
+
+static inline void suspend_blocker_init(struct suspend_blocker *blocker,
+					const char *name) {}
+static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
+static inline void suspend_block(struct suspend_blocker *blocker) {}
+static inline void suspend_unblock(struct suspend_blocker *blocker) {}
+static inline bool is_blocking_suspend(struct suspend_blocker *bl) { return 0; }
+static inline bool suspend_is_blocked(void) { return 0; }
+
+#endif
+
+#endif
+
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 23bd4da..9d1df13 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -116,6 +116,16 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config SUSPEND_BLOCK
+	bool "Suspend block"
+	depends on PM
+	select RTC_LIB
+	default n
+	---help---
+	  Enable suspend_block. When user space requests a sleep state through
+	  /sys/power/request_state, the requested sleep state will be entered
+	  when no suspend_blockers are active.
+
 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 720ea4f..29cdc9e 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -6,6 +6,7 @@ endif
 obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
+obj-$(CONFIG_SUSPEND_BLOCK)	+= suspend_block.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/main.c b/kernel/power/main.c
index c9632f8..e4c6b20 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -22,6 +22,7 @@
 #include <linux/freezer.h>
 #include <linux/vmstat.h>
 #include <linux/syscalls.h>
+#include <linux/suspend_block.h>
 
 #include "power.h"
 
@@ -392,6 +393,9 @@ static void suspend_finish(void)
 
 
 static const char * const pm_states[PM_SUSPEND_MAX] = {
+#ifdef CONFIG_SUSPEND_BLOCK
+	[PM_SUSPEND_ON]		= "on",
+#endif
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -540,6 +544,61 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+/**
+ *	request_state - control system power state.
+ *
+ *	This is similar to state, but it does not block until the system
+ *	resumes, and it will try to re-enter the state until another state is
+ *	requested. Suspend blockers are respected and the requested state will
+ *	only be entered when no suspend blockers are active.
+ *	Write "on" to cancel.
+ */
+
+#ifdef CONFIG_SUSPEND_BLOCK
+static ssize_t request_state_show(struct kobject *kobj,
+				  struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < PM_SUSPEND_MAX; i++) {
+		if (pm_states[i] && (i == PM_SUSPEND_ON || valid_state(i)))
+			s += sprintf(s, "%s ", pm_states[i]);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t request_state_store(struct kobject *kobj,
+				   struct kobj_attribute *attr,
+				   const char *buf, size_t n)
+{
+	suspend_state_t state = PM_SUSPEND_ON;
+	const char * const *s;
+	char *p;
+	int len;
+	int error = -EINVAL;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
+		if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
+			break;
+	}
+	if (state < PM_SUSPEND_MAX && *s)
+		if (state == PM_SUSPEND_ON || valid_state(state)) {
+			error = 0;
+			request_suspend_state(state);
+		}
+	return error ? error : n;
+}
+
+power_attr(request_state);
+#endif /* CONFIG_SUSPEND_BLOCK */
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -567,6 +626,9 @@ power_attr(pm_trace);
 
 static struct attribute * g[] = {
 	&state_attr.attr,
+#ifdef CONFIG_SUSPEND_BLOCK
+	&request_state_attr.attr,
+#endif
 #ifdef CONFIG_PM_TRACE
 	&pm_trace_attr.attr,
 #endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46b5ec7..2414a74 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+#ifdef CONFIG_SUSPEND_BLOCK
+/* kernel/power/suspend_block.c */
+void request_suspend_state(suspend_state_t state);
+#endif
+
diff --git a/kernel/power/suspend_block.c b/kernel/power/suspend_block.c
new file mode 100644
index 0000000..b4f2191
--- /dev/null
+++ b/kernel/power/suspend_block.c
@@ -0,0 +1,257 @@
+/* kernel/power/suspend_block.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/rtc.h>
+#include <linux/suspend.h>
+#include <linux/suspend_block.h>
+#include <linux/sysdev.h>
+#include "power.h"
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+static DEFINE_SPINLOCK(state_lock);
+static atomic_t suspend_block_count;
+static atomic_t current_event_num;
+struct workqueue_struct *suspend_work_queue;
+struct suspend_blocker main_suspend_blocker;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+
+bool suspend_is_blocked(void)
+{
+	if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
+		return 0;
+	return !!atomic_read(&suspend_block_count);
+}
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = 1;
+
+retry:
+	if (suspend_is_blocked()) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: abort suspend\n");
+		goto abort;
+	}
+
+	entry_event_num = atomic_read(&current_event_num);
+	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 (atomic_read(&current_event_num) == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: pm_suspend returned with no event\n");
+		goto retry;
+	}
+abort:
+	enable_suspend_blockers = 0;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
+{
+	int ret = suspend_is_blocked() ? -EAGAIN : 0;
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("suspend_block_suspend return %d\n", ret);
+	return ret;
+}
+
+static struct sysdev_class suspend_block_sysclass = {
+	.name = "suspend_block",
+	.suspend = suspend_block_suspend,
+};
+static struct sys_device suspend_block_sysdev = {
+	.cls = &suspend_block_sysclass,
+};
+
+/**
+ * suspend_blocker_init() - Initialize a suspend blocker
+ * @blocker:	The suspend blocker to initialize.
+ * @name:	The name of the suspend blocker to show in
+ *		/proc/suspend_blockers
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	if (name)
+		blocker->name = name;
+	BUG_ON(!blocker->name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_init name=%s\n", blocker->name);
+
+	atomic_set(&blocker->flags, SB_INITIALIZED);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_destroy() - Destroy a suspend blocker
+ * @blocker:	The suspend blocker to destroy.
+ */
+void suspend_blocker_destroy(struct suspend_blocker *blocker)
+{
+	int flags;
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
+	flags = atomic_xchg(&blocker->flags, 0);
+	WARN(!(flags & SB_INITIALIZED), "suspend_blocker_destroy called on "
+					"uninitialized suspend_blocker\n");
+	if (flags == (SB_INITIALIZED | SB_ACTIVE))
+		if (atomic_dec_and_test(&suspend_block_count))
+			queue_work(suspend_work_queue, &suspend_work);
+}
+EXPORT_SYMBOL(suspend_blocker_destroy);
+
+/**
+ * suspend_block() - Block suspend
+ * @blocker:	The suspend blocker to use
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_block: %s\n", blocker->name);
+	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED,
+	    SB_INITIALIZED | SB_ACTIVE) == SB_INITIALIZED)
+		atomic_inc(&suspend_block_count);
+
+	atomic_inc(&current_event_num);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock() - Unblock suspend
+ * @blocker:	The suspend blocker to unblock.
+ *
+ * If no other suspend blockers block suspend, the system will suspend.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("suspend_unblock: %s\n", blocker->name);
+
+	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
+	    SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
+		if (atomic_dec_and_test(&suspend_block_count))
+			queue_work(suspend_work_queue, &suspend_work);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * is_blocking_suspend() - Test if a suspend blocker is blocking suspend
+ * @blocker:	The suspend blocker to check.
+ */
+bool is_blocking_suspend(struct suspend_blocker *blocker)
+{
+	return !!(atomic_read(&blocker->flags) & SB_ACTIVE);
+}
+EXPORT_SYMBOL(is_blocking_suspend);
+
+void request_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+	spin_lock_irqsave(&state_lock, irqflags);
+	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",
+			state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			requested_suspend_state, 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);
+	}
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+	spin_unlock_irqrestore(&state_lock, irqflags);
+}
+
+static int __init suspend_block_init(void)
+{
+	int ret;
+
+	suspend_blocker_init(&main_suspend_blocker, "main");
+	suspend_block(&main_suspend_blocker);
+
+	ret = sysdev_class_register(&suspend_block_sysclass);
+	if (ret) {
+		pr_err("suspend_block_init: sysdev_class_register failed\n");
+		goto err_sysdev_class_register;
+	}
+	ret = sysdev_register(&suspend_block_sysdev);
+	if (ret) {
+		pr_err("suspend_block_init: suspend_block_sysdev failed\n");
+		goto err_sysdev_register;
+	}
+
+	suspend_work_queue = create_singlethread_workqueue("suspend");
+	if (suspend_work_queue == NULL) {
+		ret = -ENOMEM;
+		goto err_suspend_work_queue;
+	}
+
+	return 0;
+
+err_suspend_work_queue:
+	sysdev_unregister(&suspend_block_sysdev);
+err_sysdev_register:
+	sysdev_class_unregister(&suspend_block_sysclass);
+err_sysdev_class_register:
+	suspend_blocker_destroy(&main_suspend_blocker);
+	return ret;
+}
+
+static void  __exit suspend_block_exit(void)
+{
+	destroy_workqueue(suspend_work_queue);
+	sysdev_unregister(&suspend_block_sysdev);
+	sysdev_class_unregister(&suspend_block_sysclass);
+	suspend_blocker_destroy(&main_suspend_blocker);
+}
+
+core_initcall(suspend_block_init);
+module_exit(suspend_block_exit);
-- 
1.6.1

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Alan Stern]

On Tue, 14 Apr 2009, [utf-8] Arve Hjønnevåg wrote:

> +Suspend blockers can be used to allow user-space to decide which keys should
> +wake the full system up and turn the screen on.

This sentence still grates on me.  For readers not familiar with the 
embedded/phone environment, it won't make any sense.  Furthermore the 
rest of the text below doesn't even mention the screen, which will 
cause readers to wonder why it is mentioned here.

>  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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. It determines that the
> +  key should not wake up the full system, calls suspend_unblock on the
> +  process-input-events suspend_blocker and calls select or poll.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++

How about replacing that first sentence with something like this:

	In cell phones or other embedded systems where powering the
	screen is a significant drain on the battery, suspend blockers 
	can be used to allow user-space to decide whether a keystroke
	received while the system is suspended should cause the screen 
	to be turned back on or allow the system to go back into 
	suspend.

Then in the last section, say this:

      - The user-space input-event thread returns from read. If it 
	determines that the key should leave the screen off, it
	calls suspend_unblock on the process_input_events
	suspend_blocker and then calls select or poll.  The system
	will automatically suspend again, since now no suspend blockers
	are active.

Alan Stern

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Wed, Apr 15, 2009 at 11:29:01AM -0400, Alan Stern wrote:
> On Tue, 14 Apr 2009, [utf-8] Arve Hjønnevåg wrote:
> 
> > +Suspend blockers can be used to allow user-space to decide which keys should
> > +wake the full system up and turn the screen on.
> 
> This sentence still grates on me.  For readers not familiar with the 
> embedded/phone environment, it won't make any sense.  Furthermore the 
> rest of the text below doesn't even mention the screen, which will 
> cause readers to wonder why it is mentioned here.
> 
> >  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 calls suspend_block on the
> > +  keypad-scan suspend_blocker 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 calls
> > +  suspend_block on the input-event-queue suspend_blocker.
> > +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> > +  on the keypad-scan suspend_blocker.
> > +- The user-space input-event thread returns from select/poll, calls
> > +  suspend_block on the process-input-events suspend_blocker and then calls read
> > +  on the input-event device.
> > +- The input-event driver dequeues the key-event and, since the queue is now
> > +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> > +- The user-space input-event thread returns from read. It determines that the
> > +  key should not wake up the full system, calls suspend_unblock on the
> > +  process-input-events suspend_blocker and calls select or poll.
> > +
> > +                 Key pressed   Key released
> > +                     |             |
> > +keypad-scan          ++++++++++++++++++
> > +input-event-queue        +++          +++
> > +process-input-events       +++          +++
> 
> How about replacing that first sentence with something like this:
> 
> 	In cell phones or other embedded systems where powering the
> 	screen is a significant drain on the battery, suspend blockers 
> 	can be used to allow user-space to decide whether a keystroke
> 	received while the system is suspended should cause the screen 
> 	to be turned back on or allow the system to go back into 
> 	suspend.
> 
> Then in the last section, say this:
> 
>       - The user-space input-event thread returns from read. If it 
> 	determines that the key should leave the screen off, it
> 	calls suspend_unblock on the process_input_events
> 	suspend_blocker and then calls select or poll.  The system
> 	will automatically suspend again, since now no suspend blockers
> 	are active.

I'm still re-reviewing the design so I probably should keep my mouth
shut, but I only see code for constraining entry into suspend state (S3
if you will)  I didn't see code that would get called to block device
entry into higher power states just constraints on entire system entry
into sleep state.  (I apologize if I missed that code and will happily
eat my words if needed.)

more comments after I finish looking over the code.

--mgross

 

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Wed, Apr 15, 2009 at 12:08 PM, mark gross <mgross@linux.intel.com> wrote:
> I'm still re-reviewing the design so I probably should keep my mouth
> shut, but I only see code for constraining entry into suspend state (S3
> if you will)  I didn't see code that would get called to block device
> entry into higher power states just constraints on entire system entry
> into sleep state.  (I apologize if I missed that code and will happily
> eat my words if needed.)
>

I removed the idle wake lock type since it had too much overlap with
pm_qos. Are there any references to them left in the documentation?

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2009/4/15 Alan Stern <stern@rowland.harvard.edu>:
> On Tue, 14 Apr 2009, [utf-8] Arve Hjønnevåg wrote:
>
>> +Suspend blockers can be used to allow user-space to decide which keys should
>> +wake the full system up and turn the screen on.
>
> This sentence still grates on me.  For readers not familiar with the
> embedded/phone environment, it won't make any sense.  Furthermore the
> rest of the text below doesn't even mention the screen, which will
> cause readers to wonder why it is mentioned here.
>
>>  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 calls suspend_block on the
>> +  keypad-scan suspend_blocker 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 calls
>> +  suspend_block on the input-event-queue suspend_blocker.
>> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
>> +  on the keypad-scan suspend_blocker.
>> +- The user-space input-event thread returns from select/poll, calls
>> +  suspend_block on the process-input-events suspend_blocker and then calls read
>> +  on the input-event device.
>> +- The input-event driver dequeues the key-event and, since the queue is now
>> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
>> +- The user-space input-event thread returns from read. It determines that the
>> +  key should not wake up the full system, calls suspend_unblock on the
>> +  process-input-events suspend_blocker and calls select or poll.
>> +
>> +                 Key pressed   Key released
>> +                     |             |
>> +keypad-scan          ++++++++++++++++++
>> +input-event-queue        +++          +++
>> +process-input-events       +++          +++
>
> How about replacing that first sentence with something like this:
>
>        In cell phones or other embedded systems where powering the
>        screen is a significant drain on the battery, suspend blockers
>        can be used to allow user-space to decide whether a keystroke
>        received while the system is suspended should cause the screen
>        to be turned back on or allow the system to go back into
>        suspend.
>
> Then in the last section, say this:
>
>      - The user-space input-event thread returns from read. If it
>        determines that the key should leave the screen off, it
>        calls suspend_unblock on the process_input_events
>        suspend_blocker and then calls select or poll.  The system
>        will automatically suspend again, since now no suspend blockers
>        are active.
>

This sounds reasonable too me.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

I'm sure you are sick of this question, but couldn't you do this same
functionality (constraining entry to Suspend) using existing
infrastructure.  You are clearly aggregating a block-count and triggering
on an zero aggregate value to enter Suspend.

I'm thinking you could do something like CPUIDLE to push the implicit
suspend call and use a new pmqos parameter to keep the system alive.
We'd have to look at the API to make sure it would work in interrupt
mode.

The only thing I got from the earlier threads asking why not PMQOS, was
some complaint about the strcmp the constraint aggregation does WRT
performance.  I don't think it would be too hard to address the perceived
performance issue (even if its yet to be proven as an issue anywhere)

FWIW there is some talk of re-factoring some of pmqos to sit on top of a
constraint framework (to generalize the code a little and support
constraining things that are not really measurable in terms of latencies
or throughputs)

anyway a few comments below.

On Tue, Apr 14, 2009 at 06:41:25PM -0700, Arve Hjønnevåg wrote:
> Adds /sys/power/request_state, a non-blocking interface that specifies
> which suspend state to enter when no suspend blockers are active. A
> special state, "on", stops the process by activating the "main" suspend
> blocker.
> 
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  Documentation/power/suspend-blockers.txt |   76 +++++++++
>  include/linux/suspend_block.h            |   61 +++++++
>  kernel/power/Kconfig                     |   10 ++
>  kernel/power/Makefile                    |    1 +
>  kernel/power/main.c                      |   62 +++++++
>  kernel/power/power.h                     |    6 +
>  kernel/power/suspend_block.c             |  257 ++++++++++++++++++++++++++++++
>  7 files changed, 473 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/power/suspend-blockers.txt
>  create mode 100755 include/linux/suspend_block.h
>  create mode 100644 kernel/power/suspend_block.c
> 
> diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
> new file mode 100644
> index 0000000..743b870
> --- /dev/null
> +++ b/Documentation/power/suspend-blockers.txt
> @@ -0,0 +1,76 @@
> +Suspend blockers
> +================
> +
> +A suspend_blocker prevents the system from entering suspend.

And trigger implicit entry into suspend when last blocker is released.

> +
> +If the suspend operation has already started when calling suspend_block on a
> +suspend_blocker, it will abort the suspend operation as long it has not already
> +reached the sysdev suspend stage. This means that calling suspend_block from an
> +interrupt handler or a freezeable thread always works, but if you call
> +block_suspend from a sysdev suspend handler you must also return an error from
> +that handler to abort suspend.
> +
> +Suspend blockers can be used to allow user-space to decide which keys should
> +wake the full system up and turn the screen on. 

Provided the user mode process controlling the screen power is in the calling
path of user-space input-event thread.

Basically it should be made clear that this is not a device PM
implementation.  Its a global system suspend constraint system, where
the count of blockers is aggregated in a static variable,
suspend_block_count, within suspend_block.c  with implicit suspend
called when block count gets to zero.

i.e. only useful in platform specific code for platforms that can do
~10ms suspends and resumes.
 
> 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 calls suspend_block on the
> +  keypad-scan suspend_blocker and starts scanning the keypad matrix.
count = 1
> +- 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
count = 2
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
count = 1
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
count = 2
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
count = 1
> +- The user-space input-event thread returns from read. It determines that the
> +  key should not wake up the full system, calls suspend_unblock on the
> +  process-input-events suspend_blocker and calls select or poll.
count = 0 + race between dropping into Suspend state and the execution
of the select or poll.  (should probably be ok)

> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++
> +
> +
> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);
> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);
> +
> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
> +it is not active has no effect. This allows drivers to update their state and
> +call suspend suspend_block or suspend_unblock based on the result.
> +For instance:
> +
> +if (list_empty(&state->pending_work))
> +	suspend_unblock(&state->suspend_blocker);
> +else
> +	suspend_block(&state->suspend_blocker);
> +
> diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
> new file mode 100755
> index 0000000..7820c60
> --- /dev/null
> +++ b/include/linux/suspend_block.h
> @@ -0,0 +1,61 @@
> +/* include/linux/suspend_block.h
> + *
> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCK_H
> +#define _LINUX_SUSPEND_BLOCK_H
> +
> +/* A suspend_blocker prevents the system from entering suspend when active.
> + */
> +
> +struct suspend_blocker {
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	atomic_t            flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +
> +/* is_blocking_suspend returns true if the suspend_blocker is currently active.
> + */
> +bool is_blocking_suspend(struct suspend_blocker *blocker);
> +
> +/* suspend_is_blocked can be used by generic power management code to abort
> + * suspend.
> + *
> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
> + * is called during suspend initiated from the suspend_block code.
> + */
> +bool suspend_is_blocked(void);
> +
> +#else
> +
> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
> +					const char *name) {}
> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
> +static inline void suspend_block(struct suspend_blocker *blocker) {}
> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
> +static inline bool is_blocking_suspend(struct suspend_blocker *bl) { return 0; }
> +static inline bool suspend_is_blocked(void) { return 0; }
> +
> +#endif
> +
> +#endif
> +
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 23bd4da..9d1df13 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -116,6 +116,16 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config SUSPEND_BLOCK
> +	bool "Suspend block"
> +	depends on PM
> +	select RTC_LIB
> +	default n
> +	---help---
> +	  Enable suspend_block. When user space requests a sleep state through
> +	  /sys/power/request_state, the requested sleep state will be entered
> +	  when no suspend_blockers are active.
> +
>  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 720ea4f..29cdc9e 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -6,6 +6,7 @@ endif
>  obj-$(CONFIG_PM)		+= main.o
>  obj-$(CONFIG_PM_SLEEP)		+= console.o
>  obj-$(CONFIG_FREEZER)		+= process.o
> +obj-$(CONFIG_SUSPEND_BLOCK)	+= suspend_block.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/main.c b/kernel/power/main.c
> index c9632f8..e4c6b20 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -22,6 +22,7 @@
>  #include <linux/freezer.h>
>  #include <linux/vmstat.h>
>  #include <linux/syscalls.h>
> +#include <linux/suspend_block.h>
>  
>  #include "power.h"
>  
> @@ -392,6 +393,9 @@ static void suspend_finish(void)
>  
>  
>  static const char * const pm_states[PM_SUSPEND_MAX] = {
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	[PM_SUSPEND_ON]		= "on",
> +#endif
>  	[PM_SUSPEND_STANDBY]	= "standby",
>  	[PM_SUSPEND_MEM]	= "mem",
>  };
> @@ -540,6 +544,61 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	request_state - control system power state.
> + *
> + *	This is similar to state, but it does not block until the system
> + *	resumes, and it will try to re-enter the state until another state is
> + *	requested. Suspend blockers are respected and the requested state will
> + *	only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
> + */
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +static ssize_t request_state_show(struct kobject *kobj,
> +				  struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> +		if (pm_states[i] && (i == PM_SUSPEND_ON || valid_state(i)))
> +			s += sprintf(s, "%s ", pm_states[i]);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t request_state_store(struct kobject *kobj,
> +				   struct kobj_attribute *attr,
> +				   const char *buf, size_t n)
> +{
> +	suspend_state_t state = PM_SUSPEND_ON;
> +	const char * const *s;
> +	char *p;
> +	int len;
> +	int error = -EINVAL;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
> +		if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
> +			break;
> +	}
> +	if (state < PM_SUSPEND_MAX && *s)
> +		if (state == PM_SUSPEND_ON || valid_state(state)) {
> +			error = 0;
> +			request_suspend_state(state);
> +		}
> +	return error ? error : n;
> +}
> +
> +power_attr(request_state);
> +#endif /* CONFIG_SUSPEND_BLOCK */
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  
> @@ -567,6 +626,9 @@ power_attr(pm_trace);
>  
>  static struct attribute * g[] = {
>  	&state_attr.attr,
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	&request_state_attr.attr,
> +#endif
>  #ifdef CONFIG_PM_TRACE
>  	&pm_trace_attr.attr,
>  #endif
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 46b5ec7..2414a74 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
>  {
>  }
>  #endif
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +/* kernel/power/suspend_block.c */
> +void request_suspend_state(suspend_state_t state);
> +#endif
> +
> diff --git a/kernel/power/suspend_block.c b/kernel/power/suspend_block.c
> new file mode 100644
> index 0000000..b4f2191
> --- /dev/null
> +++ b/kernel/power/suspend_block.c
> @@ -0,0 +1,257 @@
> +/* kernel/power/suspend_block.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/rtc.h>
> +#include <linux/suspend.h>
> +#include <linux/suspend_block.h>
> +#include <linux/sysdev.h>
> +#include "power.h"
> +
> +enum {
> +	DEBUG_EXIT_SUSPEND = 1U << 0,
> +	DEBUG_WAKEUP = 1U << 1,
> +	DEBUG_USER_STATE = 1U << 2,
> +	DEBUG_SUSPEND = 1U << 3,
> +	DEBUG_SUSPEND_BLOCKER = 1U << 4,
> +};
> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
> +
> +#define SB_INITIALIZED            (1U << 8)
> +#define SB_ACTIVE                 (1U << 9)
> +
> +static DEFINE_SPINLOCK(state_lock);
> +static atomic_t suspend_block_count;

So if suspend_block_count is the lynch pin of the design, why have all
the suspend_blocker structs?  Why have all the logic around the
different suspend blocker instances?

It seems like a lot of extra effort for an atomic "stay awake" counter.


--mgross


> +static atomic_t current_event_num;
> +struct workqueue_struct *suspend_work_queue;
> +struct suspend_blocker main_suspend_blocker;
> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
> +static bool enable_suspend_blockers;
> +
> +bool suspend_is_blocked(void)
> +{
> +	if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
> +		return 0;
> +	return !!atomic_read(&suspend_block_count);
> +}
> +
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = 1;
> +
> +retry:
> +	if (suspend_is_blocked()) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: abort suspend\n");
> +		goto abort;
> +	}
> +
> +	entry_event_num = atomic_read(&current_event_num);
> +	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 (atomic_read(&current_event_num) == entry_event_num) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +		goto retry;
> +	}
> +abort:
> +	enable_suspend_blockers = 0;
> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
> +{
> +	int ret = suspend_is_blocked() ? -EAGAIN : 0;
> +	if (debug_mask & DEBUG_SUSPEND)
> +		pr_info("suspend_block_suspend return %d\n", ret);
> +	return ret;
> +}
> +
> +static struct sysdev_class suspend_block_sysclass = {
> +	.name = "suspend_block",
> +	.suspend = suspend_block_suspend,
> +};
> +static struct sys_device suspend_block_sysdev = {
> +	.cls = &suspend_block_sysclass,
> +};
> +
> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in
> + *		/proc/suspend_blockers
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	if (name)
> +		blocker->name = name;
> +	BUG_ON(!blocker->name);
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", blocker->name);
> +
> +	atomic_set(&blocker->flags, SB_INITIALIZED);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);
> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	int flags;
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +	flags = atomic_xchg(&blocker->flags, 0);
> +	WARN(!(flags & SB_INITIALIZED), "suspend_blocker_destroy called on "
> +					"uninitialized suspend_blocker\n");
> +	if (flags == (SB_INITIALIZED | SB_ACTIVE))
> +		if (atomic_dec_and_test(&suspend_block_count))
> +			queue_work(suspend_work_queue, &suspend_work);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));
> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED,
> +	    SB_INITIALIZED | SB_ACTIVE) == SB_INITIALIZED)
> +		atomic_inc(&suspend_block_count);
> +
> +	atomic_inc(&current_event_num);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
> +	    SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
> +		if (atomic_dec_and_test(&suspend_block_count))
> +			queue_work(suspend_work_queue, &suspend_work);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * is_blocking_suspend() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + */
> +bool is_blocking_suspend(struct suspend_blocker *blocker)
> +{
> +	return !!(atomic_read(&blocker->flags) & SB_ACTIVE);
> +}
> +EXPORT_SYMBOL(is_blocking_suspend);
> +
> +void request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +	spin_lock_irqsave(&state_lock, irqflags);
> +	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",
> +			state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			requested_suspend_state, 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);
> +	}
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +}
> +
> +static int __init suspend_block_init(void)
> +{
> +	int ret;
> +
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +
> +	ret = sysdev_class_register(&suspend_block_sysclass);
> +	if (ret) {
> +		pr_err("suspend_block_init: sysdev_class_register failed\n");
> +		goto err_sysdev_class_register;
> +	}
> +	ret = sysdev_register(&suspend_block_sysdev);
> +	if (ret) {
> +		pr_err("suspend_block_init: suspend_block_sysdev failed\n");
> +		goto err_sysdev_register;
> +	}
> +
> +	suspend_work_queue = create_singlethread_workqueue("suspend");
> +	if (suspend_work_queue == NULL) {
> +		ret = -ENOMEM;
> +		goto err_suspend_work_queue;
> +	}
> +
> +	return 0;
> +
> +err_suspend_work_queue:
> +	sysdev_unregister(&suspend_block_sysdev);
> +err_sysdev_register:
> +	sysdev_class_unregister(&suspend_block_sysclass);
> +err_sysdev_class_register:
> +	suspend_blocker_destroy(&main_suspend_blocker);
> +	return ret;
> +}
> +
> +static void  __exit suspend_block_exit(void)
> +{
> +	destroy_workqueue(suspend_work_queue);
> +	sysdev_unregister(&suspend_block_sysdev);
> +	sysdev_class_unregister(&suspend_block_sysclass);
> +	suspend_blocker_destroy(&main_suspend_blocker);
> +}
> +
> +core_initcall(suspend_block_init);
> +module_exit(suspend_block_exit);
> -- 
> 1.6.1

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2009/4/15 mark gross <mgross@linux.intel.com>:
> I'm sure you are sick of this question, but couldn't you do this same
> functionality (constraining entry to Suspend) using existing
> infrastructure.  You are clearly aggregating a block-count and triggering
> on an zero aggregate value to enter Suspend.

The only reason I have a block count, is that the feedback on this
list was that it is too expensive to use a spin-lock every time we
want to block or unblock suspend. The later patches that enable stats
and timeout support uses inactive and active lists instead.

>
> I'm thinking you could do something like CPUIDLE to push the implicit
> suspend call and use a new pmqos parameter to keep the system alive.
> We'd have to look at the API to make sure it would work in interrupt
> mode.
>
> The only thing I got from the earlier threads asking why not PMQOS, was
> some complaint about the strcmp the constraint aggregation does WRT
> performance.  I don't think it would be too hard to address the perceived
> performance issue (even if its yet to be proven as an issue anywhere)

There was a question about why we did not use pmqos instead othe the
idle wake locks. One reason was that we mainly needed to prevent a
specific state to not loose interrupts, not because the latency was
too high. The other reason was that the pm qos interface uses strings
instead of handles. Using strings to search to a list for the item you
want to update has an impact on performance that is not hard to
measure, but it also require the clients to create unique strings.

> FWIW there is some talk of re-factoring some of pmqos to sit on top of a
> constraint framework (to generalize the code a little and support
> constraining things that are not really measurable in terms of latencies
> or throughputs)
>

That should help with replacing the idle-wake-locks.

> anyway a few comments below.
>
> On Tue, Apr 14, 2009 at 06:41:25PM -0700, Arve Hjønnevåg wrote:
>> Adds /sys/power/request_state, a non-blocking interface that specifies
>> which suspend state to enter when no suspend blockers are active. A
>> special state, "on", stops the process by activating the "main" suspend
>> blocker.
>>
>> Signed-off-by: Arve Hjønnevåg <arve@android.com>
>> ---
>>  Documentation/power/suspend-blockers.txt |   76 +++++++++
>>  include/linux/suspend_block.h            |   61 +++++++
>>  kernel/power/Kconfig                     |   10 ++
>>  kernel/power/Makefile                    |    1 +
>>  kernel/power/main.c                      |   62 +++++++
>>  kernel/power/power.h                     |    6 +
>>  kernel/power/suspend_block.c             |  257 ++++++++++++++++++++++++++++++
>>  7 files changed, 473 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/power/suspend-blockers.txt
>>  create mode 100755 include/linux/suspend_block.h
>>  create mode 100644 kernel/power/suspend_block.c
>>
>> diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
>> new file mode 100644
>> index 0000000..743b870
>> --- /dev/null
>> +++ b/Documentation/power/suspend-blockers.txt
>> @@ -0,0 +1,76 @@
>> +Suspend blockers
>> +================
>> +
>> +A suspend_blocker prevents the system from entering suspend.
>
> And trigger implicit entry into suspend when last blocker is released.
>
>> +
>> +If the suspend operation has already started when calling suspend_block on a
>> +suspend_blocker, it will abort the suspend operation as long it has not already
>> +reached the sysdev suspend stage. This means that calling suspend_block from an
>> +interrupt handler or a freezeable thread always works, but if you call
>> +block_suspend from a sysdev suspend handler you must also return an error from
>> +that handler to abort suspend.
>> +
>> +Suspend blockers can be used to allow user-space to decide which keys should
>> +wake the full system up and turn the screen on.
>
> Provided the user mode process controlling the screen power is in the calling
> path of user-space input-event thread.

What you mean by this? Our user-space input event thread does not turn
the screen on, but translates the events and queues the translated
event on another queue. As long as all queues are protected by a
suspend blocker, there is no requirement about which thread turns the
screen on.

>
> Basically it should be made clear that this is not a device PM
> implementation.  Its a global system suspend constraint system, where
> the count of blockers is aggregated in a static variable,
> suspend_block_count, within suspend_block.c  with implicit suspend
> called when block count gets to zero.
>
> i.e. only useful in platform specific code for platforms that can do
> ~10ms suspends and resumes.

I disagree. If I have a desktop system that takes 5 seconds to wake up
from sleep, I still want the ability to auto suspend after user
inactivity, and to prevent suspend while some tasks are running.

>
>> 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 calls suspend_block on the
>> +  keypad-scan suspend_blocker and starts scanning the keypad matrix.
> count = 1
>> +- 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 calls
>> +  suspend_block on the input-event-queue suspend_blocker.
> count = 2
>> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
>> +  on the keypad-scan suspend_blocker.
> count = 1
>> +- The user-space input-event thread returns from select/poll, calls
>> +  suspend_block on the process-input-events suspend_blocker and then calls read
>> +  on the input-event device.
> count = 2
>> +- The input-event driver dequeues the key-event and, since the queue is now
>> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> count = 1
>> +- The user-space input-event thread returns from read. It determines that the
>> +  key should not wake up the full system, calls suspend_unblock on the
>> +  process-input-events suspend_blocker and calls select or poll.
> count = 0 + race between dropping into Suspend state and the execution
> of the select or poll.  (should probably be ok)

This is not a race condition, select or poll does not affect the
suspend blocker in the input driver to it does not matter if the poll
is called before or after suspend.

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

>> +struct suspend_blocker {
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +     atomic_t            flags;
>> +     const char         *name;
>> +#endif
>> +};
>> +
...
>> +
>> +#define SB_INITIALIZED            (1U << 8)
>> +#define SB_ACTIVE                 (1U << 9)
>> +
>> +static DEFINE_SPINLOCK(state_lock);
>> +static atomic_t suspend_block_count;
>
> So if suspend_block_count is the lynch pin of the design, why have all
> the suspend_blocker structs?  Why have all the logic around the
> different suspend blocker instances?

The suspend block structs need to be part of the api to allow stats
and/or debugging. It also ensures that a single suspend_blocker does
not change the global count by more than one. Also,
suspend_block_count is not part of the design, it is an optimization
that becomes useless when you enable stats.

>
> It seems like a lot of extra effort for an atomic "stay awake" counter.
>


-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[mark gross]

On Wed, Apr 15, 2009 at 06:45:00PM -0700, Arve Hjønnevåg wrote:
> 2009/4/15 mark gross <mgross@linux.intel.com>:
> > I'm sure you are sick of this question, but couldn't you do this same
> > functionality (constraining entry to Suspend) using existing
> > infrastructure.  You are clearly aggregating a block-count and triggering
> > on an zero aggregate value to enter Suspend.
> 
> The only reason I have a block count, is that the feedback on this
> list was that it is too expensive to use a spin-lock every time we
> want to block or unblock suspend. The later patches that enable stats
> and timeout support uses inactive and active lists instead.
> 
> >
> > I'm thinking you could do something like CPUIDLE to push the implicit
> > suspend call and use a new pmqos parameter to keep the system alive.
> > We'd have to look at the API to make sure it would work in interrupt
> > mode.
> >
> > The only thing I got from the earlier threads asking why not PMQOS, was
> > some complaint about the strcmp the constraint aggregation does WRT
> > performance.  I don't think it would be too hard to address the perceived
> > performance issue (even if its yet to be proven as an issue anywhere)
> 
> There was a question about why we did not use pmqos instead othe the
> idle wake locks. One reason was that we mainly needed to prevent a
> specific state to not loose interrupts, not because the latency was
> too high. The other reason was that the pm qos interface uses strings
> instead of handles. Using strings to search to a list for the item you
> want to update has an impact on performance that is not hard to
> measure, but it also require the clients to create unique strings.

really?  How many times / second was your system changing the pmqos
parameter?  If that turns out to be realistic, non-abusive use of the api
then perhaps I need to migrate pmqos to include / use handles.  

when pmqos was designed we assumed it wouldn't be hit with high
parameter change rates.  What could be a realistic upper bound on
change rate for the parameters?

> 
> > FWIW there is some talk of re-factoring some of pmqos to sit on top of a
> > constraint framework (to generalize the code a little and support
> > constraining things that are not really measurable in terms of latencies
> > or throughputs)
> >
> 
> That should help with replacing the idle-wake-locks.
> 
> > anyway a few comments below.
> >
> > On Tue, Apr 14, 2009 at 06:41:25PM -0700, Arve Hjønnevåg wrote:
> >> Adds /sys/power/request_state, a non-blocking interface that specifies
> >> which suspend state to enter when no suspend blockers are active. A
> >> special state, "on", stops the process by activating the "main" suspend
> >> blocker.
> >>
> >> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> >> ---
> >>  Documentation/power/suspend-blockers.txt |   76 +++++++++
> >>  include/linux/suspend_block.h            |   61 +++++++
> >>  kernel/power/Kconfig                     |   10 ++
> >>  kernel/power/Makefile                    |    1 +
> >>  kernel/power/main.c                      |   62 +++++++
> >>  kernel/power/power.h                     |    6 +
> >>  kernel/power/suspend_block.c             |  257 ++++++++++++++++++++++++++++++
> >>  7 files changed, 473 insertions(+), 0 deletions(-)
> >>  create mode 100644 Documentation/power/suspend-blockers.txt
> >>  create mode 100755 include/linux/suspend_block.h
> >>  create mode 100644 kernel/power/suspend_block.c
> >>
> >> diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
> >> new file mode 100644
> >> index 0000000..743b870
> >> --- /dev/null
> >> +++ b/Documentation/power/suspend-blockers.txt
> >> @@ -0,0 +1,76 @@
> >> +Suspend blockers
> >> +================
> >> +
> >> +A suspend_blocker prevents the system from entering suspend.
> >
> > And trigger implicit entry into suspend when last blocker is released.
> >
> >> +
> >> +If the suspend operation has already started when calling suspend_block on a
> >> +suspend_blocker, it will abort the suspend operation as long it has not already
> >> +reached the sysdev suspend stage. This means that calling suspend_block from an
> >> +interrupt handler or a freezeable thread always works, but if you call
> >> +block_suspend from a sysdev suspend handler you must also return an error from
> >> +that handler to abort suspend.
> >> +
> >> +Suspend blockers can be used to allow user-space to decide which keys should
> >> +wake the full system up and turn the screen on.
> >
> > Provided the user mode process controlling the screen power is in the calling
> > path of user-space input-event thread.
> 
> What you mean by this? Our user-space input event thread does not turn
> the screen on, but translates the events and queues the translated
> event on another queue. As long as all queues are protected by a
> suspend blocker, there is no requirement about which thread turns the
> screen on.

I mean that to enable the promised partial system wake up ( "Suspend
blockers can be used to allow user-space to decide which keys should
wake the full system up and turn the screen on.") there is more to the
story as this API is about system level pm not device PM needed to keep
the screen off while partially waking things up before suspending again.

Perhaps an explanation on how suspend blocker can be used to partially
wake up a system without the screen coming on would help me.  Right now
I'm not seeing how that can be implemented in the context of this patch.


 
> >
> > Basically it should be made clear that this is not a device PM
> > implementation.  Its a global system suspend constraint system, where
> > the count of blockers is aggregated in a static variable,
> > suspend_block_count, within suspend_block.c  with implicit suspend
> > called when block count gets to zero.
> >
> > i.e. only useful in platform specific code for platforms that can do
> > ~10ms suspends and resumes.
> 
> I disagree. If I have a desktop system that takes 5 seconds to wake up
> from sleep, I still want the ability to auto suspend after user
> inactivity, and to prevent suspend while some tasks are running.

I guess we have this now, but the user mode implementations don't scale
to low latency and frequent suspend applications.


--mgross


> >
> >> 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 calls suspend_block on the
> >> +  keypad-scan suspend_blocker and starts scanning the keypad matrix.
> > count = 1
> >> +- 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 calls
> >> +  suspend_block on the input-event-queue suspend_blocker.
> > count = 2
> >> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> >> +  on the keypad-scan suspend_blocker.
> > count = 1
> >> +- The user-space input-event thread returns from select/poll, calls
> >> +  suspend_block on the process-input-events suspend_blocker and then calls read
> >> +  on the input-event device.
> > count = 2
> >> +- The input-event driver dequeues the key-event and, since the queue is now
> >> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> > count = 1
> >> +- The user-space input-event thread returns from read. It determines that the
> >> +  key should not wake up the full system, calls suspend_unblock on the
> >> +  process-input-events suspend_blocker and calls select or poll.
> > count = 0 + race between dropping into Suspend state and the execution
> > of the select or poll.  (should probably be ok)
> 
> This is not a race condition, select or poll does not affect the
> suspend blocker in the input driver to it does not matter if the poll
> is called before or after suspend.
> 
> >
> >> +
> >> +                 Key pressed   Key released
> >> +                     |             |
> >> +keypad-scan          ++++++++++++++++++
> >> +input-event-queue        +++          +++
> >> +process-input-events       +++          +++
> >> +
> >> +
> 
> >> +struct suspend_blocker {
> >> +#ifdef CONFIG_SUSPEND_BLOCK
> >> +     atomic_t            flags;
> >> +     const char         *name;
> >> +#endif
> >> +};
> >> +
> ...
> >> +
> >> +#define SB_INITIALIZED            (1U << 8)
> >> +#define SB_ACTIVE                 (1U << 9)
> >> +
> >> +static DEFINE_SPINLOCK(state_lock);
> >> +static atomic_t suspend_block_count;
> >
> > So if suspend_block_count is the lynch pin of the design, why have all
> > the suspend_blocker structs?  Why have all the logic around the
> > different suspend blocker instances?
> 
> The suspend block structs need to be part of the api to allow stats
> and/or debugging. It also ensures that a single suspend_blocker does
> not change the global count by more than one. Also,
> suspend_block_count is not part of the design, it is an optimization
> that becomes useless when you enable stats.
> 
> >
> > It seems like a lot of extra effort for an atomic "stay awake" counter.
> >
> 
> 
> -- 
> Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!


> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);
> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);

Sounds reasonably sane. Maybe it should be block_suspend(), because
suspend_block() sounds like... something that builds suspend, but I
guess it is good enough.

> +/* A suspend_blocker prevents the system from entering suspend when active.
> + */
> +

linuxdoc?

> +struct suspend_blocker {
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	atomic_t            flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +
> +/* is_blocking_suspend returns true if the suspend_blocker is currently active.
> + */
> +bool is_blocking_suspend(struct suspend_blocker *blocker);

Same here?

> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 23bd4da..9d1df13 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -116,6 +116,16 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config SUSPEND_BLOCK
> +	bool "Suspend block"
> +	depends on PM
> +	select RTC_LIB

Is RTC_LIB okay to select?

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

This allows you to write "on" to the other interfaces where that makes
no sense.... right?

> +static bool enable_suspend_blockers;

Uhuh... What is this good for... except debugging?

> +bool suspend_is_blocked(void)
> +{
> +	if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
> +		return 0;
> +	return !!atomic_read(&suspend_block_count);
> +}

Yes, if enable_suspend_blockers is one, we are in deep trouble.

> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in
> + *		/proc/suspend_blockers

I don't think suspend_blockers should go to /proc. They are not process-related.

> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));
As blocker->flags seem to be used mostly for debugging; do they have
to use "atomic"? Normally, "magic" variable is used, instead. (Single
bit is probably not enough to guard against using uninitialized
memory.)

> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{

...BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED)); ?

> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
> +	    SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
> +		if (atomic_dec_and_test(&suspend_block_count))
> +			queue_work(suspend_work_queue, &suspend_work);
> +}
> +EXPORT_SYMBOL(suspend_unblock);

Uhuh... can we "loose a oportunity to suspend" here? If someone is
just updating the flags...? Is it guaranteed that if two people do
suspend_unblock at the same time, one of them will pass?

> +void request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +	spin_lock_irqsave(&state_lock, irqflags);
> +	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",
> +			state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			requested_suspend_state, 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);

Introduce macro for printing time?

Otherwise, it looks good...
									Pavel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Mon, Apr 20, 2009 at 2:29 AM, Pavel Machek <pavel@ucw.cz> wrote:

>> +When the driver determines that it needs to run (usually in an interrupt
>> +handler) it calls suspend_block:
>> +     suspend_block(&state->suspend_blocker);
>> +
>> +When it no longer needs to run it calls suspend_unblock:
>> +     suspend_unblock(&state->suspend_blocker);
>
> Sounds reasonably sane. Maybe it should be block_suspend(), because
> suspend_block() sounds like... something that builds suspend, but I
> guess it is good enough.
>

I was trying to keep a common prefix.

>> +/* A suspend_blocker prevents the system from entering suspend when active.
>> + */
>> +
>
> linuxdoc?
>
>> +struct suspend_blocker {
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +     atomic_t            flags;
>> +     const char         *name;
>> +#endif
>> +};
>> +
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +
>> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
>> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
>> +void suspend_block(struct suspend_blocker *blocker);
>> +void suspend_unblock(struct suspend_blocker *blocker);
>> +
>> +/* is_blocking_suspend returns true if the suspend_blocker is currently active.
>> + */
>> +bool is_blocking_suspend(struct suspend_blocker *blocker);
>
> Same here?

I moved this to the c file, see diff below.

>
>> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
>> index 23bd4da..9d1df13 100644
>> --- a/kernel/power/Kconfig
>> +++ b/kernel/power/Kconfig
>> @@ -116,6 +116,16 @@ config SUSPEND_FREEZER
>>
>>         Turning OFF this setting is NOT recommended! If in doubt, say Y.
>>
>> +config SUSPEND_BLOCK
>> +     bool "Suspend block"
>> +     depends on PM
>> +     select RTC_LIB
>
> Is RTC_LIB okay to select?

It should be. It cannot be enabled manually.

>> @@ -392,6 +393,9 @@ static void suspend_finish(void)
>>
>>
>>  static const char * const pm_states[PM_SUSPEND_MAX] = {
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +     [PM_SUSPEND_ON]         = "on",
>> +#endif
>>       [PM_SUSPEND_STANDBY]    = "standby",
>>       [PM_SUSPEND_MEM]        = "mem",
>>  };
>
> This allows you to write "on" to the other interfaces where that makes
> no sense.... right?

state_store starts iterating at PM_SUSPEND_STANDBY, so don't think so.

>
>> +static bool enable_suspend_blockers;
>
> Uhuh... What is this good for... except debugging?

It prevents suspend blockers from affecting existing suspend and
freezing interfaces (while auto suspend is not active).

>
>> +bool suspend_is_blocked(void)
>> +{
>> +     if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
>> +             return 0;
>> +     return !!atomic_read(&suspend_block_count);
>> +}
>
> Yes, if enable_suspend_blockers is one, we are in deep trouble.

It just means that you compiled suspend blocker support into the
kernel, but used an old interface to enter suspend. It warns if
enable_suspend_blockers is 0 not 1.

>
>> +/**
>> + * suspend_blocker_init() - Initialize a suspend blocker
>> + * @blocker: The suspend blocker to initialize.
>> + * @name:    The name of the suspend blocker to show in
>> + *           /proc/suspend_blockers
>
> I don't think suspend_blockers should go to /proc. They are not process-related.

I moved that comment to the stats patch. It is still in procfs though,
as it is most similar to other procfs entries. It is not allowed under
the sysfs rules, and we do not want to enable debugfs on a production
system since it exposes some unsafe interfaces.

>
>> +/**
>> + * suspend_block() - Block suspend
>> + * @blocker: The suspend blocker to use
>> + */
>> +void suspend_block(struct suspend_blocker *blocker)
>> +{
>> +     BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));
> As blocker->flags seem to be used mostly for debugging; do they have
> to use "atomic"? Normally, "magic" variable is used, instead. (Single
> bit is probably not enough to guard against using uninitialized
> memory.)

It is mostly used to determine if the suspend blocker is already
active, so yes it has to be atomic. I could add a magic value, but a
single bit is enough to catch uninitialized global and kzalloced
members.

>
>> + * suspend_unblock() - Unblock suspend
>> + * @blocker: The suspend blocker to unblock.
>> + *
>> + * If no other suspend blockers block suspend, the system will suspend.
>> + */
>> +void suspend_unblock(struct suspend_blocker *blocker)
>> +{
>
> ...BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED)); ?

Perhaps. This function does not do anything unless you have already
called suspend_block though.

>
>> +     if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> +             pr_info("suspend_unblock: %s\n", blocker->name);
>> +
>> +     if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
>> +         SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
>> +             if (atomic_dec_and_test(&suspend_block_count))
>> +                     queue_work(suspend_work_queue, &suspend_work);
>> +}
>> +EXPORT_SYMBOL(suspend_unblock);
>
> Uhuh... can we "loose a oportunity to suspend" here? If someone is
> just updating the flags...? Is it guaranteed that if two people do
> suspend_unblock at the same time, one of them will pass?

What do you mean by just updating the flags? SB_ACTIVE was either
cleared or not, if it was, then atomic_dec_and_test is called.

>
>> +void request_suspend_state(suspend_state_t state)
>> +{
>> +     unsigned long irqflags;
>> +     spin_lock_irqsave(&state_lock, irqflags);
>> +     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",
>> +                     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
>> +                     requested_suspend_state, 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);
>
> Introduce macro for printing time?

OK.

-- 
Arve Hjønnevåg

----
diff --git a/Documentation/power/suspend-blockers.txt
b/Documentation/power/suspend-blockers.txt
index 743b870..e95a507 100644
--- a/Documentation/power/suspend-blockers.txt
+++ b/Documentation/power/suspend-blockers.txt
@@ -10,10 +10,14 @@ interrupt handler or a freezeable thread always
works, but if you call
 block_suspend from a sysdev suspend handler you must also return an error from
 that handler to abort suspend.

-Suspend blockers 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:
+In cell phones or other embedded systems where powering the screen is a
+significant drain on the battery, suspend blockers can be used to allow
+user-space to decide whether a keystroke received while the system is suspended
+should cause the screen to be turned back on or allow the system to
go back into
+suspend. 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 calls suspend_block on the
   keypad-scan suspend_blocker and starts scanning the keypad matrix.
 - The keypad-scan code detects a key change and reports it to the input-event
@@ -27,9 +31,11 @@ driver has resumed, the sequence of events can look
like this:
   on the input-event device.
 - The input-event driver dequeues the key-event and, since the queue is now
   empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
-- The user-space input-event thread returns from read. It determines that the
-  key should not wake up the full system, calls suspend_unblock on the
-  process-input-events suspend_blocker and calls select or poll.
+- The user-space input-event thread returns from read. If it determines that
+  the key should leave the screen off, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.

                  Key pressed   Key released
                      |             |
diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
index 7820c60..54bf9c4 100755
--- a/include/linux/suspend_block.h
+++ b/include/linux/suspend_block.h
@@ -16,7 +16,15 @@
 #ifndef _LINUX_SUSPEND_BLOCK_H
 #define _LINUX_SUSPEND_BLOCK_H

-/* A suspend_blocker prevents the system from entering suspend when active.
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @flags:     Tracks initialized and active state.
+ * @name:      Name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
  */

 struct suspend_blocker {
@@ -32,17 +40,7 @@ void suspend_blocker_init(struct suspend_blocker
*blocker, const char *name);
 void suspend_blocker_destroy(struct suspend_blocker *blocker);
 void suspend_block(struct suspend_blocker *blocker);
 void suspend_unblock(struct suspend_blocker *blocker);
-
-/* is_blocking_suspend returns true if the suspend_blocker is currently active.
- */
 bool is_blocking_suspend(struct suspend_blocker *blocker);
-
-/* suspend_is_blocked can be used by generic power management code to abort
- * suspend.
- *
- * To preserve backward compatibility suspend_is_blocked returns 0 unless it
- * is called during suspend initiated from the suspend_block code.
- */
 bool suspend_is_blocked(void);

 #else
diff --git a/kernel/power/suspend_block.c b/kernel/power/suspend_block.c
index b4f2191..1adf075 100644
--- a/kernel/power/suspend_block.c
+++ b/kernel/power/suspend_block.c
@@ -41,6 +41,27 @@ struct suspend_blocker main_suspend_blocker;
 static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
 static bool enable_suspend_blockers;

+#define pr_info_time(fmt, args...) \
+       do { \
+               struct timespec ts; \
+               struct rtc_time tm; \
+               getnstimeofday(&ts); \
+               rtc_time_to_tm(ts.tv_sec, &tm); \
+               pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+                       args, \
+                       tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+                       tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+       } while (0);
+
+/**
+ * suspend_is_blocked() - Check if suspend should be blocked
+ *
+ * suspend_is_blocked can be used by generic power management code to abort
+ * suspend.
+ *
+ * To preserve backward compatibility suspend_is_blocked returns 0 unless it
+ * is called during suspend initiated from the suspend_block code.
+ */
 bool suspend_is_blocked(void)
 {
        if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
@@ -66,16 +87,8 @@ retry:
        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 (debug_mask & DEBUG_EXIT_SUSPEND)
+               pr_info_time("suspend: exit suspend, ret = %d ", ret);
        if (atomic_read(&current_event_num) == entry_event_num) {
                if (debug_mask & DEBUG_SUSPEND)
                        pr_info("suspend: pm_suspend returned with no event\n");
@@ -105,8 +118,7 @@ static struct sys_device suspend_block_sysdev = {
 /**
  * suspend_blocker_init() - Initialize a suspend blocker
  * @blocker:   The suspend blocker to initialize.
- * @name:      The name of the suspend blocker to show in
- *             /proc/suspend_blockers
+ * @name:      The name of the suspend blocker to show in debug messages.
  */
 void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
 {
@@ -178,6 +190,8 @@ EXPORT_SYMBOL(suspend_unblock);
 /**
  * is_blocking_suspend() - Test if a suspend blocker is blocking suspend
  * @blocker:   The suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
  */
 bool is_blocking_suspend(struct suspend_blocker *blocker)
 {
@@ -189,19 +203,11 @@ void request_suspend_state(suspend_state_t state)
 {
        unsigned long irqflags;
        spin_lock_irqsave(&state_lock, irqflags);
-       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",
-                       state != PM_SUSPEND_ON ? "sleep" : "wakeup",
-                       requested_suspend_state, 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 (debug_mask & DEBUG_USER_STATE)
+               pr_info_time("request_suspend_state: %s (%d->%d) at %lld ",
+                            state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+                            requested_suspend_state, state,
+                            ktime_to_ns(ktime_get()));
        requested_suspend_state = state;
        if (state == PM_SUSPEND_ON)
                suspend_block(&main_suspend_blocker);

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> >> @@ -392,6 +393,9 @@ static void suspend_finish(void)
> >>
> >>
> >>  static const char * const pm_states[PM_SUSPEND_MAX] = {
> >> +#ifdef CONFIG_SUSPEND_BLOCK
> >> +     [PM_SUSPEND_ON]         = "on",
> >> +#endif
> >>       [PM_SUSPEND_STANDBY]    = "standby",
> >>       [PM_SUSPEND_MEM]        = "mem",
> >>  };
> >
> > This allows you to write "on" to the other interfaces where that makes
> > no sense.... right?
> 
> state_store starts iterating at PM_SUSPEND_STANDBY, so don't think so.

Good.


> >> +bool suspend_is_blocked(void)
> >> +{
> >> +     if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
> >> +             return 0;
> >> +     return !!atomic_read(&suspend_block_count);
> >> +}
> >
> > Yes, if enable_suspend_blockers is one, we are in deep trouble.
> 
> It just means that you compiled suspend blocker support into the
> kernel, but used an old interface to enter suspend. It warns if
> enable_suspend_blockers is 0 not 1.

I do not think WARN_ONCE() should be that easy to trigger. WARN is
very scary animal; better use normal printk?



> >> +/**
> >> + * suspend_blocker_init() - Initialize a suspend blocker
> >> + * @blocker: The suspend blocker to initialize.
> >> + * @name:    The name of the suspend blocker to show in
> >> + *           /proc/suspend_blockers
> >
> > I don't think suspend_blockers should go to /proc. They are not process-related.
> 
> I moved that comment to the stats patch. It is still in procfs though,
> as it is most similar to other procfs entries. It is not allowed under
> the sysfs rules, and we do not want to enable debugfs on a production
> system since it exposes some unsafe interfaces.

You have to sort this out somehow. It does not belong to /proc.

									Pavel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Friday 24 April 2009, Pavel Machek wrote:
> Hi!
> 
> > >> @@ -392,6 +393,9 @@ static void suspend_finish(void)
> > >>
> > >>
> > >>  static const char * const pm_states[PM_SUSPEND_MAX] = {
> > >> +#ifdef CONFIG_SUSPEND_BLOCK
> > >> +     [PM_SUSPEND_ON]         = "on",
> > >> +#endif
> > >>       [PM_SUSPEND_STANDBY]    = "standby",
> > >>       [PM_SUSPEND_MEM]        = "mem",
> > >>  };
> > >
> > > This allows you to write "on" to the other interfaces where that makes
> > > no sense.... right?
> > 
> > state_store starts iterating at PM_SUSPEND_STANDBY, so don't think so.
> 
> Good.
> 
> 
> > >> +bool suspend_is_blocked(void)
> > >> +{
> > >> +     if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
> > >> +             return 0;
> > >> +     return !!atomic_read(&suspend_block_count);
> > >> +}
> > >
> > > Yes, if enable_suspend_blockers is one, we are in deep trouble.
> > 
> > It just means that you compiled suspend blocker support into the
> > kernel, but used an old interface to enter suspend. It warns if
> > enable_suspend_blockers is 0 not 1.
> 
> I do not think WARN_ONCE() should be that easy to trigger. WARN is
> very scary animal; better use normal printk?

Yes, printk() please.

> > >> +/**
> > >> + * suspend_blocker_init() - Initialize a suspend blocker
> > >> + * @blocker: The suspend blocker to initialize.
> > >> + * @name:    The name of the suspend blocker to show in
> > >> + *           /proc/suspend_blockers
> > >
> > > I don't think suspend_blockers should go to /proc. They are not process-related.
> > 
> > I moved that comment to the stats patch. It is still in procfs though,
> > as it is most similar to other procfs entries. It is not allowed under
> > the sysfs rules, and we do not want to enable debugfs on a production
> > system since it exposes some unsafe interfaces.
> 
> You have to sort this out somehow. It does not belong to /proc.

Agreed.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

On Wed, Apr 29, 2009 at 2:24 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday 24 April 2009, Pavel Machek wrote:
>> Hi!
>>
>> > >> @@ -392,6 +393,9 @@ static void suspend_finish(void)
>> > >>
>> > >>
>> > >>  static const char * const pm_states[PM_SUSPEND_MAX] = {
>> > >> +#ifdef CONFIG_SUSPEND_BLOCK
>> > >> +     [PM_SUSPEND_ON]         = "on",
>> > >> +#endif
>> > >>       [PM_SUSPEND_STANDBY]    = "standby",
>> > >>       [PM_SUSPEND_MEM]        = "mem",
>> > >>  };
>> > >
>> > > This allows you to write "on" to the other interfaces where that makes
>> > > no sense.... right?
>> >
>> > state_store starts iterating at PM_SUSPEND_STANDBY, so don't think so.
>>
>> Good.
>>
>>
>> > >> +bool suspend_is_blocked(void)
>> > >> +{
>> > >> +     if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
>> > >> +             return 0;
>> > >> +     return !!atomic_read(&suspend_block_count);
>> > >> +}
>> > >
>> > > Yes, if enable_suspend_blockers is one, we are in deep trouble.
>> >
>> > It just means that you compiled suspend blocker support into the
>> > kernel, but used an old interface to enter suspend. It warns if
>> > enable_suspend_blockers is 0 not 1.
>>
>> I do not think WARN_ONCE() should be that easy to trigger. WARN is
>> very scary animal; better use normal printk?
>
> Yes, printk() please.

Using printk instead of WARN_ONCE would be much more verbose, so I
removed it instead.

>
>> > >> +/**
>> > >> + * suspend_blocker_init() - Initialize a suspend blocker
>> > >> + * @blocker: The suspend blocker to initialize.
>> > >> + * @name:    The name of the suspend blocker to show in
>> > >> + *           /proc/suspend_blockers
>> > >
>> > > I don't think suspend_blockers should go to /proc. They are not process-related.
>> >
>> > I moved that comment to the stats patch. It is still in procfs though,
>> > as it is most similar to other procfs entries. It is not allowed under
>> > the sysfs rules, and we do not want to enable debugfs on a production
>> > system since it exposes some unsafe interfaces.
>>
>> You have to sort this out somehow. It does not belong to /proc.
>
> Agreed.

OK. I moved it to debugfs.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Wednesday 15 April 2009, Arve Hjønnevåg wrote:
> Adds /sys/power/request_state, a non-blocking interface that specifies
> which suspend state to enter when no suspend blockers are active. A
> special state, "on", stops the process by activating the "main" suspend
> blocker.

Finally I have some time to look at this more thoroughly, sorry for the long
delay.

I'll try not to repeate the others' comments, but I guess that may not be
totally avoidable.

> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  Documentation/power/suspend-blockers.txt |   76 +++++++++
>  include/linux/suspend_block.h            |   61 +++++++
>  kernel/power/Kconfig                     |   10 ++
>  kernel/power/Makefile                    |    1 +
>  kernel/power/main.c                      |   62 +++++++
>  kernel/power/power.h                     |    6 +
>  kernel/power/suspend_block.c             |  257 ++++++++++++++++++++++++++++++
>  7 files changed, 473 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/power/suspend-blockers.txt
>  create mode 100755 include/linux/suspend_block.h
>  create mode 100644 kernel/power/suspend_block.c
> 
> diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
> new file mode 100644
> index 0000000..743b870
> --- /dev/null
> +++ b/Documentation/power/suspend-blockers.txt
> @@ -0,0 +1,76 @@
> +Suspend blockers
> +================
> +
> +A suspend_blocker prevents the system from entering suspend.

I'd say "suspend blocker", without the underscore.

Also, I'd try to provide a general explanation of how this is supposed to
work here, as an introduction.  Something like:

"Suspend blockers provide a mechanism allowing device drivers and user
space processes to prevent the system from entering a sleep state, such as
the ACPI S3 state.

To use a suspend blocker, a device driver needs a struct suspend_blocker object
that has to be initialized with the help of suspend_blocker_init().  When no
longer needed, the suspend blocker must be garbage collected with the help
of suspend_blocker_destroy().

A suspend blocker is activated using suspend_block(), which prevents the
system from entering any sleep state until the suspend blocker is deactivated
with suspend_unblock().  Many suspend blockers may be used simultaneously
and the system is prevented from entering sleep states as long as at least one
of them is active."

BTW, I don't really like the names "suspend_block" and "suspend_unblock".
See below for possible alternatives.

> +If the suspend operation has already started when calling suspend_block on a
> +suspend_blocker, it will abort the suspend operation as long it has not already
> +reached the sysdev suspend stage. This means that calling suspend_block from an
> +interrupt handler or a freezeable thread always works, but if you call
> +block_suspend

Surely suspend_block() ?

> from a sysdev suspend handler you must also return an error from
> +that handler to abort suspend.

Well, if a sysdev suspend handler returns an error code, suspend will be
aborted anyway, so I'm not sure what the point in using suspend blockers from
sysdev suspend handlers really is.  Perhaps it's better to say "don't use
suspend blockers from withing sysdev suspend handlers"?

> +

I'd say "For example" here.

> +Suspend blockers 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 calls suspend_block on the
> +  keypad-scan suspend_blocker 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 calls
> +  suspend_block on the input-event-queue suspend_blocker.
> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
> +  on the keypad-scan suspend_blocker.
> +- The user-space input-event thread returns from select/poll, calls
> +  suspend_block on the process-input-events suspend_blocker and then calls read
> +  on the input-event device.
> +- The input-event driver dequeues the key-event and, since the queue is now
> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
> +- The user-space input-event thread returns from read. It determines that the
> +  key should not wake up the full system, calls suspend_unblock on the
> +  process-input-events suspend_blocker and calls select or poll.
> +
> +                 Key pressed   Key released
> +                     |             |
> +keypad-scan          ++++++++++++++++++
> +input-event-queue        +++          +++
> +process-input-events       +++          +++
> +
> +
> +Driver API
> +==========
> +
> +A driver can use the suspend block api by adding a suspend_blocker variable to
> +its state and calling suspend_blocker_init. For instance:
> +struct state {
> +	struct suspend_blocker suspend_blocker;
> +}
> +
> +init() {
> +	suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
> +}
> +
> +Before freeing the memory, suspend_blocker_destroy must be called:
> +
> +uninit() {
> +	suspend_blocker_destroy(&state->suspend_blocker);
> +}
> +
> +When the driver determines that it needs to run (usually in an interrupt
> +handler) it calls suspend_block:
> +	suspend_block(&state->suspend_blocker);

suspend_blocker_activate() ?
suspend_blocker_enable() ?
suspend_blocker_start() ?

> +
> +When it no longer needs to run it calls suspend_unblock:
> +	suspend_unblock(&state->suspend_blocker);

suspend_blocker_deactivate() ?
suspend_blocker_disable() ?
suspend_blocker_finish() ?

> +
> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
> +it is not active has no effect. This allows drivers to update their state and
> +call suspend suspend_block or suspend_unblock based on the result.
> +For instance:
> +
> +if (list_empty(&state->pending_work))
> +	suspend_unblock(&state->suspend_blocker);
> +else
> +	suspend_block(&state->suspend_blocker);
> +
> diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
> new file mode 100755
> index 0000000..7820c60
> --- /dev/null
> +++ b/include/linux/suspend_block.h

suspend_blockers.h perhaps?

> @@ -0,0 +1,61 @@
> +/* include/linux/suspend_block.h
> + *
> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCK_H
> +#define _LINUX_SUSPEND_BLOCK_H

SUSPEND_BLOCKERS_H ?

> +
> +/* A suspend_blocker prevents the system from entering suspend when active.
> + */
> +
> +struct suspend_blocker {
> +#ifdef CONFIG_SUSPEND_BLOCK

CONFIG_SUSPEND_BLOCKERS ?

> +	atomic_t            flags;
> +	const char         *name;
> +#endif
> +};
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
> +void suspend_block(struct suspend_blocker *blocker);
> +void suspend_unblock(struct suspend_blocker *blocker);
> +
> +/* is_blocking_suspend returns true if the suspend_blocker is currently active.
> + */
> +bool is_blocking_suspend(struct suspend_blocker *blocker);

suspend_blocker_is_active() ?
suspend_blocker_enabled() ?

> +
> +/* suspend_is_blocked can be used by generic power management code to abort
> + * suspend.
> + *
> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
> + * is called during suspend initiated from the suspend_block code.
> + */
> +bool suspend_is_blocked(void);
> +
> +#else
> +
> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
> +					const char *name) {}
> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
> +static inline void suspend_block(struct suspend_blocker *blocker) {}
> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
> +static inline bool is_blocking_suspend(struct suspend_blocker *bl) { return 0; }
> +static inline bool suspend_is_blocked(void) { return 0; }
> +
> +#endif
> +
> +#endif
> +
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 23bd4da..9d1df13 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -116,6 +116,16 @@ config SUSPEND_FREEZER
>  
>  	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
>  
> +config SUSPEND_BLOCK
> +	bool "Suspend block"
> +	depends on PM
> +	select RTC_LIB

depends on RTC_LIB

select doesn't really work and I don't think it ever will.

> +	default n
> +	---help---
> +	  Enable suspend_block.

Enable suspend blockers.

> When user space requests a sleep state through
> +	  /sys/power/request_state, the requested sleep state will be entered
> +	  when no suspend_blockers are active.

Well, if you don't want suspend blockers to block suspend started via
/sys/power/state, it's worth making it crystal clear in the documentation too.

> +
>  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 720ea4f..29cdc9e 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -6,6 +6,7 @@ endif
>  obj-$(CONFIG_PM)		+= main.o
>  obj-$(CONFIG_PM_SLEEP)		+= console.o
>  obj-$(CONFIG_FREEZER)		+= process.o
> +obj-$(CONFIG_SUSPEND_BLOCK)	+= suspend_block.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/main.c b/kernel/power/main.c
> index c9632f8..e4c6b20 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -22,6 +22,7 @@
>  #include <linux/freezer.h>
>  #include <linux/vmstat.h>
>  #include <linux/syscalls.h>
> +#include <linux/suspend_block.h>
>  
>  #include "power.h"
>  
> @@ -392,6 +393,9 @@ static void suspend_finish(void)
>  
>  
>  static const char * const pm_states[PM_SUSPEND_MAX] = {
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	[PM_SUSPEND_ON]		= "on",
> +#endif

Why #ifdef?

>  	[PM_SUSPEND_STANDBY]	= "standby",
>  	[PM_SUSPEND_MEM]	= "mem",
>  };
> @@ -540,6 +544,61 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>  
>  power_attr(state);
>  
> +/**
> + *	request_state - control system power state.
> + *
> + *	This is similar to state, but it does not block until the system
> + *	resumes, and it will try to re-enter the state until another state is
> + *	requested. Suspend blockers are respected and the requested state will
> + *	only be entered when no suspend blockers are active.
> + *	Write "on" to cancel.
> + */
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +static ssize_t request_state_show(struct kobject *kobj,
> +				  struct kobj_attribute *attr, char *buf)
> +{
> +	char *s = buf;
> +	int i;
> +
> +	for (i = 0; i < PM_SUSPEND_MAX; i++) {
> +		if (pm_states[i] && (i == PM_SUSPEND_ON || valid_state(i)))
> +			s += sprintf(s, "%s ", pm_states[i]);
> +	}
> +	if (s != buf)
> +		/* convert the last space to a newline */
> +		*(s-1) = '\n';
> +	return (s - buf);
> +}
> +
> +static ssize_t request_state_store(struct kobject *kobj,
> +				   struct kobj_attribute *attr,
> +				   const char *buf, size_t n)
> +{
> +	suspend_state_t state = PM_SUSPEND_ON;
> +	const char * const *s;
> +	char *p;
> +	int len;
> +	int error = -EINVAL;
> +
> +	p = memchr(buf, '\n', n);
> +	len = p ? p - buf : n;
> +
> +	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
> +		if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
> +			break;
> +	}
> +	if (state < PM_SUSPEND_MAX && *s)
> +		if (state == PM_SUSPEND_ON || valid_state(state)) {
> +			error = 0;
> +			request_suspend_state(state);
> +		}
> +	return error ? error : n;
> +}
> +
> +power_attr(request_state);
> +#endif /* CONFIG_SUSPEND_BLOCK */
> +
>  #ifdef CONFIG_PM_TRACE
>  int pm_trace_enabled;
>  
> @@ -567,6 +626,9 @@ power_attr(pm_trace);
>  
>  static struct attribute * g[] = {
>  	&state_attr.attr,
> +#ifdef CONFIG_SUSPEND_BLOCK
> +	&request_state_attr.attr,
> +#endif
>  #ifdef CONFIG_PM_TRACE
>  	&pm_trace_attr.attr,
>  #endif
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 46b5ec7..2414a74 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
>  {
>  }
>  #endif
> +
> +#ifdef CONFIG_SUSPEND_BLOCK
> +/* kernel/power/suspend_block.c */
> +void request_suspend_state(suspend_state_t state);
> +#endif

Is the #ifdef really necessary?

> +
> diff --git a/kernel/power/suspend_block.c b/kernel/power/suspend_block.c
> new file mode 100644
> index 0000000..b4f2191
> --- /dev/null
> +++ b/kernel/power/suspend_block.c
> @@ -0,0 +1,257 @@
> +/* kernel/power/suspend_block.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/rtc.h>
> +#include <linux/suspend.h>
> +#include <linux/suspend_block.h>
> +#include <linux/sysdev.h>
> +#include "power.h"
> +
> +enum {
> +	DEBUG_EXIT_SUSPEND = 1U << 0,
> +	DEBUG_WAKEUP = 1U << 1,
> +	DEBUG_USER_STATE = 1U << 2,
> +	DEBUG_SUSPEND = 1U << 3,
> +	DEBUG_SUSPEND_BLOCKER = 1U << 4,
> +};
> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
> +
> +#define SB_INITIALIZED            (1U << 8)
> +#define SB_ACTIVE                 (1U << 9)
> +
> +static DEFINE_SPINLOCK(state_lock);
> +static atomic_t suspend_block_count;
> +static atomic_t current_event_num;
> +struct workqueue_struct *suspend_work_queue;
> +struct suspend_blocker main_suspend_blocker;
> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
> +static bool enable_suspend_blockers;
> +
> +bool suspend_is_blocked(void)
> +{
> +	if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
> +		return 0;
> +	return !!atomic_read(&suspend_block_count);
> +}
> +
> +static void suspend_worker(struct work_struct *work)
> +{
> +	int ret;
> +	int entry_event_num;
> +
> +	enable_suspend_blockers = 1;

'true' instead of '1', please.

> +
> +retry:
> +	if (suspend_is_blocked()) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: abort suspend\n");
> +		goto abort;

If that were in a loop you could just use 'break' here.

> +	}
> +
> +	entry_event_num = atomic_read(&current_event_num);
> +	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 (atomic_read(&current_event_num) == entry_event_num) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("suspend: pm_suspend returned with no event\n");
> +		goto retry;

Put that into a loop and use 'continue' here?  Or use 'break' to go out of
the loop?

> +	}
> +abort:
> +	enable_suspend_blockers = 0;

'false' instead of '0', please.

> +}
> +static DECLARE_WORK(suspend_work, suspend_worker);
> +
> +static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
> +{
> +	int ret = suspend_is_blocked() ? -EAGAIN : 0;
> +	if (debug_mask & DEBUG_SUSPEND)
> +		pr_info("suspend_block_suspend return %d\n", ret);
> +	return ret;
> +}
> +
> +static struct sysdev_class suspend_block_sysclass = {
> +	.name = "suspend_block",
> +	.suspend = suspend_block_suspend,
> +};
> +static struct sys_device suspend_block_sysdev = {
> +	.cls = &suspend_block_sysclass,
> +};
> +

Hmm.  Perhaps add the suspend_is_blocked() check at the beginning of
sysdev_suspend() instead of this?  Surely you don't want to suspend
any sysdevs with any suspend blockers active, right?

> +/**
> + * suspend_blocker_init() - Initialize a suspend blocker
> + * @blocker:	The suspend blocker to initialize.
> + * @name:	The name of the suspend blocker to show in
> + *		/proc/suspend_blockers
> + */
> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
> +{
> +	if (name)
> +		blocker->name = name;
> +	BUG_ON(!blocker->name);

Do you really want to crash the kernel in this case?  WARN_ON() might be better IMO.

Also, this assumes that the caller won't release the memory used to store the
'name' string.  it might be a good idea to point that out in the kerneldoc
comment.

> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_init name=%s\n", blocker->name);
> +
> +	atomic_set(&blocker->flags, SB_INITIALIZED);
> +}
> +EXPORT_SYMBOL(suspend_blocker_init);
> +
> +/**
> + * suspend_blocker_destroy() - Destroy a suspend blocker
> + * @blocker:	The suspend blocker to destroy.
> + */
> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
> +{
> +	int flags;
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
> +	flags = atomic_xchg(&blocker->flags, 0);
> +	WARN(!(flags & SB_INITIALIZED), "suspend_blocker_destroy called on "
> +					"uninitialized suspend_blocker\n");
> +	if (flags == (SB_INITIALIZED | SB_ACTIVE))
> +		if (atomic_dec_and_test(&suspend_block_count))
> +			queue_work(suspend_work_queue, &suspend_work);
> +}
> +EXPORT_SYMBOL(suspend_blocker_destroy);
> +
> +/**
> + * suspend_block() - Block suspend
> + * @blocker:	The suspend blocker to use
> + */
> +void suspend_block(struct suspend_blocker *blocker)
> +{
> +	BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));

WARN_ON() and exit instead?  BUG_ON() is a bit drastic IMHO.

> +
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_block: %s\n", blocker->name);
> +	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED,
> +	    SB_INITIALIZED | SB_ACTIVE) == SB_INITIALIZED)
> +		atomic_inc(&suspend_block_count);
> +
> +	atomic_inc(&current_event_num);
> +}
> +EXPORT_SYMBOL(suspend_block);
> +
> +/**
> + * suspend_unblock() - Unblock suspend
> + * @blocker:	The suspend blocker to unblock.
> + *
> + * If no other suspend blockers block suspend, the system will suspend.
> + */
> +void suspend_unblock(struct suspend_blocker *blocker)
> +{
> +	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
> +		pr_info("suspend_unblock: %s\n", blocker->name);
> +
> +	if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
> +	    SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
> +		if (atomic_dec_and_test(&suspend_block_count))
> +			queue_work(suspend_work_queue, &suspend_work);
> +}
> +EXPORT_SYMBOL(suspend_unblock);
> +
> +/**
> + * is_blocking_suspend() - Test if a suspend blocker is blocking suspend
> + * @blocker:	The suspend blocker to check.
> + */
> +bool is_blocking_suspend(struct suspend_blocker *blocker)
> +{
> +	return !!(atomic_read(&blocker->flags) & SB_ACTIVE);

Check SB_INITIALIZED too, perhaps?  WARN_ON(!SB_INITIALIZED)?

> +}
> +EXPORT_SYMBOL(is_blocking_suspend);
> +
> +void request_suspend_state(suspend_state_t state)
> +{
> +	unsigned long irqflags;
> +	spin_lock_irqsave(&state_lock, irqflags);
> +	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",
> +			state != PM_SUSPEND_ON ? "sleep" : "wakeup",
> +			requested_suspend_state, 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);
> +	}
> +	requested_suspend_state = state;
> +	if (state == PM_SUSPEND_ON)
> +		suspend_block(&main_suspend_blocker);
> +	else
> +		suspend_unblock(&main_suspend_blocker);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +}
> +
> +static int __init suspend_block_init(void)
> +{
> +	int ret;
> +
> +	suspend_blocker_init(&main_suspend_blocker, "main");
> +	suspend_block(&main_suspend_blocker);
> +
> +	ret = sysdev_class_register(&suspend_block_sysclass);
> +	if (ret) {
> +		pr_err("suspend_block_init: sysdev_class_register failed\n");
> +		goto err_sysdev_class_register;
> +	}
> +	ret = sysdev_register(&suspend_block_sysdev);
> +	if (ret) {
> +		pr_err("suspend_block_init: suspend_block_sysdev failed\n");
> +		goto err_sysdev_register;
> +	}
> +
> +	suspend_work_queue = create_singlethread_workqueue("suspend");

Do we need a separate workqueue for this purpose?

> +	if (suspend_work_queue == NULL) {
> +		ret = -ENOMEM;
> +		goto err_suspend_work_queue;
> +	}
> +
> +	return 0;
> +
> +err_suspend_work_queue:
> +	sysdev_unregister(&suspend_block_sysdev);
> +err_sysdev_register:
> +	sysdev_class_unregister(&suspend_block_sysclass);
> +err_sysdev_class_register:
> +	suspend_blocker_destroy(&main_suspend_blocker);
> +	return ret;
> +}
> +
> +static void  __exit suspend_block_exit(void)
> +{
> +	destroy_workqueue(suspend_work_queue);
> +	sysdev_unregister(&suspend_block_sysdev);
> +	sysdev_class_unregister(&suspend_block_sysclass);
> +	suspend_blocker_destroy(&main_suspend_blocker);
> +}
> +
> +core_initcall(suspend_block_init);
> +module_exit(suspend_block_exit);

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2009/4/29 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 15 April 2009, Arve Hjønnevåg wrote:
>> diff --git a/Documentation/power/suspend-blockers.txt b/Documentation/power/suspend-blockers.txt
>> new file mode 100644
>> index 0000000..743b870
>> --- /dev/null
>> +++ b/Documentation/power/suspend-blockers.txt
>> @@ -0,0 +1,76 @@
>> +Suspend blockers
>> +================
>> +
>> +A suspend_blocker prevents the system from entering suspend.
>
> I'd say "suspend blocker", without the underscore.
>
> Also, I'd try to provide a general explanation of how this is supposed to
> work here, as an introduction.  Something like:
>
> "Suspend blockers provide a mechanism allowing device drivers and user
> space processes to prevent the system from entering a sleep state, such as
> the ACPI S3 state.
>
> To use a suspend blocker, a device driver needs a struct suspend_blocker object
> that has to be initialized with the help of suspend_blocker_init().  When no
> longer needed, the suspend blocker must be garbage collected with the help
> of suspend_blocker_destroy().
>
> A suspend blocker is activated using suspend_block(), which prevents the
> system from entering any sleep state until the suspend blocker is deactivated
> with suspend_unblock().  Many suspend blockers may be used simultaneously
> and the system is prevented from entering sleep states as long as at least one
> of them is active."
>

I added most of this, see new text below.

> BTW, I don't really like the names "suspend_block" and "suspend_unblock".
> See below for possible alternatives.
>
>> +If the suspend operation has already started when calling suspend_block on a
>> +suspend_blocker, it will abort the suspend operation as long it has not already
>> +reached the sysdev suspend stage. This means that calling suspend_block from an
>> +interrupt handler or a freezeable thread always works, but if you call
>> +block_suspend
>
> Surely suspend_block() ?

Yes.

>
>> from a sysdev suspend handler you must also return an error from
>> +that handler to abort suspend.
>
> Well, if a sysdev suspend handler returns an error code, suspend will be
> aborted anyway, so I'm not sure what the point in using suspend blockers from
> sysdev suspend handlers really is.  Perhaps it's better to say "don't use
> suspend blockers from withing sysdev suspend handlers"?

You still need the suspend blocker to prevent the system from trying
to enter suspend again. I changed the text to "to abort a suspend
sequence that was already started".

>
>> +
>
> I'd say "For example" here.
>
>> +Suspend blockers 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 calls suspend_block on the
>> +  keypad-scan suspend_blocker 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 calls
>> +  suspend_block on the input-event-queue suspend_blocker.
>> +- The keypad-scan code detects that no keys are held and calls suspend_unblock
>> +  on the keypad-scan suspend_blocker.
>> +- The user-space input-event thread returns from select/poll, calls
>> +  suspend_block on the process-input-events suspend_blocker and then calls read
>> +  on the input-event device.
>> +- The input-event driver dequeues the key-event and, since the queue is now
>> +  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
>> +- The user-space input-event thread returns from read. It determines that the
>> +  key should not wake up the full system, calls suspend_unblock on the
>> +  process-input-events suspend_blocker and calls select or poll.
>> +
>> +                 Key pressed   Key released
>> +                     |             |
>> +keypad-scan          ++++++++++++++++++
>> +input-event-queue        +++          +++
>> +process-input-events       +++          +++
>> +
>> +
>> +Driver API
>> +==========
>> +
>> +A driver can use the suspend block api by adding a suspend_blocker variable to
>> +its state and calling suspend_blocker_init. For instance:
>> +struct state {
>> +     struct suspend_blocker suspend_blocker;
>> +}
>> +
>> +init() {
>> +     suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
>> +}
>> +
>> +Before freeing the memory, suspend_blocker_destroy must be called:
>> +
>> +uninit() {
>> +     suspend_blocker_destroy(&state->suspend_blocker);
>> +}
>> +
>> +When the driver determines that it needs to run (usually in an interrupt
>> +handler) it calls suspend_block:
>> +     suspend_block(&state->suspend_blocker);
>
> suspend_blocker_activate() ?
> suspend_blocker_enable() ?
> suspend_blocker_start() ?
>

I don't like any of those better than suspend_block, but if there is
some agreement on what it should be changed to, I'll change it.

>> +
>> +When it no longer needs to run it calls suspend_unblock:
>> +     suspend_unblock(&state->suspend_blocker);
>
> suspend_blocker_deactivate() ?
> suspend_blocker_disable() ?
> suspend_blocker_finish() ?
>
>> +
>> +Calling suspend_block when the suspend blocker is active or suspend_unblock when
>> +it is not active has no effect. This allows drivers to update their state and
>> +call suspend suspend_block or suspend_unblock based on the result.
>> +For instance:
>> +
>> +if (list_empty(&state->pending_work))
>> +     suspend_unblock(&state->suspend_blocker);
>> +else
>> +     suspend_block(&state->suspend_blocker);
>> +


-- 
Arve Hjønnevåg


----

Suspend blockers
================

Suspend blockers provide a mechanism for device drivers and user-space processes
to prevent the system from entering suspend. Only suspend states requested
through /sys/power/request_state are prevented. Writing to /sys/power/state
will ignore suspend blockers, and sleep states entered from idle are unaffected.

To use a suspend blocker, a device driver needs a struct suspend_blocker object
that has to be initialized with suspend_blocker_init. When no longer needed,
the suspend blocker must be destroyed with suspend_blocker_destroy.

A suspend blocker is activated using suspend_block, which prevents the system
from entering suspend until the suspend blocker is deactivated with
suspend_unblock. Many suspend blockers may be used simultaneously, and the
system is prevented from entering suspend as long as at least one of them is
active.

If the suspend operation has already started when calling suspend_block on a
suspend_blocker, it will abort the suspend operation as long it has not already
reached the sysdev suspend stage. This means that calling suspend_block from an
interrupt handler or a freezeable thread always works, but if you call
suspend_block from a sysdev suspend handler you must also return an error from
that handler to abort a suspend sequence that was already started.

In cell phones or other embedded systems where powering the screen is a
significant drain on the battery, suspend blockers can be used to allow
user-space to decide whether a keystroke received while the system is suspended
should cause the screen to be turned back on or allow the system to go back into
suspend. 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 calls suspend_block on the
  keypad-scan suspend_blocker 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 calls
  suspend_block on the input-event-queue suspend_blocker.
- The keypad-scan code detects that no keys are held and calls suspend_unblock
  on the keypad-scan suspend_blocker.
- The user-space input-event thread returns from select/poll, calls
  suspend_block on the process-input-events suspend_blocker and then calls read
  on the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now
  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
- The user-space input-event thread returns from read. If it determines that
  the key should leave the screen off, it calls suspend_unblock on the
  process_input_events suspend_blocker and then calls select or poll. The
  system will automatically suspend again, since now no suspend blockers are
  active.

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


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

A driver can use the suspend block api by adding a suspend_blocker variable to
its state and calling suspend_blocker_init. For instance:
struct state {
        struct suspend_blocker suspend_blocker;
}

init() {
        suspend_blocker_init(&state->suspend_blocker, "suspend-blocker-name");
}

Before freeing the memory, suspend_blocker_destroy must be called:

uninit() {
        suspend_blocker_destroy(&state->suspend_blocker);
}

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

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

Calling suspend_block when the suspend blocker is active or suspend_unblock when
it is not active has no effect. This allows drivers to update their state and
call suspend suspend_block or suspend_unblock based on the result.
For instance:

if (list_empty(&state->pending_work))
        suspend_unblock(&state->suspend_blocker);
else
        suspend_block(&state->suspend_blocker);

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2009/4/29 Rafael J. Wysocki <rjw@sisk.pl>:
> On Wednesday 15 April 2009, Arve Hjønnevåg wrote:
>> diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
>> new file mode 100755
>> index 0000000..7820c60
>> --- /dev/null
>> +++ b/include/linux/suspend_block.h
>
> suspend_blockers.h perhaps?

suspend_blocker.h?

>
>> @@ -0,0 +1,61 @@
>> +/* include/linux/suspend_block.h
>> + *
>> + * Copyright (C) 2007-2009 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_SUSPEND_BLOCK_H
>> +#define _LINUX_SUSPEND_BLOCK_H
>
> SUSPEND_BLOCKERS_H ?
>
>> +
>> +/* A suspend_blocker prevents the system from entering suspend when active.
>> + */
>> +
>> +struct suspend_blocker {
>> +#ifdef CONFIG_SUSPEND_BLOCK
>
> CONFIG_SUSPEND_BLOCKERS ?

OK.

>
>> +     atomic_t            flags;
>> +     const char         *name;
>> +#endif
>> +};
>> +
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +
>> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
>> +void suspend_blocker_destroy(struct suspend_blocker *blocker);
>> +void suspend_block(struct suspend_blocker *blocker);
>> +void suspend_unblock(struct suspend_blocker *blocker);
>> +
>> +/* is_blocking_suspend returns true if the suspend_blocker is currently active.
>> + */
>> +bool is_blocking_suspend(struct suspend_blocker *blocker);
>
> suspend_blocker_is_active() ?
OK.
> suspend_blocker_enabled() ?
>
>> +
>> +/* suspend_is_blocked can be used by generic power management code to abort
>> + * suspend.
>> + *
>> + * To preserve backward compatibility suspend_is_blocked returns 0 unless it
>> + * is called during suspend initiated from the suspend_block code.
>> + */
>> +bool suspend_is_blocked(void);
>> +
>> +#else
>> +
>> +static inline void suspend_blocker_init(struct suspend_blocker *blocker,
>> +                                     const char *name) {}
>> +static inline void suspend_blocker_destroy(struct suspend_blocker *blocker) {}
>> +static inline void suspend_block(struct suspend_blocker *blocker) {}
>> +static inline void suspend_unblock(struct suspend_blocker *blocker) {}
>> +static inline bool is_blocking_suspend(struct suspend_blocker *bl) { return 0; }
>> +static inline bool suspend_is_blocked(void) { return 0; }
>> +
>> +#endif
>> +
>> +#endif
>> +
>> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
>> index 23bd4da..9d1df13 100644
>> --- a/kernel/power/Kconfig
>> +++ b/kernel/power/Kconfig
>> @@ -116,6 +116,16 @@ config SUSPEND_FREEZER
>>
>>         Turning OFF this setting is NOT recommended! If in doubt, say Y.
>>
>> +config SUSPEND_BLOCK
>> +     bool "Suspend block"
>> +     depends on PM
>> +     select RTC_LIB
>
> depends on RTC_LIB
>
> select doesn't really work and I don't think it ever will.

Nothing depends on RTC_LIB, it is only selected.

>
>> +     default n
>> +     ---help---
>> +       Enable suspend_block.
>
> Enable suspend blockers.

OK.

>
>> When user space requests a sleep state through
>> +       /sys/power/request_state, the requested sleep state will be entered
>> +       when no suspend_blockers are active.
>
> Well, if you don't want suspend blockers to block suspend started via
> /sys/power/state, it's worth making it crystal clear in the documentation too.

I added this to the intro.

>
>> +
>>  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 720ea4f..29cdc9e 100644
>> --- a/kernel/power/Makefile
>> +++ b/kernel/power/Makefile
>> @@ -6,6 +6,7 @@ endif
>>  obj-$(CONFIG_PM)             += main.o
>>  obj-$(CONFIG_PM_SLEEP)               += console.o
>>  obj-$(CONFIG_FREEZER)                += process.o
>> +obj-$(CONFIG_SUSPEND_BLOCK)  += suspend_block.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/main.c b/kernel/power/main.c
>> index c9632f8..e4c6b20 100644
>> --- a/kernel/power/main.c
>> +++ b/kernel/power/main.c
>> @@ -22,6 +22,7 @@
>>  #include <linux/freezer.h>
>>  #include <linux/vmstat.h>
>>  #include <linux/syscalls.h>
>> +#include <linux/suspend_block.h>
>>
>>  #include "power.h"
>>
>> @@ -392,6 +393,9 @@ static void suspend_finish(void)
>>
>>
>>  static const char * const pm_states[PM_SUSPEND_MAX] = {
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +     [PM_SUSPEND_ON]         = "on",
>> +#endif
>
> Why #ifdef?

Removed.

>
>>       [PM_SUSPEND_STANDBY]    = "standby",
>>       [PM_SUSPEND_MEM]        = "mem",
>>  };
>> @@ -540,6 +544,61 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
>>
>>  power_attr(state);
>>
>> +/**
>> + *   request_state - control system power state.
>> + *
>> + *   This is similar to state, but it does not block until the system
>> + *   resumes, and it will try to re-enter the state until another state is
>> + *   requested. Suspend blockers are respected and the requested state will
>> + *   only be entered when no suspend blockers are active.
>> + *   Write "on" to cancel.
>> + */
>> +
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +static ssize_t request_state_show(struct kobject *kobj,
>> +                               struct kobj_attribute *attr, char *buf)
>> +{
>> +     char *s = buf;
>> +     int i;
>> +
>> +     for (i = 0; i < PM_SUSPEND_MAX; i++) {
>> +             if (pm_states[i] && (i == PM_SUSPEND_ON || valid_state(i)))
>> +                     s += sprintf(s, "%s ", pm_states[i]);
>> +     }
>> +     if (s != buf)
>> +             /* convert the last space to a newline */
>> +             *(s-1) = '\n';
>> +     return (s - buf);
>> +}
>> +
>> +static ssize_t request_state_store(struct kobject *kobj,
>> +                                struct kobj_attribute *attr,
>> +                                const char *buf, size_t n)
>> +{
>> +     suspend_state_t state = PM_SUSPEND_ON;
>> +     const char * const *s;
>> +     char *p;
>> +     int len;
>> +     int error = -EINVAL;
>> +
>> +     p = memchr(buf, '\n', n);
>> +     len = p ? p - buf : n;
>> +
>> +     for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
>> +             if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
>> +                     break;
>> +     }
>> +     if (state < PM_SUSPEND_MAX && *s)
>> +             if (state == PM_SUSPEND_ON || valid_state(state)) {
>> +                     error = 0;
>> +                     request_suspend_state(state);
>> +             }
>> +     return error ? error : n;
>> +}
>> +
>> +power_attr(request_state);
>> +#endif /* CONFIG_SUSPEND_BLOCK */
>> +
>>  #ifdef CONFIG_PM_TRACE
>>  int pm_trace_enabled;
>>
>> @@ -567,6 +626,9 @@ power_attr(pm_trace);
>>
>>  static struct attribute * g[] = {
>>       &state_attr.attr,
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +     &request_state_attr.attr,
>> +#endif
>>  #ifdef CONFIG_PM_TRACE
>>       &pm_trace_attr.attr,
>>  #endif
>> diff --git a/kernel/power/power.h b/kernel/power/power.h
>> index 46b5ec7..2414a74 100644
>> --- a/kernel/power/power.h
>> +++ b/kernel/power/power.h
>> @@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
>>  {
>>  }
>>  #endif
>> +
>> +#ifdef CONFIG_SUSPEND_BLOCK
>> +/* kernel/power/suspend_block.c */
>> +void request_suspend_state(suspend_state_t state);
>> +#endif
>
> Is the #ifdef really necessary?
>

No, but it gives a compile error instead of a link error if you call
request_suspend_state when it is not available so it is useful.

>> +
>> diff --git a/kernel/power/suspend_block.c b/kernel/power/suspend_block.c
>> new file mode 100644
>> index 0000000..b4f2191
>> --- /dev/null
>> +++ b/kernel/power/suspend_block.c
>> @@ -0,0 +1,257 @@
>> +/* kernel/power/suspend_block.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/rtc.h>
>> +#include <linux/suspend.h>
>> +#include <linux/suspend_block.h>
>> +#include <linux/sysdev.h>
>> +#include "power.h"
>> +
>> +enum {
>> +     DEBUG_EXIT_SUSPEND = 1U << 0,
>> +     DEBUG_WAKEUP = 1U << 1,
>> +     DEBUG_USER_STATE = 1U << 2,
>> +     DEBUG_SUSPEND = 1U << 3,
>> +     DEBUG_SUSPEND_BLOCKER = 1U << 4,
>> +};
>> +static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
>> +module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
>> +
>> +#define SB_INITIALIZED            (1U << 8)
>> +#define SB_ACTIVE                 (1U << 9)
>> +
>> +static DEFINE_SPINLOCK(state_lock);
>> +static atomic_t suspend_block_count;
>> +static atomic_t current_event_num;
>> +struct workqueue_struct *suspend_work_queue;
>> +struct suspend_blocker main_suspend_blocker;
>> +static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
>> +static bool enable_suspend_blockers;
>> +
>> +bool suspend_is_blocked(void)
>> +{
>> +     if (WARN_ONCE(!enable_suspend_blockers, "ignoring suspend blockers\n"))
>> +             return 0;
>> +     return !!atomic_read(&suspend_block_count);
>> +}
>> +
>> +static void suspend_worker(struct work_struct *work)
>> +{
>> +     int ret;
>> +     int entry_event_num;
>> +
>> +     enable_suspend_blockers = 1;
>
> 'true' instead of '1', please.

OK.

>
>> +
>> +retry:
>> +     if (suspend_is_blocked()) {
>> +             if (debug_mask & DEBUG_SUSPEND)
>> +                     pr_info("suspend: abort suspend\n");
>> +             goto abort;
>
> If that were in a loop you could just use 'break' here.

do you think this is better:
while(1) {
        if (exception1) {
                ...
                break;
        }
        ...
        if (exception2) {
                ...
                continue;
        }
        break;
}
>
>> +     }
>> +
>> +     entry_event_num = atomic_read(&current_event_num);
>> +     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 (atomic_read(&current_event_num) == entry_event_num) {
>> +             if (debug_mask & DEBUG_SUSPEND)
>> +                     pr_info("suspend: pm_suspend returned with no event\n");
>> +             goto retry;
>
> Put that into a loop and use 'continue' here?  Or use 'break' to go out of
> the loop?

The retry is a workaround for the lack of suspend_block_timeout.

>
>> +     }
>> +abort:
>> +     enable_suspend_blockers = 0;
>
> 'false' instead of '0', please.

OK.

>
>> +}
>> +static DECLARE_WORK(suspend_work, suspend_worker);
>> +
>> +static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
>> +{
>> +     int ret = suspend_is_blocked() ? -EAGAIN : 0;
>> +     if (debug_mask & DEBUG_SUSPEND)
>> +             pr_info("suspend_block_suspend return %d\n", ret);
>> +     return ret;
>> +}
>> +
>> +static struct sysdev_class suspend_block_sysclass = {
>> +     .name = "suspend_block",
>> +     .suspend = suspend_block_suspend,
>> +};
>> +static struct sys_device suspend_block_sysdev = {
>> +     .cls = &suspend_block_sysclass,
>> +};
>> +
>
> Hmm.  Perhaps add the suspend_is_blocked() check at the beginning of
> sysdev_suspend() instead of this?  Surely you don't want to suspend
> any sysdevs with any suspend blockers active, right?

You could make the same argument for any device. Using a sysdev makes
the patch easier to apply.

>
>> +/**
>> + * suspend_blocker_init() - Initialize a suspend blocker
>> + * @blocker: The suspend blocker to initialize.
>> + * @name:    The name of the suspend blocker to show in
>> + *           /proc/suspend_blockers
>> + */
>> +void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
>> +{
>> +     if (name)
>> +             blocker->name = name;
>> +     BUG_ON(!blocker->name);
>
> Do you really want to crash the kernel in this case?  WARN_ON() might be better IMO.

OK.

>
> Also, this assumes that the caller won't release the memory used to store the
> 'name' string.  it might be a good idea to point that out in the kerneldoc
> comment.
>
>> +
>> +     if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> +             pr_info("suspend_blocker_init name=%s\n", blocker->name);
>> +
>> +     atomic_set(&blocker->flags, SB_INITIALIZED);
>> +}
>> +EXPORT_SYMBOL(suspend_blocker_init);
>> +
>> +/**
>> + * suspend_blocker_destroy() - Destroy a suspend blocker
>> + * @blocker: The suspend blocker to destroy.
>> + */
>> +void suspend_blocker_destroy(struct suspend_blocker *blocker)
>> +{
>> +     int flags;
>> +     if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> +             pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
>> +     flags = atomic_xchg(&blocker->flags, 0);
>> +     WARN(!(flags & SB_INITIALIZED), "suspend_blocker_destroy called on "
>> +                                     "uninitialized suspend_blocker\n");
>> +     if (flags == (SB_INITIALIZED | SB_ACTIVE))
>> +             if (atomic_dec_and_test(&suspend_block_count))
>> +                     queue_work(suspend_work_queue, &suspend_work);
>> +}
>> +EXPORT_SYMBOL(suspend_blocker_destroy);
>> +
>> +/**
>> + * suspend_block() - Block suspend
>> + * @blocker: The suspend blocker to use
>> + */
>> +void suspend_block(struct suspend_blocker *blocker)
>> +{
>> +     BUG_ON(!(atomic_read(&blocker->flags) & SB_INITIALIZED));
>
> WARN_ON() and exit instead?  BUG_ON() is a bit drastic IMHO.
>
>> +
>> +     if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> +             pr_info("suspend_block: %s\n", blocker->name);
>> +     if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED,
>> +         SB_INITIALIZED | SB_ACTIVE) == SB_INITIALIZED)
>> +             atomic_inc(&suspend_block_count);
>> +
>> +     atomic_inc(&current_event_num);
>> +}
>> +EXPORT_SYMBOL(suspend_block);
>> +
>> +/**
>> + * suspend_unblock() - Unblock suspend
>> + * @blocker: The suspend blocker to unblock.
>> + *
>> + * If no other suspend blockers block suspend, the system will suspend.
>> + */
>> +void suspend_unblock(struct suspend_blocker *blocker)
>> +{
>> +     if (debug_mask & DEBUG_SUSPEND_BLOCKER)
>> +             pr_info("suspend_unblock: %s\n", blocker->name);
>> +
>> +     if (atomic_cmpxchg(&blocker->flags, SB_INITIALIZED | SB_ACTIVE,
>> +         SB_INITIALIZED) == (SB_INITIALIZED | SB_ACTIVE))
>> +             if (atomic_dec_and_test(&suspend_block_count))
>> +                     queue_work(suspend_work_queue, &suspend_work);
>> +}
>> +EXPORT_SYMBOL(suspend_unblock);
>> +
>> +/**
>> + * is_blocking_suspend() - Test if a suspend blocker is blocking suspend
>> + * @blocker: The suspend blocker to check.
>> + */
>> +bool is_blocking_suspend(struct suspend_blocker *blocker)
>> +{
>> +     return !!(atomic_read(&blocker->flags) & SB_ACTIVE);
>
> Check SB_INITIALIZED too, perhaps?  WARN_ON(!SB_INITIALIZED)?

Added WARN_ON.

>
>> +}
>> +EXPORT_SYMBOL(is_blocking_suspend);
>> +
>> +void request_suspend_state(suspend_state_t state)
>> +{
>> +     unsigned long irqflags;
>> +     spin_lock_irqsave(&state_lock, irqflags);
>> +     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",
>> +                     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
>> +                     requested_suspend_state, 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);
>> +     }
>> +     requested_suspend_state = state;
>> +     if (state == PM_SUSPEND_ON)
>> +             suspend_block(&main_suspend_blocker);
>> +     else
>> +             suspend_unblock(&main_suspend_blocker);
>> +     spin_unlock_irqrestore(&state_lock, irqflags);
>> +}
>> +
>> +static int __init suspend_block_init(void)
>> +{
>> +     int ret;
>> +
>> +     suspend_blocker_init(&main_suspend_blocker, "main");
>> +     suspend_block(&main_suspend_blocker);
>> +
>> +     ret = sysdev_class_register(&suspend_block_sysclass);
>> +     if (ret) {
>> +             pr_err("suspend_block_init: sysdev_class_register failed\n");
>> +             goto err_sysdev_class_register;
>> +     }
>> +     ret = sysdev_register(&suspend_block_sysdev);
>> +     if (ret) {
>> +             pr_err("suspend_block_init: suspend_block_sysdev failed\n");
>> +             goto err_sysdev_register;
>> +     }
>> +
>> +     suspend_work_queue = create_singlethread_workqueue("suspend");
>
> Do we need a separate workqueue for this purpose?
>

Yes. Some drivers wait on work that runs on the main workqueue in
their suspend handler.

>> +     if (suspend_work_queue == NULL) {
>> +             ret = -ENOMEM;
>> +             goto err_suspend_work_queue;
>> +     }
>> +
>> +     return 0;
>> +
>> +err_suspend_work_queue:
>> +     sysdev_unregister(&suspend_block_sysdev);
>> +err_sysdev_register:
>> +     sysdev_class_unregister(&suspend_block_sysclass);
>> +err_sysdev_class_register:
>> +     suspend_blocker_destroy(&main_suspend_blocker);
>> +     return ret;
>> +}
>> +
>> +static void  __exit suspend_block_exit(void)
>> +{
>> +     destroy_workqueue(suspend_work_queue);
>> +     sysdev_unregister(&suspend_block_sysdev);
>> +     sysdev_class_unregister(&suspend_block_sysclass);
>> +     suspend_blocker_destroy(&main_suspend_blocker);
>> +}
>> +
>> +core_initcall(suspend_block_init);
>> +module_exit(suspend_block_exit);
>
> Thanks,
> Rafael
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> >> --- a/kernel/power/power.h
> >> +++ b/kernel/power/power.h
> >> @@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
> >>  {
> >>  }
> >>  #endif
> >> +
> >> +#ifdef CONFIG_SUSPEND_BLOCK
> >> +/* kernel/power/suspend_block.c */
> >> +void request_suspend_state(suspend_state_t state);
> >> +#endif
> >
> > Is the #ifdef really necessary?
> >
> 
> No, but it gives a compile error instead of a link error if you call
> request_suspend_state when it is not available so it is useful.

I believe #ifdef is too ugly and link error is really good enough.

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Sunday 26 April 2009, Pavel Machek wrote:
> Hi!
> 
> > >> --- a/kernel/power/power.h
> > >> +++ b/kernel/power/power.h
> > >> @@ -223,3 +223,9 @@ static inline void suspend_thaw_processes(void)
> > >>  {
> > >>  }
> > >>  #endif
> > >> +
> > >> +#ifdef CONFIG_SUSPEND_BLOCK
> > >> +/* kernel/power/suspend_block.c */
> > >> +void request_suspend_state(suspend_state_t state);
> > >> +#endif
> > >
> > > Is the #ifdef really necessary?
> > >
> > 
> > No, but it gives a compile error instead of a link error if you call
> > request_suspend_state when it is not available so it is useful.
> 
> I believe #ifdef is too ugly and link error is really good enough.

Well, I agree with this FWIW.

We don't ususally use #ifdefs around function headers, unless they are defined
conditionally.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Rafael J. Wysocki]

On Thursday 30 April 2009, Arve Hjønnevåg wrote:
> 2009/4/29 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Wednesday 15 April 2009, Arve Hjønnevåg wrote:
> >> diff --git a/include/linux/suspend_block.h b/include/linux/suspend_block.h
> >> new file mode 100755
> >> index 0000000..7820c60
> >> --- /dev/null
> >> +++ b/include/linux/suspend_block.h
> >
> > suspend_blockers.h perhaps?
> 
> suspend_blocker.h?

Fine by me.

[--snip--]
> >> +config SUSPEND_BLOCK
> >> +     bool "Suspend block"
> >> +     depends on PM
> >> +     select RTC_LIB
> >
> > depends on RTC_LIB
> >
> > select doesn't really work and I don't think it ever will.
> 
> Nothing depends on RTC_LIB, it is only selected.

If nothing in your code needs anything depending on RTC_LIB, why select it?

[--snip--]
> >
> >> +
> >> +retry:
> >> +     if (suspend_is_blocked()) {
> >> +             if (debug_mask & DEBUG_SUSPEND)
> >> +                     pr_info("suspend: abort suspend\n");
> >> +             goto abort;
> >
> > If that were in a loop you could just use 'break' here.
> 
> do you think this is better:
> while(1) {
>         if (exception1) {
>                 ...
>                 break;
>         }
>         ...
>         if (exception2) {
>                 ...
>                 continue;
>         }
>         break;
> }

I rather thought of

for (;;) {
         if (exception1) {
                 ...
                 break;
         }
         ...
         if (!exception2)
                 break;
         ...
}

[--snip--]
> >> +static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
> >> +{
> >> +     int ret = suspend_is_blocked() ? -EAGAIN : 0;
> >> +     if (debug_mask & DEBUG_SUSPEND)
> >> +             pr_info("suspend_block_suspend return %d\n", ret);
> >> +     return ret;
> >> +}
> >> +
> >> +static struct sysdev_class suspend_block_sysclass = {
> >> +     .name = "suspend_block",
> >> +     .suspend = suspend_block_suspend,
> >> +};
> >> +static struct sys_device suspend_block_sysdev = {
> >> +     .cls = &suspend_block_sysclass,
> >> +};
> >> +
> >
> > Hmm.  Perhaps add the suspend_is_blocked() check at the beginning of
> > sysdev_suspend() instead of this?  Surely you don't want to suspend
> > any sysdevs with any suspend blockers active, right?
> 
> You could make the same argument for any device. Using a sysdev makes
> the patch easier to apply.

You've lost me here. :-)

AFAICT, the only purpose of the sysdev class above is to abort suspend if
suspend_is_blocked() returns 'true'.  If that is correct, then IMO you could
achieve the same goal by calling suspend_is_blocked() directly from
sysdev_suspend(), right before check_wakeup_irqs().  Or am I missing anything?

Thanks,
Rafael

Re: [PATCH 1/8] PM: Add suspend block api.

[Pavel Machek]

Hi!

> > >> +config SUSPEND_BLOCK
> > >> +     bool "Suspend block"
> > >> +     depends on PM
> > >> +     select RTC_LIB
> > >
> > > depends on RTC_LIB
> > >
> > > select doesn't really work and I don't think it ever will.
> > 
> > Nothing depends on RTC_LIB, it is only selected.
> 
> If nothing in your code needs anything depending on RTC_LIB, why select it?

He wants to say nothing in _kernel proper_ depends on RTC_LIB:

pavel@amd:/data/l/linux-good$ grep 'select RTC_LIB' `find . -name
"Kconfig"`
./arch/arm/Kconfig:	select RTC_LIB
./arch/mips/Kconfig:	select RTC_LIB
./drivers/rtc/Kconfig:	select RTC_LIB
pavel@amd:/data/l/linux-good$ grep 'depends.*RTC_LIB' `find . -name
"Kconfig"`
pavel@amd:/data/l/linux-good$ 

RTC_LIB seems to be designed for select.
									Pavel

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

Re: [PATCH 1/8] PM: Add suspend block api.

[Arve Hjønnevåg]

2009/5/2 Rafael J. Wysocki <rjw@sisk.pl>:
> [--snip--]
>> >
>> >> +
>> >> +retry:
>> >> +     if (suspend_is_blocked()) {
>> >> +             if (debug_mask & DEBUG_SUSPEND)
>> >> +                     pr_info("suspend: abort suspend\n");
>> >> +             goto abort;
>> >
>> > If that were in a loop you could just use 'break' here.
>>
>> do you think this is better:
>> while(1) {
>>         if (exception1) {
>>                 ...
>>                 break;
>>         }
>>         ...
>>         if (exception2) {
>>                 ...
>>                 continue;
>>         }
>>         break;
>> }
>
> I rather thought of
>
> for (;;) {
>         if (exception1) {
>                 ...
>                 break;
>         }
>         ...
>         if (!exception2)
>                 break;
>         ...
> }

I don't think that is much better, but I changed the first patch to
use a loop anyway. The loop is then removed (as before) in the patch
that adds the stats.

>
> [--snip--]
>> >> +static int suspend_block_suspend(struct sys_device *dev, pm_message_t state)
>> >> +{
>> >> +     int ret = suspend_is_blocked() ? -EAGAIN : 0;
>> >> +     if (debug_mask & DEBUG_SUSPEND)
>> >> +             pr_info("suspend_block_suspend return %d\n", ret);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +static struct sysdev_class suspend_block_sysclass = {
>> >> +     .name = "suspend_block",
>> >> +     .suspend = suspend_block_suspend,
>> >> +};
>> >> +static struct sys_device suspend_block_sysdev = {
>> >> +     .cls = &suspend_block_sysclass,
>> >> +};
>> >> +
>> >
>> > Hmm.  Perhaps add the suspend_is_blocked() check at the beginning of
>> > sysdev_suspend() instead of this?  Surely you don't want to suspend
>> > any sysdevs with any suspend blockers active, right?
>>
>> You could make the same argument for any device. Using a sysdev makes
>> the patch easier to apply.
>
> You've lost me here. :-)

You have been making other changes to those files which made it a moving target.

> AFAICT, the only purpose of the sysdev class above is to abort suspend if
> suspend_is_blocked() returns 'true'.  If that is correct, then IMO you could
> achieve the same goal by calling suspend_is_blocked() directly from
> sysdev_suspend(), right before check_wakeup_irqs().  Or am I missing anything?

The stats patch also used it to track wakeup events, but I have added
another call for this to get rid of the sysdev.

-- 
Arve Hjønnevåg