[PATCH 0/8] Suspend block api (version 6)

[PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

This patch series adds a suspend-block api that provides the same
functionality as the android wakelock api. This version fixes a race
in suspend blocking work, has some documentation changes and
opportunistic suspend now uses the same workqueue as runtime pm.

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

[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

[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

[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 |   17 ++++
 include/linux/suspend_block_dev.h             |   25 +++++
 kernel/power/Kconfig                          |    9 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
 6 files changed, 182 insertions(+), 1 deletions(-)
 create mode 100644 include/linux/suspend_block_dev.h
 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 3d060e8..f2b145e 100644
--- a/Documentation/power/opportunistic-suspend.txt
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
 else
 	suspend_block(&state->suspend_blocker);
 
+User-space API
+==============
+
+To create a suspend_blocker from user-space, open the suspend_blocker device:
+    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
+then call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
+
+To activate a suspend_blocker call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
+
+To unblock call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
+
+To destroy the suspend_blocker, close the device:
+    close(fd);
+
diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
new file mode 100644
index 0000000..24bc5c7
--- /dev/null
+++ b/include/linux/suspend_block_dev.h
@@ -0,0 +1,25 @@
+/* include/linux/suspend_block_dev.h
+ *
+ * Copyright (C) 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_DEV_H
+#define _LINUX_SUSPEND_BLOCK_DEV_H
+
+#include <linux/ioctl.h>
+
+#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
+#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
+#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
+
+#endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 55a06a1..fe5a2f2 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  User-space suspend block api. Creates a misc device with ioctls
+	  to create, block and unblock a suspend_blocker. The suspend_blocker
+	  will be deleted when the device is closed.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
--- /dev/null
+++ b/kernel/power/user_suspend_blocker.c
@@ -0,0 +1,128 @@
+/* kernel/power/user_suspend_block.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_blocker.h>
+#include <linux/suspend_block_dev.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);
+
+struct user_suspend_blocker {
+	struct suspend_blocker	blocker;
+	char			name[0];
+};
+
+static int create_user_suspend_blocker(struct file *file, void __user *name,
+				 size_t name_len)
+{
+	struct user_suspend_blocker *bl;
+	if (file->private_data)
+		return -EBUSY;
+	if (name_len > NAME_MAX)
+		return -ENAMETOOLONG;
+	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
+	if (!bl)
+		return -ENOMEM;
+	if (copy_from_user(bl->name, name, name_len))
+		goto err_fault;
+	suspend_blocker_init(&bl->blocker, bl->name);
+	file->private_data = bl;
+	return 0;
+
+err_fault:
+	kfree(bl);
+	return -EFAULT;
+}
+
+static long user_suspend_blocker_ioctl(struct file *file, unsigned int cmd,
+				unsigned long _arg)
+{
+	void __user *arg = (void __user *)_arg;
+	struct user_suspend_blocker *bl;
+	long ret;
+
+	mutex_lock(&ioctl_lock);
+	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_INIT(0)) {
+		ret = create_user_suspend_blocker(file, arg, _IOC_SIZE(cmd));
+		goto done;
+	}
+	bl = file->private_data;
+	if (!bl) {
+		ret = -ENOENT;
+		goto done;
+	}
+	switch (cmd) {
+	case SUSPEND_BLOCKER_IOCTL_BLOCK:
+		suspend_block(&bl->blocker);
+		ret = 0;
+		break;
+	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
+		suspend_unblock(&bl->blocker);
+		ret = 0;
+		break;
+	default:
+		ret = -ENOTSUPP;
+	}
+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 *file)
+{
+	struct user_suspend_blocker *bl = file->private_data;
+	if (!bl)
+		return 0;
+	suspend_blocker_destroy(&bl->blocker);
+	kfree(bl);
+	return 0;
+}
+
+const struct file_operations user_suspend_blocker_fops = {
+	.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

[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 |   17 ++++
 include/linux/suspend_block_dev.h             |   25 +++++
 kernel/power/Kconfig                          |    9 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
 6 files changed, 182 insertions(+), 1 deletions(-)
 create mode 100644 include/linux/suspend_block_dev.h
 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 3d060e8..f2b145e 100644
--- a/Documentation/power/opportunistic-suspend.txt
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
 else
 	suspend_block(&state->suspend_blocker);
 
+User-space API
+==============
+
+To create a suspend_blocker from user-space, open the suspend_blocker device:
+    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
+then call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
+
+To activate a suspend_blocker call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
+
+To unblock call:
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
+
+To destroy the suspend_blocker, close the device:
+    close(fd);
+
diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
new file mode 100644
index 0000000..24bc5c7
--- /dev/null
+++ b/include/linux/suspend_block_dev.h
@@ -0,0 +1,25 @@
+/* include/linux/suspend_block_dev.h
+ *
+ * Copyright (C) 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_DEV_H
+#define _LINUX_SUSPEND_BLOCK_DEV_H
+
+#include <linux/ioctl.h>
+
+#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
+#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
+#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
+
+#endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 55a06a1..fe5a2f2 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  User-space suspend block api. Creates a misc device with ioctls
+	  to create, block and unblock a suspend_blocker. The suspend_blocker
+	  will be deleted when the device is closed.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
--- /dev/null
+++ b/kernel/power/user_suspend_blocker.c
@@ -0,0 +1,128 @@
+/* kernel/power/user_suspend_block.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_blocker.h>
+#include <linux/suspend_block_dev.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);
+
+struct user_suspend_blocker {
+	struct suspend_blocker	blocker;
+	char			name[0];
+};
+
+static int create_user_suspend_blocker(struct file *file, void __user *name,
+				 size_t name_len)
+{
+	struct user_suspend_blocker *bl;
+	if (file->private_data)
+		return -EBUSY;
+	if (name_len > NAME_MAX)
+		return -ENAMETOOLONG;
+	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
+	if (!bl)
+		return -ENOMEM;
+	if (copy_from_user(bl->name, name, name_len))
+		goto err_fault;
+	suspend_blocker_init(&bl->blocker, bl->name);
+	file->private_data = bl;
+	return 0;
+
+err_fault:
+	kfree(bl);
+	return -EFAULT;
+}
+
+static long user_suspend_blocker_ioctl(struct file *file, unsigned int cmd,
+				unsigned long _arg)
+{
+	void __user *arg = (void __user *)_arg;
+	struct user_suspend_blocker *bl;
+	long ret;
+
+	mutex_lock(&ioctl_lock);
+	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_INIT(0)) {
+		ret = create_user_suspend_blocker(file, arg, _IOC_SIZE(cmd));
+		goto done;
+	}
+	bl = file->private_data;
+	if (!bl) {
+		ret = -ENOENT;
+		goto done;
+	}
+	switch (cmd) {
+	case SUSPEND_BLOCKER_IOCTL_BLOCK:
+		suspend_block(&bl->blocker);
+		ret = 0;
+		break;
+	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
+		suspend_unblock(&bl->blocker);
+		ret = 0;
+		break;
+	default:
+		ret = -ENOTSUPP;
+	}
+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 *file)
+{
+	struct user_suspend_blocker *bl = file->private_data;
+	if (!bl)
+		return 0;
+	suspend_blocker_destroy(&bl->blocker);
+	kfree(bl);
+	return 0;
+}
+
+const struct file_operations user_suspend_blocker_fops = {
+	.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>
---
 kernel/power/process.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index 71ae290..d8ebd50 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -15,6 +15,7 @@
 #include <linux/syscalls.h>
 #include <linux/freezer.h>
 #include <linux/delay.h>
+#include <linux/suspend_blocker.h>
 
 /* 
  * Timeout for stopping processes
@@ -38,6 +39,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 +65,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 +91,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

[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>
---
 kernel/power/process.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index 71ae290..d8ebd50 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -15,6 +15,7 @@
 #include <linux/syscalls.h>
 #include <linux/freezer.h>
 #include <linux/delay.h>
+#include <linux/suspend_blocker.h>
 
 /* 
  * Timeout for stopping processes
@@ -38,6 +39,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 +65,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 +91,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/suspend_blocker.c |   43 ++++++++++++++++++++++++++++++++++++++-
 1 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
index 2c58b21..ced4993 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -17,6 +17,7 @@
 #include <linux/rtc.h>
 #include <linux/suspend.h>
 #include <linux/suspend_blocker.h>
+#include <linux/debugfs.h>
 #include "power.h"
 
 extern struct workqueue_struct *pm_wq;
@@ -42,6 +43,7 @@ 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;
+static struct dentry *suspend_blocker_stats_dentry;
 
 #define pr_info_time(fmt, args...) \
 	do { \
@@ -55,6 +57,21 @@ static bool enable_suspend_blockers;
 			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
 	} while (0);
 
+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 void print_active_blockers_locked(void)
 {
 	struct suspend_blocker *blocker;
@@ -106,8 +123,8 @@ 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.
- *
+ * @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_destroy.
  */
@@ -254,8 +271,30 @@ int request_suspend_state(suspend_state_t state)
 	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,
+};
+
 void __init suspend_block_init(void)
 {
 	suspend_blocker_init(&main_suspend_blocker, "main");
 	suspend_block(&main_suspend_blocker);
 }
+
+static int __init suspend_block_postcore_init(void)
+{
+	suspend_blocker_stats_dentry = debugfs_create_file("suspend_blockers",
+			S_IRUGO, NULL, NULL, &suspend_blocker_stats_fops);
+	return 0;
+}
+
+postcore_initcall(suspend_block_postcore_init);
-- 
1.6.5.1

[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/suspend_blocker.c |   43 ++++++++++++++++++++++++++++++++++++++-
 1 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
index 2c58b21..ced4993 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -17,6 +17,7 @@
 #include <linux/rtc.h>
 #include <linux/suspend.h>
 #include <linux/suspend_blocker.h>
+#include <linux/debugfs.h>
 #include "power.h"
 
 extern struct workqueue_struct *pm_wq;
@@ -42,6 +43,7 @@ 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;
+static struct dentry *suspend_blocker_stats_dentry;
 
 #define pr_info_time(fmt, args...) \
 	do { \
@@ -55,6 +57,21 @@ static bool enable_suspend_blockers;
 			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
 	} while (0);
 
+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 void print_active_blockers_locked(void)
 {
 	struct suspend_blocker *blocker;
@@ -106,8 +123,8 @@ 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.
- *
+ * @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_destroy.
  */
@@ -254,8 +271,30 @@ int request_suspend_state(suspend_state_t state)
 	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,
+};
+
 void __init suspend_block_init(void)
 {
 	suspend_blocker_init(&main_suspend_blocker, "main");
 	suspend_block(&main_suspend_blocker);
 }
+
+static int __init suspend_block_postcore_init(void)
+{
+	suspend_blocker_stats_dentry = debugfs_create_file("suspend_blockers",
+			S_IRUGO, NULL, NULL, &suspend_blocker_stats_fops);
+	return 0;
+}
+
+postcore_initcall(suspend_block_postcore_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 |   21 ++++-
 kernel/power/Kconfig            |    7 ++
 kernel/power/power.h            |    5 +
 kernel/power/suspend.c          |    4 +-
 kernel/power/suspend_blocker.c  |  190 +++++++++++++++++++++++++++++++++++++--
 5 files changed, 218 insertions(+), 9 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index f9928cc..c80764c 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -17,12 +17,21 @@
 #define _LINUX_SUSPEND_BLOCKER_H
 
 #include <linux/list.h>
+#include <linux/ktime.h>
 
 /**
  * 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, active and stats state.
  * @name:	Name used for debugging.
+ * @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.
  *
  * When a suspend_blocker is active it prevents the system from entering
  * opportunistic suspend.
@@ -35,6 +44,16 @@ struct suspend_blocker {
 	struct list_head    link;
 	int                 flags;
 	const char         *name;
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	struct {
+		int             count;
+		int             wakeup_count;
+		ktime_t         total_time;
+		ktime_t         prevent_suspend_time;
+		ktime_t         max_time;
+		ktime_t         last_time;
+	} stat;
+#endif
 #endif
 };
 
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index fe5a2f2..4bcba07 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 SUSPEND_BLOCKER_STATS
+	bool "Suspend block stats"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  Report suspend block stats in /sys/kernel/debug/suspend_blockers
+
 config USER_SUSPEND_BLOCKERS
 	bool "Userspace suspend blockers"
 	depends on OPPORTUNISTIC_SUSPEND
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 67d10fd..897c116 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -245,3 +245,8 @@ extern void __init suspend_block_init(void);
 #else
 static inline void suspend_block_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 dc42006..6d327ea 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -159,8 +159,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();
 	}
 
diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
index ced4993..77920e6 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -34,6 +34,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)
 
 static DEFINE_SPINLOCK(list_lock);
 static DEFINE_SPINLOCK(state_lock);
@@ -43,6 +44,7 @@ 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;
+static struct suspend_blocker unknown_wakeup;
 static struct dentry *suspend_blocker_stats_dentry;
 
 #define pr_info_time(fmt, args...) \
@@ -57,6 +59,153 @@ static struct dentry *suspend_blocker_stats_dentry;
 			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
 	} while (0);
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static struct suspend_blocker deleted_suspend_blockers;
+static ktime_t last_sleep_time_update;
+static bool wait_for_wakeup;
+
+static int print_blocker_stat(struct seq_file *m,
+			      struct suspend_blocker *blocker)
+{
+	int lock_count = blocker->stat.count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = blocker->stat.total_time;
+	ktime_t max_time = blocker->stat.max_time;
+	ktime_t prevent_suspend_time = blocker->stat.prevent_suspend_time;
+	if (blocker->flags & SB_ACTIVE) {
+		ktime_t now, add_time;
+		now = ktime_get();
+		add_time = ktime_sub(now, blocker->stat.last_time);
+		lock_count++;
+		active_time = add_time;
+		total_time = ktime_add(total_time, add_time);
+		if (blocker->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",
+		       blocker->name, lock_count, blocker->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(blocker->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, &inactive_blockers, link)
+		print_blocker_stat(m, blocker);
+	list_for_each_entry(blocker, &active_blockers, link)
+		print_blocker_stat(m, blocker);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+static void suspend_blocker_stat_init_locked(struct suspend_blocker *blocker)
+{
+	blocker->stat.count = 0;
+	blocker->stat.wakeup_count = 0;
+	blocker->stat.total_time = ktime_set(0, 0);
+	blocker->stat.prevent_suspend_time = ktime_set(0, 0);
+	blocker->stat.max_time = ktime_set(0, 0);
+	blocker->stat.last_time = ktime_set(0, 0);
+}
+
+static void suspend_blocker_stat_destroy_locked(struct suspend_blocker *bl)
+{
+	if (!bl->stat.count)
+		return;
+	deleted_suspend_blockers.stat.count += bl->stat.count;
+	deleted_suspend_blockers.stat.total_time = ktime_add(
+		deleted_suspend_blockers.stat.total_time, bl->stat.total_time);
+	deleted_suspend_blockers.stat.prevent_suspend_time = ktime_add(
+		deleted_suspend_blockers.stat.prevent_suspend_time,
+		bl->stat.prevent_suspend_time);
+	deleted_suspend_blockers.stat.max_time = ktime_add(
+		deleted_suspend_blockers.stat.max_time, bl->stat.max_time);
+}
+
+static void suspend_unblock_stat_locked(struct suspend_blocker *blocker)
+{
+	ktime_t duration;
+	ktime_t now;
+	if (!(blocker->flags & SB_ACTIVE))
+		return;
+	now = ktime_get();
+	blocker->stat.count++;
+	duration = ktime_sub(now, blocker->stat.last_time);
+	blocker->stat.total_time =
+		ktime_add(blocker->stat.total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(blocker->stat.max_time))
+		blocker->stat.max_time = duration;
+	blocker->stat.last_time = ktime_get();
+	if (blocker->flags & SB_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		blocker->stat.prevent_suspend_time = ktime_add(
+			blocker->stat.prevent_suspend_time, duration);
+		blocker->flags &= ~SB_PREVENTING_SUSPEND;
+	}
+}
+
+static void suspend_block_stat_locked(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_locked(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) {
+		if (blocker->flags & SB_PREVENTING_SUSPEND) {
+			add = elapsed;
+			blocker->stat.prevent_suspend_time = ktime_add(
+				blocker->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
+
+static inline void suspend_blocker_stat_init_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_blocker_stat_destroy_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_block_stat_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_unblock_stat_locked(
+					struct suspend_blocker *blocker) {}
+static inline void update_sleep_wait_stats_locked(bool done) {}
+
 static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 {
 	unsigned long irqflags;
@@ -72,6 +221,8 @@ static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 	return 0;
 }
 
+#endif
+
 static void print_active_blockers_locked(void)
 {
 	struct suspend_blocker *blocker;
@@ -102,20 +253,31 @@ static void suspend_worker(struct work_struct *work)
 	int entry_event_num;
 
 	enable_suspend_blockers = true;
-	while (!suspend_is_blocked()) {
-		entry_event_num = current_event_num;
 
+	if (suspend_is_blocked()) {
 		if (debug_mask & DEBUG_SUSPEND)
-			pr_info("suspend: enter suspend\n");
+			pr_info("suspend: abort suspend\n");
+		goto abort;
+	}
+
+	entry_event_num = current_event_num;
 
-		ret = pm_suspend(requested_suspend_state);
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("suspend: enter suspend\n");
 
-		if (debug_mask & DEBUG_EXIT_SUSPEND)
-			pr_info_time("suspend: exit suspend, ret = %d ", ret);
+	ret = pm_suspend(requested_suspend_state);
 
-		if (current_event_num == entry_event_num)
+	if (debug_mask & DEBUG_EXIT_SUSPEND)
+		pr_info_time("suspend: exit suspend, ret = %d ", ret);
+
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
 			pr_info("suspend: pm_suspend returned with no event\n");
+
+		suspend_block(&unknown_wakeup);
+		suspend_unblock(&unknown_wakeup);
 	}
+abort:
 	enable_suspend_blockers = false;
 }
 static DECLARE_WORK(suspend_work, suspend_worker);
@@ -142,6 +304,7 @@ void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
 	INIT_LIST_HEAD(&blocker->link);
 
 	spin_lock_irqsave(&list_lock, irqflags);
+	suspend_blocker_stat_init_locked(blocker);
 	list_add(&blocker->link, &inactive_blockers);
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -161,6 +324,7 @@ void suspend_blocker_destroy(struct suspend_blocker *blocker)
 		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
 
 	spin_lock_irqsave(&list_lock, irqflags);
+	suspend_blocker_stat_destroy_locked(blocker);
 	blocker->flags &= ~SB_INITIALIZED;
 	list_del(&blocker->link);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -187,9 +351,14 @@ void suspend_block(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("suspend_block: %s\n", blocker->name);
 
+	suspend_block_stat_locked(blocker);
 	blocker->flags |= SB_ACTIVE;
 	list_move(&blocker->link, &active_blockers);
 	current_event_num++;
+	if (blocker == &main_suspend_blocker)
+		update_sleep_wait_stats_locked(true);
+	else if (!suspend_blocker_is_active(&main_suspend_blocker))
+		update_sleep_wait_stats_locked(false);
 
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -215,6 +384,7 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("suspend_unblock: %s\n", blocker->name);
 
+	suspend_unblock_stat_locked(blocker);
 	list_move(&blocker->link, &inactive_blockers);
 
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -223,6 +393,7 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (blocker == &main_suspend_blocker) {
 		if (debug_mask & DEBUG_SUSPEND)
 			print_active_blockers_locked();
+		update_sleep_wait_stats_locked(false);
 	}
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -288,6 +459,11 @@ void __init suspend_block_init(void)
 {
 	suspend_blocker_init(&main_suspend_blocker, "main");
 	suspend_block(&main_suspend_blocker);
+	suspend_blocker_init(&unknown_wakeup, "unknown_wakeups");
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	suspend_blocker_init(&deleted_suspend_blockers,
+				"deleted_suspend_blockers");
+#endif
 }
 
 static int __init suspend_block_postcore_init(void)
-- 
1.6.5.1

[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 |   21 ++++-
 kernel/power/Kconfig            |    7 ++
 kernel/power/power.h            |    5 +
 kernel/power/suspend.c          |    4 +-
 kernel/power/suspend_blocker.c  |  190 +++++++++++++++++++++++++++++++++++++--
 5 files changed, 218 insertions(+), 9 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index f9928cc..c80764c 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -17,12 +17,21 @@
 #define _LINUX_SUSPEND_BLOCKER_H
 
 #include <linux/list.h>
+#include <linux/ktime.h>
 
 /**
  * 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, active and stats state.
  * @name:	Name used for debugging.
+ * @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.
  *
  * When a suspend_blocker is active it prevents the system from entering
  * opportunistic suspend.
@@ -35,6 +44,16 @@ struct suspend_blocker {
 	struct list_head    link;
 	int                 flags;
 	const char         *name;
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	struct {
+		int             count;
+		int             wakeup_count;
+		ktime_t         total_time;
+		ktime_t         prevent_suspend_time;
+		ktime_t         max_time;
+		ktime_t         last_time;
+	} stat;
+#endif
 #endif
 };
 
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index fe5a2f2..4bcba07 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 SUSPEND_BLOCKER_STATS
+	bool "Suspend block stats"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  Report suspend block stats in /sys/kernel/debug/suspend_blockers
+
 config USER_SUSPEND_BLOCKERS
 	bool "Userspace suspend blockers"
 	depends on OPPORTUNISTIC_SUSPEND
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 67d10fd..897c116 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -245,3 +245,8 @@ extern void __init suspend_block_init(void);
 #else
 static inline void suspend_block_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 dc42006..6d327ea 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -159,8 +159,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();
 	}
 
diff --git a/kernel/power/suspend_blocker.c b/kernel/power/suspend_blocker.c
index ced4993..77920e6 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -34,6 +34,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)
 
 static DEFINE_SPINLOCK(list_lock);
 static DEFINE_SPINLOCK(state_lock);
@@ -43,6 +44,7 @@ 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;
+static struct suspend_blocker unknown_wakeup;
 static struct dentry *suspend_blocker_stats_dentry;
 
 #define pr_info_time(fmt, args...) \
@@ -57,6 +59,153 @@ static struct dentry *suspend_blocker_stats_dentry;
 			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
 	} while (0);
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static struct suspend_blocker deleted_suspend_blockers;
+static ktime_t last_sleep_time_update;
+static bool wait_for_wakeup;
+
+static int print_blocker_stat(struct seq_file *m,
+			      struct suspend_blocker *blocker)
+{
+	int lock_count = blocker->stat.count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = blocker->stat.total_time;
+	ktime_t max_time = blocker->stat.max_time;
+	ktime_t prevent_suspend_time = blocker->stat.prevent_suspend_time;
+	if (blocker->flags & SB_ACTIVE) {
+		ktime_t now, add_time;
+		now = ktime_get();
+		add_time = ktime_sub(now, blocker->stat.last_time);
+		lock_count++;
+		active_time = add_time;
+		total_time = ktime_add(total_time, add_time);
+		if (blocker->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",
+		       blocker->name, lock_count, blocker->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(blocker->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, &inactive_blockers, link)
+		print_blocker_stat(m, blocker);
+	list_for_each_entry(blocker, &active_blockers, link)
+		print_blocker_stat(m, blocker);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+static void suspend_blocker_stat_init_locked(struct suspend_blocker *blocker)
+{
+	blocker->stat.count = 0;
+	blocker->stat.wakeup_count = 0;
+	blocker->stat.total_time = ktime_set(0, 0);
+	blocker->stat.prevent_suspend_time = ktime_set(0, 0);
+	blocker->stat.max_time = ktime_set(0, 0);
+	blocker->stat.last_time = ktime_set(0, 0);
+}
+
+static void suspend_blocker_stat_destroy_locked(struct suspend_blocker *bl)
+{
+	if (!bl->stat.count)
+		return;
+	deleted_suspend_blockers.stat.count += bl->stat.count;
+	deleted_suspend_blockers.stat.total_time = ktime_add(
+		deleted_suspend_blockers.stat.total_time, bl->stat.total_time);
+	deleted_suspend_blockers.stat.prevent_suspend_time = ktime_add(
+		deleted_suspend_blockers.stat.prevent_suspend_time,
+		bl->stat.prevent_suspend_time);
+	deleted_suspend_blockers.stat.max_time = ktime_add(
+		deleted_suspend_blockers.stat.max_time, bl->stat.max_time);
+}
+
+static void suspend_unblock_stat_locked(struct suspend_blocker *blocker)
+{
+	ktime_t duration;
+	ktime_t now;
+	if (!(blocker->flags & SB_ACTIVE))
+		return;
+	now = ktime_get();
+	blocker->stat.count++;
+	duration = ktime_sub(now, blocker->stat.last_time);
+	blocker->stat.total_time =
+		ktime_add(blocker->stat.total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(blocker->stat.max_time))
+		blocker->stat.max_time = duration;
+	blocker->stat.last_time = ktime_get();
+	if (blocker->flags & SB_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		blocker->stat.prevent_suspend_time = ktime_add(
+			blocker->stat.prevent_suspend_time, duration);
+		blocker->flags &= ~SB_PREVENTING_SUSPEND;
+	}
+}
+
+static void suspend_block_stat_locked(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_locked(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) {
+		if (blocker->flags & SB_PREVENTING_SUSPEND) {
+			add = elapsed;
+			blocker->stat.prevent_suspend_time = ktime_add(
+				blocker->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
+
+static inline void suspend_blocker_stat_init_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_blocker_stat_destroy_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_block_stat_locked(
+					struct suspend_blocker *blocker) {}
+static inline void suspend_unblock_stat_locked(
+					struct suspend_blocker *blocker) {}
+static inline void update_sleep_wait_stats_locked(bool done) {}
+
 static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 {
 	unsigned long irqflags;
@@ -72,6 +221,8 @@ static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 	return 0;
 }
 
+#endif
+
 static void print_active_blockers_locked(void)
 {
 	struct suspend_blocker *blocker;
@@ -102,20 +253,31 @@ static void suspend_worker(struct work_struct *work)
 	int entry_event_num;
 
 	enable_suspend_blockers = true;
-	while (!suspend_is_blocked()) {
-		entry_event_num = current_event_num;
 
+	if (suspend_is_blocked()) {
 		if (debug_mask & DEBUG_SUSPEND)
-			pr_info("suspend: enter suspend\n");
+			pr_info("suspend: abort suspend\n");
+		goto abort;
+	}
+
+	entry_event_num = current_event_num;
 
-		ret = pm_suspend(requested_suspend_state);
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("suspend: enter suspend\n");
 
-		if (debug_mask & DEBUG_EXIT_SUSPEND)
-			pr_info_time("suspend: exit suspend, ret = %d ", ret);
+	ret = pm_suspend(requested_suspend_state);
 
-		if (current_event_num == entry_event_num)
+	if (debug_mask & DEBUG_EXIT_SUSPEND)
+		pr_info_time("suspend: exit suspend, ret = %d ", ret);
+
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
 			pr_info("suspend: pm_suspend returned with no event\n");
+
+		suspend_block(&unknown_wakeup);
+		suspend_unblock(&unknown_wakeup);
 	}
+abort:
 	enable_suspend_blockers = false;
 }
 static DECLARE_WORK(suspend_work, suspend_worker);
@@ -142,6 +304,7 @@ void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
 	INIT_LIST_HEAD(&blocker->link);
 
 	spin_lock_irqsave(&list_lock, irqflags);
+	suspend_blocker_stat_init_locked(blocker);
 	list_add(&blocker->link, &inactive_blockers);
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -161,6 +324,7 @@ void suspend_blocker_destroy(struct suspend_blocker *blocker)
 		pr_info("suspend_blocker_destroy name=%s\n", blocker->name);
 
 	spin_lock_irqsave(&list_lock, irqflags);
+	suspend_blocker_stat_destroy_locked(blocker);
 	blocker->flags &= ~SB_INITIALIZED;
 	list_del(&blocker->link);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -187,9 +351,14 @@ void suspend_block(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("suspend_block: %s\n", blocker->name);
 
+	suspend_block_stat_locked(blocker);
 	blocker->flags |= SB_ACTIVE;
 	list_move(&blocker->link, &active_blockers);
 	current_event_num++;
+	if (blocker == &main_suspend_blocker)
+		update_sleep_wait_stats_locked(true);
+	else if (!suspend_blocker_is_active(&main_suspend_blocker))
+		update_sleep_wait_stats_locked(false);
 
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -215,6 +384,7 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("suspend_unblock: %s\n", blocker->name);
 
+	suspend_unblock_stat_locked(blocker);
 	list_move(&blocker->link, &inactive_blockers);
 
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -223,6 +393,7 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (blocker == &main_suspend_blocker) {
 		if (debug_mask & DEBUG_SUSPEND)
 			print_active_blockers_locked();
+		update_sleep_wait_stats_locked(false);
 	}
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -288,6 +459,11 @@ void __init suspend_block_init(void)
 {
 	suspend_blocker_init(&main_suspend_blocker, "main");
 	suspend_block(&main_suspend_blocker);
+	suspend_blocker_init(&unknown_wakeup, "unknown_wakeups");
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	suspend_blocker_init(&deleted_suspend_blockers,
+				"deleted_suspend_blockers");
+#endif
 }
 
 static int __init suspend_block_postcore_init(void)
-- 
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>
---
 include/linux/suspend_blocker.h |   67 ++++++++++++++++++++++++
 kernel/power/suspend_blocker.c  |  109 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 176 insertions(+), 0 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index c80764c..bf41a57 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 - the basic suspend_blocker structure
@@ -57,6 +58,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
 
 void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
@@ -66,6 +99,14 @@ void suspend_unblock(struct suspend_blocker *blocker);
 bool suspend_blocker_is_active(struct suspend_blocker *blocker);
 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
 
 static inline void suspend_blocker_init(struct suspend_blocker *blocker,
@@ -77,6 +118,32 @@ static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
 								{ return 0; }
 static inline bool suspend_is_blocked(void) { return 0; }
 
+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/suspend_blocker.c b/kernel/power/suspend_blocker.c
index 77920e6..852d941 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -474,3 +474,112 @@ static int __init suspend_block_postcore_init(void)
 }
 
 postcore_initcall(suspend_block_postcore_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 suspend_blocking_work
+ * @work: The work item in question.
+ * @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 suspend_blocking_work
+ * @work: The work item in question
+ */
+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 suspend_blocking_work
+ * @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_destroy(&work->suspend_blocker);
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_destroy);
+
+/**
+ * queue_suspend_blocking_work - Queue suspend blocking work
+ * @wq:		Workqueue to queue work on.
+ * @work:	The work item in question.
+ */
+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 - Queue suspend blocking work
+ * @work:	The work item in question.
+ */
+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

[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>
---
 include/linux/suspend_blocker.h |   67 ++++++++++++++++++++++++
 kernel/power/suspend_blocker.c  |  109 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 176 insertions(+), 0 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index c80764c..bf41a57 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 - the basic suspend_blocker structure
@@ -57,6 +58,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
 
 void suspend_blocker_init(struct suspend_blocker *blocker, const char *name);
@@ -66,6 +99,14 @@ void suspend_unblock(struct suspend_blocker *blocker);
 bool suspend_blocker_is_active(struct suspend_blocker *blocker);
 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
 
 static inline void suspend_blocker_init(struct suspend_blocker *blocker,
@@ -77,6 +118,32 @@ static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
 								{ return 0; }
 static inline bool suspend_is_blocked(void) { return 0; }
 
+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/suspend_blocker.c b/kernel/power/suspend_blocker.c
index 77920e6..852d941 100644
--- a/kernel/power/suspend_blocker.c
+++ b/kernel/power/suspend_blocker.c
@@ -474,3 +474,112 @@ static int __init suspend_block_postcore_init(void)
 }
 
 postcore_initcall(suspend_block_postcore_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 suspend_blocking_work
+ * @work: The work item in question.
+ * @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 suspend_blocking_work
+ * @work: The work item in question
+ */
+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 suspend_blocking_work
+ * @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_destroy(&work->suspend_blocker);
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_destroy);
+
+/**
+ * queue_suspend_blocking_work - Queue suspend blocking work
+ * @wq:		Workqueue to queue work on.
+ * @work:	The work item in question.
+ */
+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 - Queue suspend blocking work
+ * @work:	The work item in question.
+ */
+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..66e0d16 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_blocker.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_destroy(&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_destroy(&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

[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..66e0d16 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_blocker.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_destroy(&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_destroy(&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..8a12d50 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_blocker.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

[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..8a12d50 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_blocker.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 6/8] PM: Add suspend blocking work.

[Tejun Heo]

On 05/01/2010 12:36 AM, Arve Hjønnevåg wrote:
> 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>

Thank you.

-- 
tejun

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

[Tejun Heo]

On 05/01/2010 12:36 AM, Arve Hjønnevåg wrote:
> 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>

Thank you.

-- 
tejun
_______________________________________________
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]

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 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.

[Pavel Machek]

Hi!

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

I acked this one before, please preserve such tags.
								Pavel

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

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

[Pavel Machek]

Hi!

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

I acked this one before, please preserve such tags.
								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.

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

[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 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Pavel Machek]

On Fri 2010-04-30 15:36:55, Arve Hj??nnev??g wrote:
> 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.

Yeah, this one is overly complex; instead of having 'open blocks
suspend' semantics and lsof listing active blockers, it adds strange
ioctl based interface passing names, and then adds debugfs
infrastructure listing those back.

I guess this is why you are getying 'it should be in /proc, no in
/sys, no in debugfs, no in /proc' kind of feedback. This should simply
not exist in the first place...

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

NAK.

> ---
>  Documentation/ioctl/ioctl-number.txt          |    3 +-
>  Documentation/power/opportunistic-suspend.txt |   17 ++++
>  include/linux/suspend_block_dev.h             |   25 +++++
>  kernel/power/Kconfig                          |    9 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
>  6 files changed, 182 insertions(+), 1 deletions(-)
>  create mode 100644 include/linux/suspend_block_dev.h
>  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 3d060e8..f2b145e 100644
> --- a/Documentation/power/opportunistic-suspend.txt
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
>  else
>  	suspend_block(&state->suspend_blocker);
>  
> +User-space API
> +==============
> +
> +To create a suspend_blocker from user-space, open the suspend_blocker device:
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +then call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
> +
> +To activate a suspend_blocker call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To unblock call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend_blocker, close the device:
> +    close(fd);
> +
> diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
> new file mode 100644
> index 0000000..24bc5c7
> --- /dev/null
> +++ b/include/linux/suspend_block_dev.h
> @@ -0,0 +1,25 @@
> +/* include/linux/suspend_block_dev.h
> + *
> + * Copyright (C) 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_DEV_H
> +#define _LINUX_SUSPEND_BLOCK_DEV_H
> +
> +#include <linux/ioctl.h>
> +
> +#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
> +#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
> +#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
> +
> +#endif
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 55a06a1..fe5a2f2 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
> +	depends on OPPORTUNISTIC_SUSPEND
> +	default y
> +	---help---
> +	  User-space suspend block api. Creates a misc device with ioctls
> +	  to create, block and unblock a suspend_blocker. The suspend_blocker
> +	  will be deleted when the device is closed.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
> --- /dev/null
> +++ b/kernel/power/user_suspend_blocker.c
> @@ -0,0 +1,128 @@
> +/* kernel/power/user_suspend_block.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_blocker.h>
> +#include <linux/suspend_block_dev.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);
> +
> +struct user_suspend_blocker {
> +	struct suspend_blocker	blocker;
> +	char			name[0];
> +};
> +
> +static int create_user_suspend_blocker(struct file *file, void __user *name,
> +				 size_t name_len)
> +{
> +	struct user_suspend_blocker *bl;
> +	if (file->private_data)
> +		return -EBUSY;
> +	if (name_len > NAME_MAX)
> +		return -ENAMETOOLONG;
> +	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
> +	if (!bl)
> +		return -ENOMEM;
> +	if (copy_from_user(bl->name, name, name_len))
> +		goto err_fault;
> +	suspend_blocker_init(&bl->blocker, bl->name);
> +	file->private_data = bl;
> +	return 0;
> +
> +err_fault:
> +	kfree(bl);
> +	return -EFAULT;
> +}
> +
> +static long user_suspend_blocker_ioctl(struct file *file, unsigned int cmd,
> +				unsigned long _arg)
> +{
> +	void __user *arg = (void __user *)_arg;
> +	struct user_suspend_blocker *bl;
> +	long ret;
> +
> +	mutex_lock(&ioctl_lock);
> +	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_INIT(0)) {
> +		ret = create_user_suspend_blocker(file, arg, _IOC_SIZE(cmd));
> +		goto done;
> +	}
> +	bl = file->private_data;
> +	if (!bl) {
> +		ret = -ENOENT;
> +		goto done;
> +	}
> +	switch (cmd) {
> +	case SUSPEND_BLOCKER_IOCTL_BLOCK:
> +		suspend_block(&bl->blocker);
> +		ret = 0;
> +		break;
> +	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
> +		suspend_unblock(&bl->blocker);
> +		ret = 0;
> +		break;
> +	default:
> +		ret = -ENOTSUPP;
> +	}
> +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 *file)
> +{
> +	struct user_suspend_blocker *bl = file->private_data;
> +	if (!bl)
> +		return 0;
> +	suspend_blocker_destroy(&bl->blocker);
> +	kfree(bl);
> +	return 0;
> +}
> +
> +const struct file_operations user_suspend_blocker_fops = {
> +	.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);

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

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

[Pavel Machek]

On Fri 2010-04-30 15:36:55, Arve Hj??nnev??g wrote:
> 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.

Yeah, this one is overly complex; instead of having 'open blocks
suspend' semantics and lsof listing active blockers, it adds strange
ioctl based interface passing names, and then adds debugfs
infrastructure listing those back.

I guess this is why you are getying 'it should be in /proc, no in
/sys, no in debugfs, no in /proc' kind of feedback. This should simply
not exist in the first place...

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

NAK.

> ---
>  Documentation/ioctl/ioctl-number.txt          |    3 +-
>  Documentation/power/opportunistic-suspend.txt |   17 ++++
>  include/linux/suspend_block_dev.h             |   25 +++++
>  kernel/power/Kconfig                          |    9 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
>  6 files changed, 182 insertions(+), 1 deletions(-)
>  create mode 100644 include/linux/suspend_block_dev.h
>  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 3d060e8..f2b145e 100644
> --- a/Documentation/power/opportunistic-suspend.txt
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
>  else
>  	suspend_block(&state->suspend_blocker);
>  
> +User-space API
> +==============
> +
> +To create a suspend_blocker from user-space, open the suspend_blocker device:
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +then call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
> +
> +To activate a suspend_blocker call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To unblock call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend_blocker, close the device:
> +    close(fd);
> +
> diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
> new file mode 100644
> index 0000000..24bc5c7
> --- /dev/null
> +++ b/include/linux/suspend_block_dev.h
> @@ -0,0 +1,25 @@
> +/* include/linux/suspend_block_dev.h
> + *
> + * Copyright (C) 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_DEV_H
> +#define _LINUX_SUSPEND_BLOCK_DEV_H
> +
> +#include <linux/ioctl.h>
> +
> +#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
> +#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
> +#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
> +
> +#endif
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 55a06a1..fe5a2f2 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
> +	depends on OPPORTUNISTIC_SUSPEND
> +	default y
> +	---help---
> +	  User-space suspend block api. Creates a misc device with ioctls
> +	  to create, block and unblock a suspend_blocker. The suspend_blocker
> +	  will be deleted when the device is closed.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
> --- /dev/null
> +++ b/kernel/power/user_suspend_blocker.c
> @@ -0,0 +1,128 @@
> +/* kernel/power/user_suspend_block.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_blocker.h>
> +#include <linux/suspend_block_dev.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);
> +
> +struct user_suspend_blocker {
> +	struct suspend_blocker	blocker;
> +	char			name[0];
> +};
> +
> +static int create_user_suspend_blocker(struct file *file, void __user *name,
> +				 size_t name_len)
> +{
> +	struct user_suspend_blocker *bl;
> +	if (file->private_data)
> +		return -EBUSY;
> +	if (name_len > NAME_MAX)
> +		return -ENAMETOOLONG;
> +	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
> +	if (!bl)
> +		return -ENOMEM;
> +	if (copy_from_user(bl->name, name, name_len))
> +		goto err_fault;
> +	suspend_blocker_init(&bl->blocker, bl->name);
> +	file->private_data = bl;
> +	return 0;
> +
> +err_fault:
> +	kfree(bl);
> +	return -EFAULT;
> +}
> +
> +static long user_suspend_blocker_ioctl(struct file *file, unsigned int cmd,
> +				unsigned long _arg)
> +{
> +	void __user *arg = (void __user *)_arg;
> +	struct user_suspend_blocker *bl;
> +	long ret;
> +
> +	mutex_lock(&ioctl_lock);
> +	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_INIT(0)) {
> +		ret = create_user_suspend_blocker(file, arg, _IOC_SIZE(cmd));
> +		goto done;
> +	}
> +	bl = file->private_data;
> +	if (!bl) {
> +		ret = -ENOENT;
> +		goto done;
> +	}
> +	switch (cmd) {
> +	case SUSPEND_BLOCKER_IOCTL_BLOCK:
> +		suspend_block(&bl->blocker);
> +		ret = 0;
> +		break;
> +	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
> +		suspend_unblock(&bl->blocker);
> +		ret = 0;
> +		break;
> +	default:
> +		ret = -ENOTSUPP;
> +	}
> +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 *file)
> +{
> +	struct user_suspend_blocker *bl = file->private_data;
> +	if (!bl)
> +		return 0;
> +	suspend_blocker_destroy(&bl->blocker);
> +	kfree(bl);
> +	return 0;
> +}
> +
> +const struct file_operations user_suspend_blocker_fops = {
> +	.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);

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

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

[Pavel Machek]

On Fri 2010-04-30 15:36:59, Arve Hj??nnev??g wrote:
> 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>

Looks ok.

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

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

[Pavel Machek]

On Fri 2010-04-30 15:36:59, Arve Hj??nnev??g wrote:
> 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>

Looks ok.

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

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

[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 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Saturday 01 May 2010, Arve Hjønnevåg wrote:
> 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 |   17 ++++
>  include/linux/suspend_block_dev.h             |   25 +++++
>  kernel/power/Kconfig                          |    9 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
>  6 files changed, 182 insertions(+), 1 deletions(-)
>  create mode 100644 include/linux/suspend_block_dev.h
>  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 3d060e8..f2b145e 100644
> --- a/Documentation/power/opportunistic-suspend.txt
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
>  else
>  	suspend_block(&state->suspend_blocker);
>  
> +User-space API
> +==============
> +
> +To create a suspend_blocker from user-space, open the suspend_blocker device:
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +then call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
> +
> +To activate a suspend_blocker call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To unblock call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend_blocker, close the device:
> +    close(fd);
> +
> diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
> new file mode 100644
> index 0000000..24bc5c7
> --- /dev/null
> +++ b/include/linux/suspend_block_dev.h
> @@ -0,0 +1,25 @@
> +/* include/linux/suspend_block_dev.h
> + *
> + * Copyright (C) 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_DEV_H
> +#define _LINUX_SUSPEND_BLOCK_DEV_H
> +
> +#include <linux/ioctl.h>
> +
> +#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
> +#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
> +#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
> +
> +#endif
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 55a06a1..fe5a2f2 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
> +	depends on OPPORTUNISTIC_SUSPEND
> +	default y
> +	---help---
> +	  User-space suspend block api. Creates a misc device with ioctls
> +	  to create, block and unblock a suspend_blocker. The suspend_blocker
> +	  will be deleted when the device is closed.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
> --- /dev/null
> +++ b/kernel/power/user_suspend_blocker.c
> @@ -0,0 +1,128 @@
> +/* kernel/power/user_suspend_block.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_blocker.h>
> +#include <linux/suspend_block_dev.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);
> +
> +struct user_suspend_blocker {
> +	struct suspend_blocker	blocker;
> +	char			name[0];
> +};
> +
> +static int create_user_suspend_blocker(struct file *file, void __user *name,
> +				 size_t name_len)
> +{
> +	struct user_suspend_blocker *bl;
> +	if (file->private_data)
> +		return -EBUSY;
> +	if (name_len > NAME_MAX)
> +		return -ENAMETOOLONG;
> +	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
> +	if (!bl)
> +		return -ENOMEM;
> +	if (copy_from_user(bl->name, name, name_len))
> +		goto err_fault;
> +	suspend_blocker_init(&bl->blocker, bl->name);
> +	file->private_data = bl;

Hmm.  It doesn't seem to be possible to create two different suspend blockers
using the same file handle.  So, what exactly is a process supposed to do to
use two suspend blockers at the same time?

Rafael

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

[Rafael J. Wysocki]

On Saturday 01 May 2010, Arve Hjønnevåg wrote:
> 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 |   17 ++++
>  include/linux/suspend_block_dev.h             |   25 +++++
>  kernel/power/Kconfig                          |    9 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
>  6 files changed, 182 insertions(+), 1 deletions(-)
>  create mode 100644 include/linux/suspend_block_dev.h
>  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 3d060e8..f2b145e 100644
> --- a/Documentation/power/opportunistic-suspend.txt
> +++ b/Documentation/power/opportunistic-suspend.txt
> @@ -117,3 +117,20 @@ if (list_empty(&state->pending_work))
>  else
>  	suspend_block(&state->suspend_blocker);
>  
> +User-space API
> +==============
> +
> +To create a suspend_blocker from user-space, open the suspend_blocker device:
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +then call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
> +
> +To activate a suspend_blocker call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To unblock call:
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend_blocker, close the device:
> +    close(fd);
> +
> diff --git a/include/linux/suspend_block_dev.h b/include/linux/suspend_block_dev.h
> new file mode 100644
> index 0000000..24bc5c7
> --- /dev/null
> +++ b/include/linux/suspend_block_dev.h
> @@ -0,0 +1,25 @@
> +/* include/linux/suspend_block_dev.h
> + *
> + * Copyright (C) 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_DEV_H
> +#define _LINUX_SUSPEND_BLOCK_DEV_H
> +
> +#include <linux/ioctl.h>
> +
> +#define SUSPEND_BLOCKER_IOCTL_INIT(len)		_IOC(_IOC_WRITE, 's', 0, len)
> +#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
> +#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
> +
> +#endif
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 55a06a1..fe5a2f2 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -146,6 +146,15 @@ 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 "Userspace suspend blockers"
> +	depends on OPPORTUNISTIC_SUSPEND
> +	default y
> +	---help---
> +	  User-space suspend block api. Creates a misc device with ioctls
> +	  to create, block and unblock a suspend_blocker. The suspend_blocker
> +	  will be deleted when the device is closed.
> +
>  config HIBERNATION_NVS
>  	bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index ee5276d..78f703b 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)	+= suspend_blocker.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..dc1d06f
> --- /dev/null
> +++ b/kernel/power/user_suspend_blocker.c
> @@ -0,0 +1,128 @@
> +/* kernel/power/user_suspend_block.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_blocker.h>
> +#include <linux/suspend_block_dev.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);
> +
> +struct user_suspend_blocker {
> +	struct suspend_blocker	blocker;
> +	char			name[0];
> +};
> +
> +static int create_user_suspend_blocker(struct file *file, void __user *name,
> +				 size_t name_len)
> +{
> +	struct user_suspend_blocker *bl;
> +	if (file->private_data)
> +		return -EBUSY;
> +	if (name_len > NAME_MAX)
> +		return -ENAMETOOLONG;
> +	bl = kzalloc(sizeof(*bl) + name_len + 1, GFP_KERNEL);
> +	if (!bl)
> +		return -ENOMEM;
> +	if (copy_from_user(bl->name, name, name_len))
> +		goto err_fault;
> +	suspend_blocker_init(&bl->blocker, bl->name);
> +	file->private_data = bl;

Hmm.  It doesn't seem to be possible to create two different suspend blockers
using the same file handle.  So, what exactly is a process supposed to do to
use two suspend blockers at the same time?

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.

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

[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 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Stern]

On Sun, 2 May 2010, Rafael J. Wysocki wrote:

> Hmm.  It doesn't seem to be possible to create two different suspend blockers
> using the same file handle.  So, what exactly is a process supposed to do to
> use two suspend blockers at the same time?

Open the file twice, thereby obtaining two file handles.

Alan Stern

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

[Alan Stern]

On Sun, 2 May 2010, Rafael J. Wysocki wrote:

> Hmm.  It doesn't seem to be possible to create two different suspend blockers
> using the same file handle.  So, what exactly is a process supposed to do to
> use two suspend blockers at the same time?

Open the file twice, thereby obtaining two file handles.

Alan Stern

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

[Rafael J. Wysocki]

On Sunday 02 May 2010, Alan Stern wrote:
> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> 
> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> > using the same file handle.  So, what exactly is a process supposed to do to
> > use two suspend blockers at the same time?
> 
> Open the file twice, thereby obtaining two file handles.

Well, that's what I thought.

I must admit I'm not really comfortable with this interface.  IMO it would
be better if _open() created the suspend blocker giving it a name based on
the name of the process that called it.  Something like
"<process name>_<timestamp>" might work at first sight.

Alternatively, "<process_name><number>", where <number> is 0 for the first
suspend blocker created by the given process, 1 for the second one etc., also
seems to be doable.

Rafael

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

[Rafael J. Wysocki]

On Sunday 02 May 2010, Alan Stern wrote:
> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> 
> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> > using the same file handle.  So, what exactly is a process supposed to do to
> > use two suspend blockers at the same time?
> 
> Open the file twice, thereby obtaining two file handles.

Well, that's what I thought.

I must admit I'm not really comfortable with this interface.  IMO it would
be better if _open() created the suspend blocker giving it a name based on
the name of the process that called it.  Something like
"<process name>_<timestamp>" might work at first sight.

Alternatively, "<process_name><number>", where <number> is 0 for the first
suspend blocker created by the given process, 1 for the second one etc., also
seems to be doable.

Rafael

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

[Kevin Hilman]

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

> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version fixes a race
> in suspend blocking work, has some documentation changes and
> opportunistic suspend now uses the same workqueue as runtime pm.

Earlier this month, several folks intersted in embedded PM had a BoF
as part of the Embedded Linux Conference[1] in San Francisco.  Many of
us had concerns about wakelocks/suspend-blockers and I wanted to share
some of mine here, since I don't know if embedded folks (other than
Google) were included in discussions during the LF Collab summmit.

I hope other embedded folks will chime in here as well.  My background
is in embedded as one of the kernel developers on the TI OMAP SoCs,
and I work primarily on PM stuff.

My comments are not about this implementation of suspend blockers in
particular, but rather on the potential implications of suspend
blockers in general.  

Sorry for the lengthy mail, it's broken up in to 3 parts:

- suspend blockers vs. runtime PM
- how to handle PM aware drivers?
- what about dumb or untrusted apps


Suspend blockers vs runtime PM
------------------------------

My primary concern is that suspend blockers attempt to address the
same problem(s) as runtime PM, but with a very different approach.
Suspend blockers use one very large hammer whereas runtime PM hands
out many little hammers.  Since I believe power management to be a
problem of many little nails, I think many little hammers are better
suited for the job.

Currently in the kernel, we have two main forms of PM

- static PM (system PM, traditional suspend/resume etc.)
- dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)

And with the addition of suspend blockers we have something in
between.  In my simple world, I think of suspend_blockers as static PM
with a retrofit of some basic dynamic capabilities.  In my view, a
poor man's dynamic PM.

The current design of suspend blockers was (presumably) taken due to
major limitations and/or problems in dynamic PM when it was designed.
However, since then, some very signifcant improvements in dynamic PM
have come along, particularily in the form of runtime PM.  What I
still feel is missing from this discussion are details about why the
issues addressed by suspend blockers cannot be solved with runtime PM.

It seems to me the keypad/screen example given in the doc can very
easily be solved with runtime PM.  The goal of that example is that
the keypad not turn on the screen unless a specific key is pressed.
That is rather easy to accomplish using runtime PM:
 
1. system is idle, all devices/drivers runtime suspended
   (display and keypad drivers are both runtime suspended)
-  keypress triggers wakeup ->runtime_resume() of keypad (screen is
   still runtime suspended)
-  key press trickles up to userspace
-  keypad driver is done, goes idle and is runtime supended
-  userspace decides whether or not to turn on screen based on key
-  if not, goto 1, (display is still runtime suspended)
-  if so, start using display and it will be runtime resumed

I realize this keypad example was only one example usage of suspend
blockers, but I suspect the others would be solved similarily using
runtime PM.

But anyways, to get back to the main point: 

I feel the main problems tackled by _kernel_ suspend blockers (as I
understand them) are the same problems already addressed by runtime
PM.  First and formost, both have the same guiding principle:

  Rule #1: Always try for lowest power state, unless X

For runtime PM, X = "activity"
For suspend blockers, X = a held suspend_blocker

In addition, both have the same secondary goals:

- keep device PM independent of other devices (e.g. don't wake up
  screen just because keypad was pressed)

- wakeups/events can be handled in a device specific way, without
  affecting other devices or rest of the system, unless desired

So, the goals are the same, but the approaches are different.  Runtime
PM makes each of the drivers and subsystems do the work, where suspend
blockers just forces the issue from on high.  IMHO, the more flexible
and generic approach of runtime PM is more suited to a general purpose
kernel than the one-big-hammer approach currently taken by suspend
blockers.


What about PM aware drivers?
----------------------------

All of this brings up a second major concern regarding how to write PM
aware drivers.

At least from the kernel perspective, both suspend blockers and
runtime PM have the same goal.  Given that, which framework should the
driver writer target?  Both?  Seems like duplicate effort.  Using
suspend blockers assumes the system is in opportunitstic suspend mode
and (at least in the keypad example given) assumes a suspend-blocker
aware userspace (Android.) Without both, targeted power savings will
not be acheived.

To me, runtime PM is a generic and flexible approach that can be used
with any userspace.  Driver writers should not have to care whether
the system is in "opportunistic" mode or about whether userspace is
suspend blocker capable.  They should only have to think about when
the device is (or should be) idle.

>From my experience with OMAP, we *really* do not want to care about
what userspace is or isn't capable of, or what suspend-mode the kernel
is in.  Among other things, the OMAP linux kernel is used in the Nokia
N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
Comments on the future of each SW stack aside, we really want to run
the same kernel and drivers across all of those platforms as well as
whatever comes next.


What about dumb or untrusted apps?
---------------------------------------

In my view, the truly significant difference between suspend blockers
and runtime PM is what happens to userspace.  So far, to me the only
compelling argument for suspend blockers is the goal of forcibly
shutting down userspace and thus forcing the system into idle
(although drivers could still reject a suspend request.)

Again, since suspend blockers were designed, there have been major
efforts to track and fix userspace as well as underlying timer issues
(deferrable timers, coalescing, timer slack ...) that led to
unnecessary wakeups from userspace.  Wouldn't it be better to spend
our collective efforts in continuing in that direction instead of just
hiding the underlying problems by forcing suspend?  Fixing the root
causes will be better for everyone, not just those using Android.

And if untrusted userspace apps remain as the major problem, maybe we
should aim for a solution directly targetting that problem.  I'm just
shooting from the hip now, but maybe containing (cgroups?) untrusted
processes together into a set that could be frozen/idled so that runtime PM
would be more effective would be a workable solution?

Anyways, that's enough rambling for now.  I hope that sheds some light
on the concerns I have with suspend blockers.

Kevin

[1] http://embeddedlinuxconference.com/elc_2010/index.html

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

[Kevin Hilman]

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

> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version fixes a race
> in suspend blocking work, has some documentation changes and
> opportunistic suspend now uses the same workqueue as runtime pm.

Earlier this month, several folks intersted in embedded PM had a BoF
as part of the Embedded Linux Conference[1] in San Francisco.  Many of
us had concerns about wakelocks/suspend-blockers and I wanted to share
some of mine here, since I don't know if embedded folks (other than
Google) were included in discussions during the LF Collab summmit.

I hope other embedded folks will chime in here as well.  My background
is in embedded as one of the kernel developers on the TI OMAP SoCs,
and I work primarily on PM stuff.

My comments are not about this implementation of suspend blockers in
particular, but rather on the potential implications of suspend
blockers in general.  

Sorry for the lengthy mail, it's broken up in to 3 parts:

- suspend blockers vs. runtime PM
- how to handle PM aware drivers?
- what about dumb or untrusted apps


Suspend blockers vs runtime PM
------------------------------

My primary concern is that suspend blockers attempt to address the
same problem(s) as runtime PM, but with a very different approach.
Suspend blockers use one very large hammer whereas runtime PM hands
out many little hammers.  Since I believe power management to be a
problem of many little nails, I think many little hammers are better
suited for the job.

Currently in the kernel, we have two main forms of PM

- static PM (system PM, traditional suspend/resume etc.)
- dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)

And with the addition of suspend blockers we have something in
between.  In my simple world, I think of suspend_blockers as static PM
with a retrofit of some basic dynamic capabilities.  In my view, a
poor man's dynamic PM.

The current design of suspend blockers was (presumably) taken due to
major limitations and/or problems in dynamic PM when it was designed.
However, since then, some very signifcant improvements in dynamic PM
have come along, particularily in the form of runtime PM.  What I
still feel is missing from this discussion are details about why the
issues addressed by suspend blockers cannot be solved with runtime PM.

It seems to me the keypad/screen example given in the doc can very
easily be solved with runtime PM.  The goal of that example is that
the keypad not turn on the screen unless a specific key is pressed.
That is rather easy to accomplish using runtime PM:
 
1. system is idle, all devices/drivers runtime suspended
   (display and keypad drivers are both runtime suspended)
-  keypress triggers wakeup ->runtime_resume() of keypad (screen is
   still runtime suspended)
-  key press trickles up to userspace
-  keypad driver is done, goes idle and is runtime supended
-  userspace decides whether or not to turn on screen based on key
-  if not, goto 1, (display is still runtime suspended)
-  if so, start using display and it will be runtime resumed

I realize this keypad example was only one example usage of suspend
blockers, but I suspect the others would be solved similarily using
runtime PM.

But anyways, to get back to the main point: 

I feel the main problems tackled by _kernel_ suspend blockers (as I
understand them) are the same problems already addressed by runtime
PM.  First and formost, both have the same guiding principle:

  Rule #1: Always try for lowest power state, unless X

For runtime PM, X = "activity"
For suspend blockers, X = a held suspend_blocker

In addition, both have the same secondary goals:

- keep device PM independent of other devices (e.g. don't wake up
  screen just because keypad was pressed)

- wakeups/events can be handled in a device specific way, without
  affecting other devices or rest of the system, unless desired

So, the goals are the same, but the approaches are different.  Runtime
PM makes each of the drivers and subsystems do the work, where suspend
blockers just forces the issue from on high.  IMHO, the more flexible
and generic approach of runtime PM is more suited to a general purpose
kernel than the one-big-hammer approach currently taken by suspend
blockers.


What about PM aware drivers?
----------------------------

All of this brings up a second major concern regarding how to write PM
aware drivers.

At least from the kernel perspective, both suspend blockers and
runtime PM have the same goal.  Given that, which framework should the
driver writer target?  Both?  Seems like duplicate effort.  Using
suspend blockers assumes the system is in opportunitstic suspend mode
and (at least in the keypad example given) assumes a suspend-blocker
aware userspace (Android.) Without both, targeted power savings will
not be acheived.

To me, runtime PM is a generic and flexible approach that can be used
with any userspace.  Driver writers should not have to care whether
the system is in "opportunistic" mode or about whether userspace is
suspend blocker capable.  They should only have to think about when
the device is (or should be) idle.

>From my experience with OMAP, we *really* do not want to care about
what userspace is or isn't capable of, or what suspend-mode the kernel
is in.  Among other things, the OMAP linux kernel is used in the Nokia
N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
Comments on the future of each SW stack aside, we really want to run
the same kernel and drivers across all of those platforms as well as
whatever comes next.


What about dumb or untrusted apps?
---------------------------------------

In my view, the truly significant difference between suspend blockers
and runtime PM is what happens to userspace.  So far, to me the only
compelling argument for suspend blockers is the goal of forcibly
shutting down userspace and thus forcing the system into idle
(although drivers could still reject a suspend request.)

Again, since suspend blockers were designed, there have been major
efforts to track and fix userspace as well as underlying timer issues
(deferrable timers, coalescing, timer slack ...) that led to
unnecessary wakeups from userspace.  Wouldn't it be better to spend
our collective efforts in continuing in that direction instead of just
hiding the underlying problems by forcing suspend?  Fixing the root
causes will be better for everyone, not just those using Android.

And if untrusted userspace apps remain as the major problem, maybe we
should aim for a solution directly targetting that problem.  I'm just
shooting from the hip now, but maybe containing (cgroups?) untrusted
processes together into a set that could be frozen/idled so that runtime PM
would be more effective would be a workable solution?

Anyways, that's enough rambling for now.  I hope that sheds some light
on the concerns I have with suspend blockers.

Kevin

[1] http://embeddedlinuxconference.com/elc_2010/index.html

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

[Alan Stern]

On Mon, 3 May 2010, Kevin Hilman wrote:

> Suspend blockers vs runtime PM
> ------------------------------
> 
> My primary concern is that suspend blockers attempt to address the
> same problem(s) as runtime PM, but with a very different approach.
> Suspend blockers use one very large hammer whereas runtime PM hands
> out many little hammers.  Since I believe power management to be a
> problem of many little nails, I think many little hammers are better
> suited for the job.

There is a major difference between suspend blockers and runtime PM 
which was not discussed in your email.  Namely: Runtime PM is aimed at 
suspending individual devices and not the system as a whole (in 
particular, not CPUs), whereas suspend blockers are aimed at suspending 
-- or more accurately, blocking suspends -- of the system as a whole 
and not individual devices.

So for example, runtime PM cannot be used to put the system into an S3 
sleep state.  But suspend blockers _are_ used to keep the system from 
going into S3.

> Currently in the kernel, we have two main forms of PM
> 
> - static PM (system PM, traditional suspend/resume etc.)
> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
> 
> And with the addition of suspend blockers we have something in
> between.  In my simple world, I think of suspend_blockers as static PM
> with a retrofit of some basic dynamic capabilities.  In my view, a
> poor man's dynamic PM.

I wouldn't describe it like that.  Consider dividing PM along a 
different axis:

- entire system (ACPI sleep states, CPUs turned off, etc.)
- single, independent devices (e.g., USB autosuspend)

Then system PM combines static + entire, whereas runtime PM combines 
dynamic + single.  By contrast, suspend blockers are aimed at the 
dynamic + entire combination.  This makes them different from anything 
already present in the kernel.

> The current design of suspend blockers was (presumably) taken due to
> major limitations and/or problems in dynamic PM when it was designed.
> However, since then, some very signifcant improvements in dynamic PM
> have come along, particularily in the form of runtime PM.  What I
> still feel is missing from this discussion are details about why the
> issues addressed by suspend blockers cannot be solved with runtime PM.

The simplest example is that suspend blockers can be used to control 
whether or not the CPU shuts down, whereas runtime PM can't.

> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.
> 
> From my experience with OMAP, we *really* do not want to care about
> what userspace is or isn't capable of, or what suspend-mode the kernel
> is in.  Among other things, the OMAP linux kernel is used in the Nokia
> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
> Comments on the future of each SW stack aside, we really want to run
> the same kernel and drivers across all of those platforms as well as
> whatever comes next.

That is indeed a weak point of the proposal.  Kernel drivers' use of
suspend blockers appears to be somewhat arbitrary and directed by the
needs of userspace.  It's not at all clear how drivers can use suspend
blockers in a way that will work on all systems.

Alan Stern

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

[Alan Stern]

On Mon, 3 May 2010, Kevin Hilman wrote:

> Suspend blockers vs runtime PM
> ------------------------------
> 
> My primary concern is that suspend blockers attempt to address the
> same problem(s) as runtime PM, but with a very different approach.
> Suspend blockers use one very large hammer whereas runtime PM hands
> out many little hammers.  Since I believe power management to be a
> problem of many little nails, I think many little hammers are better
> suited for the job.

There is a major difference between suspend blockers and runtime PM 
which was not discussed in your email.  Namely: Runtime PM is aimed at 
suspending individual devices and not the system as a whole (in 
particular, not CPUs), whereas suspend blockers are aimed at suspending 
-- or more accurately, blocking suspends -- of the system as a whole 
and not individual devices.

So for example, runtime PM cannot be used to put the system into an S3 
sleep state.  But suspend blockers _are_ used to keep the system from 
going into S3.

> Currently in the kernel, we have two main forms of PM
> 
> - static PM (system PM, traditional suspend/resume etc.)
> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
> 
> And with the addition of suspend blockers we have something in
> between.  In my simple world, I think of suspend_blockers as static PM
> with a retrofit of some basic dynamic capabilities.  In my view, a
> poor man's dynamic PM.

I wouldn't describe it like that.  Consider dividing PM along a 
different axis:

- entire system (ACPI sleep states, CPUs turned off, etc.)
- single, independent devices (e.g., USB autosuspend)

Then system PM combines static + entire, whereas runtime PM combines 
dynamic + single.  By contrast, suspend blockers are aimed at the 
dynamic + entire combination.  This makes them different from anything 
already present in the kernel.

> The current design of suspend blockers was (presumably) taken due to
> major limitations and/or problems in dynamic PM when it was designed.
> However, since then, some very signifcant improvements in dynamic PM
> have come along, particularily in the form of runtime PM.  What I
> still feel is missing from this discussion are details about why the
> issues addressed by suspend blockers cannot be solved with runtime PM.

The simplest example is that suspend blockers can be used to control 
whether or not the CPU shuts down, whereas runtime PM can't.

> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.
> 
> From my experience with OMAP, we *really* do not want to care about
> what userspace is or isn't capable of, or what suspend-mode the kernel
> is in.  Among other things, the OMAP linux kernel is used in the Nokia
> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
> Comments on the future of each SW stack aside, we really want to run
> the same kernel and drivers across all of those platforms as well as
> whatever comes next.

That is indeed a weak point of the proposal.  Kernel drivers' use of
suspend blockers appears to be somewhat arbitrary and directed by the
needs of userspace.  It's not at all clear how drivers can use suspend
blockers in a way that will work on all systems.

Alan Stern

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

[Mark Brown]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> At least from the kernel perspective, both suspend blockers and
> runtime PM have the same goal.  Given that, which framework should the
> driver writer target?  Both?  Seems like duplicate effort.  Using
> suspend blockers assumes the system is in opportunitstic suspend mode
> and (at least in the keypad example given) assumes a suspend-blocker
> aware userspace (Android.) Without both, targeted power savings will
> not be acheived.

The other concern here is that for many mobile systems the actual
semantic intended by "suspend" as it's currently used is more runtime PM
like than full suspend - the classic example of this is that when
suspending while on a call in a phone you don't want to suspend the
modem or audio CODEC, you want to leave them running.  If you use a full
system suspend then the drivers for affected components have to play
guessing games (or add currently non-standard knobs for apps to twiddle)
to decide if the system intends them to actually implement the suspend
or not but with runtime PM it all falls out very naturally without any
effort on the part of the driver.

> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.

I fully agree with this.  We do need to ensure that a runtime PM based
system can suspend the CPU core and RAM as well as system suspend can
but that seems doable.

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

[Mark Brown]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> At least from the kernel perspective, both suspend blockers and
> runtime PM have the same goal.  Given that, which framework should the
> driver writer target?  Both?  Seems like duplicate effort.  Using
> suspend blockers assumes the system is in opportunitstic suspend mode
> and (at least in the keypad example given) assumes a suspend-blocker
> aware userspace (Android.) Without both, targeted power savings will
> not be acheived.

The other concern here is that for many mobile systems the actual
semantic intended by "suspend" as it's currently used is more runtime PM
like than full suspend - the classic example of this is that when
suspending while on a call in a phone you don't want to suspend the
modem or audio CODEC, you want to leave them running.  If you use a full
system suspend then the drivers for affected components have to play
guessing games (or add currently non-standard knobs for apps to twiddle)
to decide if the system intends them to actually implement the suspend
or not but with runtime PM it all falls out very naturally without any
effort on the part of the driver.

> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.

I fully agree with this.  We do need to ensure that a runtime PM based
system can suspend the CPU core and RAM as well as system suspend can
but that seems doable.

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Mon, 3 May 2010, Kevin Hilman wrote:
>
>> Suspend blockers vs runtime PM
>> ------------------------------
>> 
>> My primary concern is that suspend blockers attempt to address the
>> same problem(s) as runtime PM, but with a very different approach.
>> Suspend blockers use one very large hammer whereas runtime PM hands
>> out many little hammers.  Since I believe power management to be a
>> problem of many little nails, I think many little hammers are better
>> suited for the job.
>
> There is a major difference between suspend blockers and runtime PM 
> which was not discussed in your email.  Namely: Runtime PM is aimed at 
> suspending individual devices and not the system as a whole (in 
> particular, not CPUs), whereas suspend blockers are aimed at suspending 
> -- or more accurately, blocking suspends -- of the system as a whole 
> and not individual devices.
>
> So for example, runtime PM cannot be used to put the system into an S3 
> sleep state.  But suspend blockers _are_ used to keep the system from 
> going into S3.

Good point.  However, adding CPUidle to runtime PM you indeed achieve
a dynamic PM that affects the whole system. 

The main difference then comes down to what prevents system-wide
low-power state: activity vs. suspend blocker held.

>> Currently in the kernel, we have two main forms of PM
>> 
>> - static PM (system PM, traditional suspend/resume etc.)
>> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
>> 
>> And with the addition of suspend blockers we have something in
>> between.  In my simple world, I think of suspend_blockers as static PM
>> with a retrofit of some basic dynamic capabilities.  In my view, a
>> poor man's dynamic PM.
>
> I wouldn't describe it like that.  Consider dividing PM along a 
> different axis:
>
> - entire system (ACPI sleep states, CPUs turned off, etc.)
> - single, independent devices (e.g., USB autosuspend)
>
> Then system PM combines static + entire, whereas runtime PM combines 
> dynamic + single.  By contrast, suspend blockers are aimed at the 
> dynamic + entire combination.  This makes them different from anything 
> already present in the kernel.

Adding CPUidle to runtime PM (dynamic + single), you add 'entire' as
well, as CPUidle manages the CPU states.

However, one problem I have with your proposed division is it doesn't
seem to match well to the hardware available on modern embedded SoCs,
mainly because these are not ACPI devices.  The CPU is just another
"independent" device whose runtime PM is managed by CPUidle.

IOW, The 'entire system' state is just a function of the CPU state
and the state of all the on- and off-chip devices.  With CPUidle
managing the CPUs, and runtime PM managing the rest of the devices,
you have a fully flexible dynamic PM for the entire system.

>> The current design of suspend blockers was (presumably) taken due to
>> major limitations and/or problems in dynamic PM when it was designed.
>> However, since then, some very signifcant improvements in dynamic PM
>> have come along, particularily in the form of runtime PM.  What I
>> still feel is missing from this discussion are details about why the
>> issues addressed by suspend blockers cannot be solved with runtime PM.
>
> The simplest example is that suspend blockers can be used to control 
> whether or not the CPU shuts down, whereas runtime PM can't.

True, by iteslf, runtime PM does not shut down CPUs, but in
combination with CPUidle the CPU(s) can be shut down based on
activity.  In a way, you could think of CPUidle as runtime PM for the
CPU(s).

Again, the primary difference comes down to: why should I not enter a
low-power state?  activity (runtime PM + CPUidle) or suspend blocker.

>> To me, runtime PM is a generic and flexible approach that can be used
>> with any userspace.  Driver writers should not have to care whether
>> the system is in "opportunistic" mode or about whether userspace is
>> suspend blocker capable.  They should only have to think about when
>> the device is (or should be) idle.
>> 
>> From my experience with OMAP, we *really* do not want to care about
>> what userspace is or isn't capable of, or what suspend-mode the kernel
>> is in.  Among other things, the OMAP linux kernel is used in the Nokia
>> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
>> Comments on the future of each SW stack aside, we really want to run
>> the same kernel and drivers across all of those platforms as well as
>> whatever comes next.
>
> That is indeed a weak point of the proposal.  Kernel drivers' use of
> suspend blockers appears to be somewhat arbitrary and directed by the
> needs of userspace.  It's not at all clear how drivers can use suspend
> blockers in a way that will work on all systems.

Nor is it clear (to me) what drivers would/should look like that would
need to do suspend blockers in addition to runtime PM.  

Kevin

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Mon, 3 May 2010, Kevin Hilman wrote:
>
>> Suspend blockers vs runtime PM
>> ------------------------------
>> 
>> My primary concern is that suspend blockers attempt to address the
>> same problem(s) as runtime PM, but with a very different approach.
>> Suspend blockers use one very large hammer whereas runtime PM hands
>> out many little hammers.  Since I believe power management to be a
>> problem of many little nails, I think many little hammers are better
>> suited for the job.
>
> There is a major difference between suspend blockers and runtime PM 
> which was not discussed in your email.  Namely: Runtime PM is aimed at 
> suspending individual devices and not the system as a whole (in 
> particular, not CPUs), whereas suspend blockers are aimed at suspending 
> -- or more accurately, blocking suspends -- of the system as a whole 
> and not individual devices.
>
> So for example, runtime PM cannot be used to put the system into an S3 
> sleep state.  But suspend blockers _are_ used to keep the system from 
> going into S3.

Good point.  However, adding CPUidle to runtime PM you indeed achieve
a dynamic PM that affects the whole system. 

The main difference then comes down to what prevents system-wide
low-power state: activity vs. suspend blocker held.

>> Currently in the kernel, we have two main forms of PM
>> 
>> - static PM (system PM, traditional suspend/resume etc.)
>> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
>> 
>> And with the addition of suspend blockers we have something in
>> between.  In my simple world, I think of suspend_blockers as static PM
>> with a retrofit of some basic dynamic capabilities.  In my view, a
>> poor man's dynamic PM.
>
> I wouldn't describe it like that.  Consider dividing PM along a 
> different axis:
>
> - entire system (ACPI sleep states, CPUs turned off, etc.)
> - single, independent devices (e.g., USB autosuspend)
>
> Then system PM combines static + entire, whereas runtime PM combines 
> dynamic + single.  By contrast, suspend blockers are aimed at the 
> dynamic + entire combination.  This makes them different from anything 
> already present in the kernel.

Adding CPUidle to runtime PM (dynamic + single), you add 'entire' as
well, as CPUidle manages the CPU states.

However, one problem I have with your proposed division is it doesn't
seem to match well to the hardware available on modern embedded SoCs,
mainly because these are not ACPI devices.  The CPU is just another
"independent" device whose runtime PM is managed by CPUidle.

IOW, The 'entire system' state is just a function of the CPU state
and the state of all the on- and off-chip devices.  With CPUidle
managing the CPUs, and runtime PM managing the rest of the devices,
you have a fully flexible dynamic PM for the entire system.

>> The current design of suspend blockers was (presumably) taken due to
>> major limitations and/or problems in dynamic PM when it was designed.
>> However, since then, some very signifcant improvements in dynamic PM
>> have come along, particularily in the form of runtime PM.  What I
>> still feel is missing from this discussion are details about why the
>> issues addressed by suspend blockers cannot be solved with runtime PM.
>
> The simplest example is that suspend blockers can be used to control 
> whether or not the CPU shuts down, whereas runtime PM can't.

True, by iteslf, runtime PM does not shut down CPUs, but in
combination with CPUidle the CPU(s) can be shut down based on
activity.  In a way, you could think of CPUidle as runtime PM for the
CPU(s).

Again, the primary difference comes down to: why should I not enter a
low-power state?  activity (runtime PM + CPUidle) or suspend blocker.

>> To me, runtime PM is a generic and flexible approach that can be used
>> with any userspace.  Driver writers should not have to care whether
>> the system is in "opportunistic" mode or about whether userspace is
>> suspend blocker capable.  They should only have to think about when
>> the device is (or should be) idle.
>> 
>> From my experience with OMAP, we *really* do not want to care about
>> what userspace is or isn't capable of, or what suspend-mode the kernel
>> is in.  Among other things, the OMAP linux kernel is used in the Nokia
>> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
>> Comments on the future of each SW stack aside, we really want to run
>> the same kernel and drivers across all of those platforms as well as
>> whatever comes next.
>
> That is indeed a weak point of the proposal.  Kernel drivers' use of
> suspend blockers appears to be somewhat arbitrary and directed by the
> needs of userspace.  It's not at all clear how drivers can use suspend
> blockers in a way that will work on all systems.

Nor is it clear (to me) what drivers would/should look like that would
need to do suspend blockers in addition to runtime PM.  

Kevin

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.

[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 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Monday 03 May 2010, Mark Brown wrote:
> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> 
> > At least from the kernel perspective, both suspend blockers and
> > runtime PM have the same goal.  Given that, which framework should the
> > driver writer target?  Both?  Seems like duplicate effort.  Using
> > suspend blockers assumes the system is in opportunitstic suspend mode
> > and (at least in the keypad example given) assumes a suspend-blocker
> > aware userspace (Android.) Without both, targeted power savings will
> > not be acheived.
> 
> The other concern here is that for many mobile systems the actual
> semantic intended by "suspend" as it's currently used is more runtime PM
> like than full suspend - the classic example of this is that when
> suspending while on a call in a phone you don't want to suspend the
> modem or audio CODEC, you want to leave them running.  If you use a full
> system suspend then the drivers for affected components have to play
> guessing games (or add currently non-standard knobs for apps to twiddle)
> to decide if the system intends them to actually implement the suspend
> or not but with runtime PM it all falls out very naturally without any
> effort on the part of the driver.
> 
> > To me, runtime PM is a generic and flexible approach that can be used
> > with any userspace.  Driver writers should not have to care whether
> > the system is in "opportunistic" mode or about whether userspace is
> > suspend blocker capable.  They should only have to think about when
> > the device is (or should be) idle.
> 
> I fully agree with this.  We do need to ensure that a runtime PM based
> system can suspend the CPU core and RAM as well as system suspend can
> but that seems doable.

I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
all AFAICS.

However, the real question is whether or not the opportunistic suspend feature
is worth adding to the kernel as such and I think it is.

To me, it doesn't duplicate the runtime PM framework which is aimed at the power
management of individual devices rather than the system as a whole.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Monday 03 May 2010, Mark Brown wrote:
> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> 
> > At least from the kernel perspective, both suspend blockers and
> > runtime PM have the same goal.  Given that, which framework should the
> > driver writer target?  Both?  Seems like duplicate effort.  Using
> > suspend blockers assumes the system is in opportunitstic suspend mode
> > and (at least in the keypad example given) assumes a suspend-blocker
> > aware userspace (Android.) Without both, targeted power savings will
> > not be acheived.
> 
> The other concern here is that for many mobile systems the actual
> semantic intended by "suspend" as it's currently used is more runtime PM
> like than full suspend - the classic example of this is that when
> suspending while on a call in a phone you don't want to suspend the
> modem or audio CODEC, you want to leave them running.  If you use a full
> system suspend then the drivers for affected components have to play
> guessing games (or add currently non-standard knobs for apps to twiddle)
> to decide if the system intends them to actually implement the suspend
> or not but with runtime PM it all falls out very naturally without any
> effort on the part of the driver.
> 
> > To me, runtime PM is a generic and flexible approach that can be used
> > with any userspace.  Driver writers should not have to care whether
> > the system is in "opportunistic" mode or about whether userspace is
> > suspend blocker capable.  They should only have to think about when
> > the device is (or should be) idle.
> 
> I fully agree with this.  We do need to ensure that a runtime PM based
> system can suspend the CPU core and RAM as well as system suspend can
> but that seems doable.

I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
all AFAICS.

However, the real question is whether or not the opportunistic suspend feature
is worth adding to the kernel as such and I think it is.

To me, it doesn't duplicate the runtime PM framework which is aimed at the power
management of individual devices rather than the system as a whole.

Thanks,
Rafael

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

[Arve Hjønnevåg]

On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Sunday 02 May 2010, Alan Stern wrote:
>> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
>>
>> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
>> > using the same file handle.  So, what exactly is a process supposed to do to
>> > use two suspend blockers at the same time?
>>
>> Open the file twice, thereby obtaining two file handles.
>
> Well, that's what I thought.
>
> I must admit I'm not really comfortable with this interface.  IMO it would
> be better if _open() created the suspend blocker giving it a name based on
> the name of the process that called it.  Something like
> "<process name>_<timestamp>" might work at first sight.
>
> Alternatively, "<process_name><number>", where <number> is 0 for the first
> suspend blocker created by the given process, 1 for the second one etc., also
> seems to be doable.

I think it is important to let user-space specify the name. If a
process uses multiple suspend blockers, it is impossible to tell what
each one is used for if they are automatically named.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Sunday 02 May 2010, Alan Stern wrote:
>> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
>>
>> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
>> > using the same file handle.  So, what exactly is a process supposed to do to
>> > use two suspend blockers at the same time?
>>
>> Open the file twice, thereby obtaining two file handles.
>
> Well, that's what I thought.
>
> I must admit I'm not really comfortable with this interface.  IMO it would
> be better if _open() created the suspend blocker giving it a name based on
> the name of the process that called it.  Something like
> "<process name>_<timestamp>" might work at first sight.
>
> Alternatively, "<process_name><number>", where <number> is 0 for the first
> suspend blocker created by the given process, 1 for the second one etc., also
> seems to be doable.

I think it is important to let user-space specify the name. If a
process uses multiple suspend blockers, it is impossible to tell what
each one is used for if they are automatically named.

-- 
Arve Hjønnevåg

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.

[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 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Monday 03 May 2010, Arve Hjønnevåg wrote:
> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Sunday 02 May 2010, Alan Stern wrote:
> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> >>
> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> >> > using the same file handle.  So, what exactly is a process supposed to do to
> >> > use two suspend blockers at the same time?
> >>
> >> Open the file twice, thereby obtaining two file handles.
> >
> > Well, that's what I thought.
> >
> > I must admit I'm not really comfortable with this interface.  IMO it would
> > be better if _open() created the suspend blocker giving it a name based on
> > the name of the process that called it.  Something like
> > "<process name>_<timestamp>" might work at first sight.
> >
> > Alternatively, "<process_name><number>", where <number> is 0 for the first
> > suspend blocker created by the given process, 1 for the second one etc., also
> > seems to be doable.
> 
> I think it is important to let user-space specify the name. If a
> process uses multiple suspend blockers, it is impossible to tell what
> each one is used for if they are automatically named.

Well, the problem is the only purpose of this is user space debugging, isn't it?

Now, while I don't think it's generally bad to provide kernel interfaces
helping to debug user space, I'm not quite sure if that should be done at the
expense of the clarity of kernel-user space interfaces.

I wonder how many cases there are in which distinguishing between suspend
blockers used by the same user space task is practically relevant.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Monday 03 May 2010, Arve Hjønnevåg wrote:
> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Sunday 02 May 2010, Alan Stern wrote:
> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> >>
> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> >> > using the same file handle.  So, what exactly is a process supposed to do to
> >> > use two suspend blockers at the same time?
> >>
> >> Open the file twice, thereby obtaining two file handles.
> >
> > Well, that's what I thought.
> >
> > I must admit I'm not really comfortable with this interface.  IMO it would
> > be better if _open() created the suspend blocker giving it a name based on
> > the name of the process that called it.  Something like
> > "<process name>_<timestamp>" might work at first sight.
> >
> > Alternatively, "<process_name><number>", where <number> is 0 for the first
> > suspend blocker created by the given process, 1 for the second one etc., also
> > seems to be doable.
> 
> I think it is important to let user-space specify the name. If a
> process uses multiple suspend blockers, it is impossible to tell what
> each one is used for if they are automatically named.

Well, the problem is the only purpose of this is user space debugging, isn't it?

Now, while I don't think it's generally bad to provide kernel interfaces
helping to debug user space, I'm not quite sure if that should be done at the
expense of the clarity of kernel-user space interfaces.

I wonder how many cases there are in which distinguishing between suspend
blockers used by the same user space task is practically relevant.

Thanks,
Rafael

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

[Matthew Garrett]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace.  So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)

I'd say that this is certainly the main issue, though the remaining 
periodic timers in the kernel are also inconvenient.

> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem.  I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?

I considered this. The problem is that not all of your wakeup events 
pass through trusted code. Assume we've used a freezer cgroup and the 
applications are now frozen. One of them is blocking on a network 
socket. A packet arrives and triggers a wakeup of the hardware. How do 
we unfreeze the userspace app?

I agree that the runtime scenario is a far more appealing one from an 
aesthetic standpoint, but so far we don't have a very compelling 
argument for dealing with the starting and stopping of userspace. The 
use-cases that Google have provided are valid and they have an 
implementation that addresses them, and while we're unable to provide an 
alternative that provides the same level of functionality I think we're 
in a poor position to prevent this from going in.

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

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

[Matthew Garrett]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace.  So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)

I'd say that this is certainly the main issue, though the remaining 
periodic timers in the kernel are also inconvenient.

> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem.  I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?

I considered this. The problem is that not all of your wakeup events 
pass through trusted code. Assume we've used a freezer cgroup and the 
applications are now frozen. One of them is blocking on a network 
socket. A packet arrives and triggers a wakeup of the hardware. How do 
we unfreeze the userspace app?

I agree that the runtime scenario is a far more appealing one from an 
aesthetic standpoint, but so far we don't have a very compelling 
argument for dealing with the starting and stopping of userspace. The 
use-cases that Google have provided are valid and they have an 
implementation that addresses them, and while we're unable to provide an 
alternative that provides the same level of functionality I think we're 
in a poor position to prevent this from going in.

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

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

[Arve Hjønnevåg]

2010/5/3 Rafael J. Wysocki <rjw@sisk.pl>:
> On Monday 03 May 2010, Arve Hjønnevåg wrote:
>> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Sunday 02 May 2010, Alan Stern wrote:
>> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
>> >>
>> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
>> >> > using the same file handle.  So, what exactly is a process supposed to do to
>> >> > use two suspend blockers at the same time?
>> >>
>> >> Open the file twice, thereby obtaining two file handles.
>> >
>> > Well, that's what I thought.
>> >
>> > I must admit I'm not really comfortable with this interface.  IMO it would
>> > be better if _open() created the suspend blocker giving it a name based on
>> > the name of the process that called it.  Something like
>> > "<process name>_<timestamp>" might work at first sight.
>> >
>> > Alternatively, "<process_name><number>", where <number> is 0 for the first
>> > suspend blocker created by the given process, 1 for the second one etc., also
>> > seems to be doable.
>>
>> I think it is important to let user-space specify the name. If a
>> process uses multiple suspend blockers, it is impossible to tell what
>> each one is used for if they are automatically named.
>
> Well, the problem is the only purpose of this is user space debugging, isn't it?
>
At the moment, yes. But having an explicit init call also simplifies
future expansion. If we ever need to add back multiple types of
suspend blockers, we can add an init call with a type argument and
have the current init call use the default type. If the past we have
had types that keeps the screen on and prevented idle sleep modes. In
the future we could for instance want to specify if a suspend blocker
should prevent suspend when the battery is low or when the lid is
closed.

> Now, while I don't think it's generally bad to provide kernel interfaces
> helping to debug user space, I'm not quite sure if that should be done at the
> expense of the clarity of kernel-user space interfaces.
>
> I wonder how many cases there are in which distinguishing between suspend
> blockers used by the same user space task is practically relevant.
>

I think all of them (when more than one suspend blocker is used).

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/5/3 Rafael J. Wysocki <rjw@sisk.pl>:
> On Monday 03 May 2010, Arve Hjønnevåg wrote:
>> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Sunday 02 May 2010, Alan Stern wrote:
>> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
>> >>
>> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
>> >> > using the same file handle.  So, what exactly is a process supposed to do to
>> >> > use two suspend blockers at the same time?
>> >>
>> >> Open the file twice, thereby obtaining two file handles.
>> >
>> > Well, that's what I thought.
>> >
>> > I must admit I'm not really comfortable with this interface.  IMO it would
>> > be better if _open() created the suspend blocker giving it a name based on
>> > the name of the process that called it.  Something like
>> > "<process name>_<timestamp>" might work at first sight.
>> >
>> > Alternatively, "<process_name><number>", where <number> is 0 for the first
>> > suspend blocker created by the given process, 1 for the second one etc., also
>> > seems to be doable.
>>
>> I think it is important to let user-space specify the name. If a
>> process uses multiple suspend blockers, it is impossible to tell what
>> each one is used for if they are automatically named.
>
> Well, the problem is the only purpose of this is user space debugging, isn't it?
>
At the moment, yes. But having an explicit init call also simplifies
future expansion. If we ever need to add back multiple types of
suspend blockers, we can add an init call with a type argument and
have the current init call use the default type. If the past we have
had types that keeps the screen on and prevented idle sleep modes. In
the future we could for instance want to specify if a suspend blocker
should prevent suspend when the battery is low or when the lid is
closed.

> Now, while I don't think it's generally bad to provide kernel interfaces
> helping to debug user space, I'm not quite sure if that should be done at the
> expense of the clarity of kernel-user space interfaces.
>
> I wonder how many cases there are in which distinguishing between suspend
> blockers used by the same user space task is practically relevant.
>

I think all of them (when more than one suspend blocker is used).

-- 
Arve Hjønnevåg

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.

[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

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

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

[Kevin Hilman]

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

> On Monday 03 May 2010, Mark Brown wrote:
>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
>> 
>> > At least from the kernel perspective, both suspend blockers and
>> > runtime PM have the same goal.  Given that, which framework should the
>> > driver writer target?  Both?  Seems like duplicate effort.  Using
>> > suspend blockers assumes the system is in opportunitstic suspend mode
>> > and (at least in the keypad example given) assumes a suspend-blocker
>> > aware userspace (Android.) Without both, targeted power savings will
>> > not be acheived.
>> 
>> The other concern here is that for many mobile systems the actual
>> semantic intended by "suspend" as it's currently used is more runtime PM
>> like than full suspend - the classic example of this is that when
>> suspending while on a call in a phone you don't want to suspend the
>> modem or audio CODEC, you want to leave them running.  If you use a full
>> system suspend then the drivers for affected components have to play
>> guessing games (or add currently non-standard knobs for apps to twiddle)
>> to decide if the system intends them to actually implement the suspend
>> or not but with runtime PM it all falls out very naturally without any
>> effort on the part of the driver.
>> 
>> > To me, runtime PM is a generic and flexible approach that can be used
>> > with any userspace.  Driver writers should not have to care whether
>> > the system is in "opportunistic" mode or about whether userspace is
>> > suspend blocker capable.  They should only have to think about when
>> > the device is (or should be) idle.
>> 
>> I fully agree with this.  We do need to ensure that a runtime PM based
>> system can suspend the CPU core and RAM as well as system suspend can
>> but that seems doable.
>
> I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
> all AFAICS.

Please forgive the ignorance of ACPI (in embedded, we thankfully live
in magical world without ACPI) but doesn't that already happen with
CPUidle and C-states?  I think of CPUidle as basically runtime PM for
the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
(via C-states), resulting in dynaimc PM for the entire system.  What
am I missing?

> However, the real question is whether or not the opportunistic suspend feature
> is worth adding to the kernel as such and I think it is.
>
> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
> management of individual devices rather than the system as a whole.

>From the use cases presented, the *usage* of suspend blockers is aimed
at power management of individual devices or subsystems, just like
usage of runtime PM.

So I still see a large duplication in the usage and the goals of both
frameworks.  The goal of both is to always enter lowest-power state
except

 - if there's activity (runtime PM for devices, CPUidle for CPU)
 - if there's a suspend blocker (opportunitic suspend)

In addition, it will likely cause duplicate work to be done in
drivers.  Presumably, PM aware drivers will want to know if the system
is in opportunistic mode.  For example, for many drivers, doing
runtime PM may not be worth the effort if the system is in
opportunistic mode.

This last point is especially troubling.  I don't find it a comforting
path to go down if the drivers have to start caring about which PM
policy is currently in use.

Kevin

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

[Kevin Hilman]

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

> On Monday 03 May 2010, Mark Brown wrote:
>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
>> 
>> > At least from the kernel perspective, both suspend blockers and
>> > runtime PM have the same goal.  Given that, which framework should the
>> > driver writer target?  Both?  Seems like duplicate effort.  Using
>> > suspend blockers assumes the system is in opportunitstic suspend mode
>> > and (at least in the keypad example given) assumes a suspend-blocker
>> > aware userspace (Android.) Without both, targeted power savings will
>> > not be acheived.
>> 
>> The other concern here is that for many mobile systems the actual
>> semantic intended by "suspend" as it's currently used is more runtime PM
>> like than full suspend - the classic example of this is that when
>> suspending while on a call in a phone you don't want to suspend the
>> modem or audio CODEC, you want to leave them running.  If you use a full
>> system suspend then the drivers for affected components have to play
>> guessing games (or add currently non-standard knobs for apps to twiddle)
>> to decide if the system intends them to actually implement the suspend
>> or not but with runtime PM it all falls out very naturally without any
>> effort on the part of the driver.
>> 
>> > To me, runtime PM is a generic and flexible approach that can be used
>> > with any userspace.  Driver writers should not have to care whether
>> > the system is in "opportunistic" mode or about whether userspace is
>> > suspend blocker capable.  They should only have to think about when
>> > the device is (or should be) idle.
>> 
>> I fully agree with this.  We do need to ensure that a runtime PM based
>> system can suspend the CPU core and RAM as well as system suspend can
>> but that seems doable.
>
> I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
> all AFAICS.

Please forgive the ignorance of ACPI (in embedded, we thankfully live
in magical world without ACPI) but doesn't that already happen with
CPUidle and C-states?  I think of CPUidle as basically runtime PM for
the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
(via C-states), resulting in dynaimc PM for the entire system.  What
am I missing?

> However, the real question is whether or not the opportunistic suspend feature
> is worth adding to the kernel as such and I think it is.
>
> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
> management of individual devices rather than the system as a whole.

>From the use cases presented, the *usage* of suspend blockers is aimed
at power management of individual devices or subsystems, just like
usage of runtime PM.

So I still see a large duplication in the usage and the goals of both
frameworks.  The goal of both is to always enter lowest-power state
except

 - if there's activity (runtime PM for devices, CPUidle for CPU)
 - if there's a suspend blocker (opportunitic suspend)

In addition, it will likely cause duplicate work to be done in
drivers.  Presumably, PM aware drivers will want to know if the system
is in opportunistic mode.  For example, for many drivers, doing
runtime PM may not be worth the effort if the system is in
opportunistic mode.

This last point is especially troubling.  I don't find it a comforting
path to go down if the drivers have to start caring about which PM
policy is currently in use.

Kevin

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

[Arve Hjønnevåg]

On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
>> On Monday 03 May 2010, Mark Brown wrote:
>>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
>>>
>>> > At least from the kernel perspective, both suspend blockers and
>>> > runtime PM have the same goal.  Given that, which framework should the
>>> > driver writer target?  Both?  Seems like duplicate effort.  Using
>>> > suspend blockers assumes the system is in opportunitstic suspend mode
>>> > and (at least in the keypad example given) assumes a suspend-blocker
>>> > aware userspace (Android.) Without both, targeted power savings will
>>> > not be acheived.
>>>
>>> The other concern here is that for many mobile systems the actual
>>> semantic intended by "suspend" as it's currently used is more runtime PM
>>> like than full suspend - the classic example of this is that when
>>> suspending while on a call in a phone you don't want to suspend the
>>> modem or audio CODEC, you want to leave them running.  If you use a full
>>> system suspend then the drivers for affected components have to play
>>> guessing games (or add currently non-standard knobs for apps to twiddle)
>>> to decide if the system intends them to actually implement the suspend
>>> or not but with runtime PM it all falls out very naturally without any
>>> effort on the part of the driver.
>>>
>>> > To me, runtime PM is a generic and flexible approach that can be used
>>> > with any userspace.  Driver writers should not have to care whether
>>> > the system is in "opportunistic" mode or about whether userspace is
>>> > suspend blocker capable.  They should only have to think about when
>>> > the device is (or should be) idle.
>>>
>>> I fully agree with this.  We do need to ensure that a runtime PM based
>>> system can suspend the CPU core and RAM as well as system suspend can
>>> but that seems doable.
>>
>> I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
>> all AFAICS.
>
> Please forgive the ignorance of ACPI (in embedded, we thankfully live
> in magical world without ACPI) but doesn't that already happen with
> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> (via C-states), resulting in dynaimc PM for the entire system.  What
> am I missing?
>

I'm not that familiar with ACPI either, but I think the S-states
entered by suspend are much lower power than the C-states entered by
idle.

>> However, the real question is whether or not the opportunistic suspend feature
>> is worth adding to the kernel as such and I think it is.
>>
>> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
>> management of individual devices rather than the system as a whole.
>
> From the use cases presented, the *usage* of suspend blockers is aimed
> at power management of individual devices or subsystems, just like
> usage of runtime PM.
>
No, suspend blockers are mostly used to ensure wakeup events are not
ignored, and to ensure tasks triggered by these wakeup events
complete.

> So I still see a large duplication in the usage and the goals of both
> frameworks.  The goal of both is to always enter lowest-power state
> except
>
>  - if there's activity (runtime PM for devices, CPUidle for CPU)
>  - if there's a suspend blocker (opportunitic suspend)
>
> In addition, it will likely cause duplicate work to be done in
> drivers.  Presumably, PM aware drivers will want to know if the system
> is in opportunistic mode.  For example, for many drivers, doing
> runtime PM may not be worth the effort if the system is in
> opportunistic mode.

Why? If a device is not in use it should be off regardless of what
state the rest of the system is in.

>
> This last point is especially troubling.  I don't find it a comforting
> path to go down if the drivers have to start caring about which PM
> policy is currently in use.
>
> Kevin
>



-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
>> On Monday 03 May 2010, Mark Brown wrote:
>>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
>>>
>>> > At least from the kernel perspective, both suspend blockers and
>>> > runtime PM have the same goal.  Given that, which framework should the
>>> > driver writer target?  Both?  Seems like duplicate effort.  Using
>>> > suspend blockers assumes the system is in opportunitstic suspend mode
>>> > and (at least in the keypad example given) assumes a suspend-blocker
>>> > aware userspace (Android.) Without both, targeted power savings will
>>> > not be acheived.
>>>
>>> The other concern here is that for many mobile systems the actual
>>> semantic intended by "suspend" as it's currently used is more runtime PM
>>> like than full suspend - the classic example of this is that when
>>> suspending while on a call in a phone you don't want to suspend the
>>> modem or audio CODEC, you want to leave them running.  If you use a full
>>> system suspend then the drivers for affected components have to play
>>> guessing games (or add currently non-standard knobs for apps to twiddle)
>>> to decide if the system intends them to actually implement the suspend
>>> or not but with runtime PM it all falls out very naturally without any
>>> effort on the part of the driver.
>>>
>>> > To me, runtime PM is a generic and flexible approach that can be used
>>> > with any userspace.  Driver writers should not have to care whether
>>> > the system is in "opportunistic" mode or about whether userspace is
>>> > suspend blocker capable.  They should only have to think about when
>>> > the device is (or should be) idle.
>>>
>>> I fully agree with this.  We do need to ensure that a runtime PM based
>>> system can suspend the CPU core and RAM as well as system suspend can
>>> but that seems doable.
>>
>> I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
>> all AFAICS.
>
> Please forgive the ignorance of ACPI (in embedded, we thankfully live
> in magical world without ACPI) but doesn't that already happen with
> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> (via C-states), resulting in dynaimc PM for the entire system.  What
> am I missing?
>

I'm not that familiar with ACPI either, but I think the S-states
entered by suspend are much lower power than the C-states entered by
idle.

>> However, the real question is whether or not the opportunistic suspend feature
>> is worth adding to the kernel as such and I think it is.
>>
>> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
>> management of individual devices rather than the system as a whole.
>
> From the use cases presented, the *usage* of suspend blockers is aimed
> at power management of individual devices or subsystems, just like
> usage of runtime PM.
>
No, suspend blockers are mostly used to ensure wakeup events are not
ignored, and to ensure tasks triggered by these wakeup events
complete.

> So I still see a large duplication in the usage and the goals of both
> frameworks.  The goal of both is to always enter lowest-power state
> except
>
>  - if there's activity (runtime PM for devices, CPUidle for CPU)
>  - if there's a suspend blocker (opportunitic suspend)
>
> In addition, it will likely cause duplicate work to be done in
> drivers.  Presumably, PM aware drivers will want to know if the system
> is in opportunistic mode.  For example, for many drivers, doing
> runtime PM may not be worth the effort if the system is in
> opportunistic mode.

Why? If a device is not in use it should be off regardless of what
state the rest of the system is in.

>
> This last point is especially troubling.  I don't find it a comforting
> path to go down if the drivers have to start caring about which PM
> policy is currently in use.
>
> Kevin
>



-- 
Arve Hjønnevåg

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

[Brian Swetland]

On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
>>
>> In addition, it will likely cause duplicate work to be done in
>> drivers.  Presumably, PM aware drivers will want to know if the system
>> is in opportunistic mode.  For example, for many drivers, doing
>> runtime PM may not be worth the effort if the system is in
>> opportunistic mode.
>
> Why? If a device is not in use it should be off regardless of what
> state the rest of the system is in.
>
>> This last point is especially troubling.  I don't find it a comforting
>> path to go down if the drivers have to start caring about which PM
>> policy is currently in use.

I'll echo Arve here -- all drivers should seek to be in the lowest
power state possible at all times.  We've never suggested that
suspend_block is a substitute for that.

Suspend blockers give us some flexibility on systems where runtime pm
will not get us all the way there. If you can meet your power needs
without needing suspend blockers, awesome, you don't need them on that
platform.  The patchset Arve sent out makes this feature an
off-by-default kernel configuration option that compiles out to no-ops
when disabled.

In our experience, periodic timers and polling, both userspace side
and kernelside make suspend blockers a win even on platforms like OMAP
which have pretty flexible hardware power management.  Going to low
power states in idle results in higher average power consumption than
going to the same states in full suspend, at least on Android devices
shipping today.

Brian

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

[Brian Swetland]

On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
>>
>> In addition, it will likely cause duplicate work to be done in
>> drivers.  Presumably, PM aware drivers will want to know if the system
>> is in opportunistic mode.  For example, for many drivers, doing
>> runtime PM may not be worth the effort if the system is in
>> opportunistic mode.
>
> Why? If a device is not in use it should be off regardless of what
> state the rest of the system is in.
>
>> This last point is especially troubling.  I don't find it a comforting
>> path to go down if the drivers have to start caring about which PM
>> policy is currently in use.

I'll echo Arve here -- all drivers should seek to be in the lowest
power state possible at all times.  We've never suggested that
suspend_block is a substitute for that.

Suspend blockers give us some flexibility on systems where runtime pm
will not get us all the way there. If you can meet your power needs
without needing suspend blockers, awesome, you don't need them on that
platform.  The patchset Arve sent out makes this feature an
off-by-default kernel configuration option that compiles out to no-ops
when disabled.

In our experience, periodic timers and polling, both userspace side
and kernelside make suspend blockers a win even on platforms like OMAP
which have pretty flexible hardware power management.  Going to low
power states in idle results in higher average power consumption than
going to the same states in full suspend, at least on Android devices
shipping today.

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

[Matthew Garrett]

On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:

> Please forgive the ignorance of ACPI (in embedded, we thankfully live
> in magical world without ACPI) but doesn't that already happen with
> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> (via C-states), resulting in dynaimc PM for the entire system.  What
> am I missing?

ACPI doesn't provide any functionality for cutting power to most devices 
other than shifting into full system suspend. The number of wakeup 
events available to us on a given machine is usually small and the 
wakeup latency large, so it's not terribly practical to do this 
transparently on most hardware.

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

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

[Matthew Garrett]

On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:

> Please forgive the ignorance of ACPI (in embedded, we thankfully live
> in magical world without ACPI) but doesn't that already happen with
> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> (via C-states), resulting in dynaimc PM for the entire system.  What
> am I missing?

ACPI doesn't provide any functionality for cutting power to most devices 
other than shifting into full system suspend. The number of wakeup 
events available to us on a given machine is usually small and the 
wakeup latency large, so it's not terribly practical to do this 
transparently on most hardware.

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

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

[Pavel Machek]

On Mon 2010-05-03 17:03:11, Rafael J. Wysocki wrote:
> On Sunday 02 May 2010, Alan Stern wrote:
> > On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> > 
> > > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> > > using the same file handle.  So, what exactly is a process supposed to do to
> > > use two suspend blockers at the same time?
> > 
> > Open the file twice, thereby obtaining two file handles.
> 
> Well, that's what I thought.
> 
> I must admit I'm not really comfortable with this interface.  IMO it would
> be better if _open() created the suspend blocker giving it a name based on
> the name of the process that called it.  Something like
> "<process name>_<timestamp>" might work at first sight.
> 
> Alternatively, "<process_name><number>", where <number> is 0 for the first
> suspend blocker created by the given process, 1 for the second one etc., also
> seems to be doable.

Yes please.

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

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

[Pavel Machek]

On Mon 2010-05-03 17:03:11, Rafael J. Wysocki wrote:
> On Sunday 02 May 2010, Alan Stern wrote:
> > On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> > 
> > > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> > > using the same file handle.  So, what exactly is a process supposed to do to
> > > use two suspend blockers at the same time?
> > 
> > Open the file twice, thereby obtaining two file handles.
> 
> Well, that's what I thought.
> 
> I must admit I'm not really comfortable with this interface.  IMO it would
> be better if _open() created the suspend blocker giving it a name based on
> the name of the process that called it.  Something like
> "<process name>_<timestamp>" might work at first sight.
> 
> Alternatively, "<process_name><number>", where <number> is 0 for the first
> suspend blocker created by the given process, 1 for the second one etc., also
> seems to be doable.

Yes please.

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

Re: [linux-pm] [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.

[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 4/8] PM: suspend_block: Add debugfs file

[Andi Kleen]

Arve Hjønnevåg <arve@android.com> writes:
>  
> +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);

Could you report the pid here too? 

The name set by the application might be meaningless or duplicated.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Andi Kleen]

Arve Hjønnevåg <arve@android.com> writes:
>  
> +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);

Could you report the pid here too? 

The name set by the application might be meaningless or duplicated.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Alan Stern]

On Tue, 4 May 2010, Matthew Garrett wrote:

> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
> 
> > Please forgive the ignorance of ACPI (in embedded, we thankfully live
> > in magical world without ACPI) but doesn't that already happen with
> > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> > (via C-states), resulting in dynaimc PM for the entire system.  What
> > am I missing?
> 
> ACPI doesn't provide any functionality for cutting power to most devices 
> other than shifting into full system suspend. The number of wakeup 
> events available to us on a given machine is usually small and the 
> wakeup latency large, so it's not terribly practical to do this 
> transparently on most hardware.

Another thing that Kevin is missing: There is more to the system than
the devices and the CPU.  For example: RAM, an embedded controller (on
modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
for the CPU and the devices won't power-down these things, but system
PM will.

Alan Stern

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

[Alan Stern]

On Tue, 4 May 2010, Matthew Garrett wrote:

> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
> 
> > Please forgive the ignorance of ACPI (in embedded, we thankfully live
> > in magical world without ACPI) but doesn't that already happen with
> > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> > (via C-states), resulting in dynaimc PM for the entire system.  What
> > am I missing?
> 
> ACPI doesn't provide any functionality for cutting power to most devices 
> other than shifting into full system suspend. The number of wakeup 
> events available to us on a given machine is usually small and the 
> wakeup latency large, so it's not terribly practical to do this 
> transparently on most hardware.

Another thing that Kevin is missing: There is more to the system than
the devices and the CPU.  For example: RAM, an embedded controller (on
modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
for the CPU and the devices won't power-down these things, but system
PM will.

Alan Stern

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

[Mark Brown]

On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman

> >> This last point is especially troubling.  I don't find it a comforting
> >> path to go down if the drivers have to start caring about which PM
> >> policy is currently in use.

> I'll echo Arve here -- all drivers should seek to be in the lowest
> power state possible at all times.  We've never suggested that
> suspend_block is a substitute for that.

Looking at this from a subsystem/driver author point of view the problem
I'm faced with is that as a result of using system suspend much more
aggressively the subsystem and driver layers are getting conflicting
instructions about what the lowest power state possible is.

> Suspend blockers give us some flexibility on systems where runtime pm
> will not get us all the way there. If you can meet your power needs
> without needing suspend blockers, awesome, you don't need them on that
> platform.  The patchset Arve sent out makes this feature an
> off-by-default kernel configuration option that compiles out to no-ops
> when disabled.

I think a big part of this for me is that this approach changes the
intended use of the system-wide suspend a bit, complicating it a bit
further than it already is.  We end up doing a suspend (which in the
normal course of affairs means that the driver should shut everything
down) partly as a substitute for runtime PM on the core system devices
and partly because our runtime PM isn't doing as well as it should on
the individual devices.

I'd be a lot more comfortable with this if it came with a mechanism for
communicating the intended effect of a suspend on a per-device level so
that the drivers have a clear way of figuring out what to do when the
system suspends.  If there isn't one we can add subsystem or driver
specific hooks, of course, but it'd be better to address this at the
system level.

> In our experience, periodic timers and polling, both userspace side
> and kernelside make suspend blockers a win even on platforms like OMAP
> which have pretty flexible hardware power management.  Going to low
> power states in idle results in higher average power consumption than
> going to the same states in full suspend, at least on Android devices
> shipping today.

There's definite work to be done here, yes.

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

[Mark Brown]

On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman

> >> This last point is especially troubling.  I don't find it a comforting
> >> path to go down if the drivers have to start caring about which PM
> >> policy is currently in use.

> I'll echo Arve here -- all drivers should seek to be in the lowest
> power state possible at all times.  We've never suggested that
> suspend_block is a substitute for that.

Looking at this from a subsystem/driver author point of view the problem
I'm faced with is that as a result of using system suspend much more
aggressively the subsystem and driver layers are getting conflicting
instructions about what the lowest power state possible is.

> Suspend blockers give us some flexibility on systems where runtime pm
> will not get us all the way there. If you can meet your power needs
> without needing suspend blockers, awesome, you don't need them on that
> platform.  The patchset Arve sent out makes this feature an
> off-by-default kernel configuration option that compiles out to no-ops
> when disabled.

I think a big part of this for me is that this approach changes the
intended use of the system-wide suspend a bit, complicating it a bit
further than it already is.  We end up doing a suspend (which in the
normal course of affairs means that the driver should shut everything
down) partly as a substitute for runtime PM on the core system devices
and partly because our runtime PM isn't doing as well as it should on
the individual devices.

I'd be a lot more comfortable with this if it came with a mechanism for
communicating the intended effect of a suspend on a per-device level so
that the drivers have a clear way of figuring out what to do when the
system suspends.  If there isn't one we can add subsystem or driver
specific hooks, of course, but it'd be better to address this at the
system level.

> In our experience, periodic timers and polling, both userspace side
> and kernelside make suspend blockers a win even on platforms like OMAP
> which have pretty flexible hardware power management.  Going to low
> power states in idle results in higher average power consumption than
> going to the same states in full suspend, at least on Android devices
> shipping today.

There's definite work to be done here, yes.

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:
> On Tue, 4 May 2010, Matthew Garrett wrote:
> > On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:

> > > Please forgive the ignorance of ACPI (in embedded, we thankfully live
> > > in magical world without ACPI) but doesn't that already happen with
> > > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> > > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> > > (via C-states), resulting in dynaimc PM for the entire system.  What
> > > am I missing?

> > ACPI doesn't provide any functionality for cutting power to most devices 
> > other than shifting into full system suspend. The number of wakeup 
> > events available to us on a given machine is usually small and the 
> > wakeup latency large, so it's not terribly practical to do this 
> > transparently on most hardware.

> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

In an embedded system I'd expect that these other system devices would
fall naturally out through the management of the CPUs and devices - for
example, the drivers for the individual devices could use the regulator
API to manage their supplies and runtime PM is being used to manage CPU
core stuff - or could at least readily be handled in a similar fashion.

This isn't to say that we're there yet from an implementation point of
view, of course.

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

[Mark Brown]

On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:
> On Tue, 4 May 2010, Matthew Garrett wrote:
> > On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:

> > > Please forgive the ignorance of ACPI (in embedded, we thankfully live
> > > in magical world without ACPI) but doesn't that already happen with
> > > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> > > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> > > (via C-states), resulting in dynaimc PM for the entire system.  What
> > > am I missing?

> > ACPI doesn't provide any functionality for cutting power to most devices 
> > other than shifting into full system suspend. The number of wakeup 
> > events available to us on a given machine is usually small and the 
> > wakeup latency large, so it's not terribly practical to do this 
> > transparently on most hardware.

> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

In an embedded system I'd expect that these other system devices would
fall naturally out through the management of the CPUs and devices - for
example, the drivers for the individual devices could use the regulator
API to manage their supplies and runtime PM is being used to manage CPU
core stuff - or could at least readily be handled in a similar fashion.

This isn't to say that we're there yet from an implementation point of
view, of course.

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
>
>> Please forgive the ignorance of ACPI (in embedded, we thankfully live
>> in magical world without ACPI) but doesn't that already happen with
>> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
>> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
>> (via C-states), resulting in dynaimc PM for the entire system.  What
>> am I missing?
>
> ACPI doesn't provide any functionality for cutting power to most
> devices other than shifting into full system suspend. The number of
> wakeup events available to us on a given machine is usually small
> and the wakeup latency large, so it's not terribly practical to do
> this transparently on most hardware.

OK, that's a major difference with embedded SoCs where the kernel must
directly manage the power state of all devices using runtime PM.

So basically, on ACPI systems, runtime PM doesn't get you any power
savings for most devices.  

Kevin

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
>
>> Please forgive the ignorance of ACPI (in embedded, we thankfully live
>> in magical world without ACPI) but doesn't that already happen with
>> CPUidle and C-states?  I think of CPUidle as basically runtime PM for
>> the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
>> (via C-states), resulting in dynaimc PM for the entire system.  What
>> am I missing?
>
> ACPI doesn't provide any functionality for cutting power to most
> devices other than shifting into full system suspend. The number of
> wakeup events available to us on a given machine is usually small
> and the wakeup latency large, so it's not terribly practical to do
> this transparently on most hardware.

OK, that's a major difference with embedded SoCs where the kernel must
directly manage the power state of all devices using runtime PM.

So basically, on ACPI systems, runtime PM doesn't get you any power
savings for most devices.  

Kevin

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Tue, 4 May 2010, Matthew Garrett wrote:
>
>> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
>> 
>> > Please forgive the ignorance of ACPI (in embedded, we thankfully live
>> > in magical world without ACPI) but doesn't that already happen with
>> > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
>> > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
>> > (via C-states), resulting in dynaimc PM for the entire system.  What
>> > am I missing?
>> 
>> ACPI doesn't provide any functionality for cutting power to most devices 
>> other than shifting into full system suspend. The number of wakeup 
>> events available to us on a given machine is usually small and the 
>> wakeup latency large, so it's not terribly practical to do this 
>> transparently on most hardware.
>
> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

I consider all of those things devices.

On non-ACPI systems where the kernel has to manage all of the above
directly, we have drivers for all of them using runtime PM as well as
the regulator framework for dynamic PM power supplies.

Kevin

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Tue, 4 May 2010, Matthew Garrett wrote:
>
>> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
>> 
>> > Please forgive the ignorance of ACPI (in embedded, we thankfully live
>> > in magical world without ACPI) but doesn't that already happen with
>> > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
>> > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
>> > (via C-states), resulting in dynaimc PM for the entire system.  What
>> > am I missing?
>> 
>> ACPI doesn't provide any functionality for cutting power to most devices 
>> other than shifting into full system suspend. The number of wakeup 
>> events available to us on a given machine is usually small and the 
>> wakeup latency large, so it's not terribly practical to do this 
>> transparently on most hardware.
>
> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

I consider all of those things devices.

On non-ACPI systems where the kernel has to manage all of the above
directly, we have drivers for all of them using runtime PM as well as
the regulator framework for dynamic PM power supplies.

Kevin

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

[Matthew Garrett]

On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:

> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

Somewhat true - machines with C1E support will put the RAM into self 
refresh when the cpu is idle, but you're right that there are various 
components that we simply don't have control over in the desktop world 
at present.

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

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

[Matthew Garrett]

On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:

> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

Somewhat true - machines with C1E support will put the RAM into self 
refresh when the cpu is idle, but you're right that there are various 
components that we simply don't have control over in the desktop world 
at present.

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

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

[Matthew Garrett]

On Tue, May 04, 2010 at 08:13:09AM -0700, Kevin Hilman wrote:

> So basically, on ACPI systems, runtime PM doesn't get you any power
> savings for most devices.  

I'd say it does for most devices, but the power savings may not be as 
great as they would be with fine-grained control over power rails.

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

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

[Matthew Garrett]

On Tue, May 04, 2010 at 08:13:09AM -0700, Kevin Hilman wrote:

> So basically, on ACPI systems, runtime PM doesn't get you any power
> savings for most devices.  

I'd say it does for most devices, but the power savings may not be as 
great as they would be with fine-grained control over power rails.

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

Re: [linux-pm] [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.

[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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Kevin Hilman]

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

> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>

[...]

>>> However, the real question is whether or not the opportunistic suspend feature
>>> is worth adding to the kernel as such and I think it is.
>>>
>>> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
>>> management of individual devices rather than the system as a whole.
>>
>> From the use cases presented, the *usage* of suspend blockers is aimed
>> at power management of individual devices or subsystems, just like
>> usage of runtime PM.
>>
> No, suspend blockers are mostly used to ensure wakeup events are not
> ignored, and to ensure tasks triggered by these wakeup events
> complete.

OK, but my point was that their *usage* is at the level of inidividual
devices and subsystems, just like runtime PM.  Hence, duplicate work.

>> So I still see a large duplication in the usage and the goals of both
>> frameworks.  The goal of both is to always enter lowest-power state
>> except
>>
>>  - if there's activity (runtime PM for devices, CPUidle for CPU)
>>  - if there's a suspend blocker (opportunitic suspend)
>>
>> In addition, it will likely cause duplicate work to be done in
>> drivers.  Presumably, PM aware drivers will want to know if the system
>> is in opportunistic mode.  For example, for many drivers, doing
>> runtime PM may not be worth the effort if the system is in
>> opportunistic mode.
>
> Why? If a device is not in use it should be off regardless of what
> state the rest of the system is in.

Not necessarily.

If a device is not in use, what power state it goes into depends on
many device/subsystem specific things.  For example, recent activity
(timeouts), whether it will be busy soon (pending transfers),
latency/throughput constraints, dependency on other devices, or any
other device/subsystem specific reason.

All of these can be handled with runtime PM.  None of which are taken
into consideration with opportunistic suspend.

Kevin

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

[Kevin Hilman]

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

> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>

[...]

>>> However, the real question is whether or not the opportunistic suspend feature
>>> is worth adding to the kernel as such and I think it is.
>>>
>>> To me, it doesn't duplicate the runtime PM framework which is aimed at the power
>>> management of individual devices rather than the system as a whole.
>>
>> From the use cases presented, the *usage* of suspend blockers is aimed
>> at power management of individual devices or subsystems, just like
>> usage of runtime PM.
>>
> No, suspend blockers are mostly used to ensure wakeup events are not
> ignored, and to ensure tasks triggered by these wakeup events
> complete.

OK, but my point was that their *usage* is at the level of inidividual
devices and subsystems, just like runtime PM.  Hence, duplicate work.

>> So I still see a large duplication in the usage and the goals of both
>> frameworks.  The goal of both is to always enter lowest-power state
>> except
>>
>>  - if there's activity (runtime PM for devices, CPUidle for CPU)
>>  - if there's a suspend blocker (opportunitic suspend)
>>
>> In addition, it will likely cause duplicate work to be done in
>> drivers.  Presumably, PM aware drivers will want to know if the system
>> is in opportunistic mode.  For example, for many drivers, doing
>> runtime PM may not be worth the effort if the system is in
>> opportunistic mode.
>
> Why? If a device is not in use it should be off regardless of what
> state the rest of the system is in.

Not necessarily.

If a device is not in use, what power state it goes into depends on
many device/subsystem specific things.  For example, recent activity
(timeouts), whether it will be busy soon (pending transfers),
latency/throughput constraints, dependency on other devices, or any
other device/subsystem specific reason.

All of these can be handled with runtime PM.  None of which are taken
into consideration with opportunistic suspend.

Kevin

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

[Kevin Hilman]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
>> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
>> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
>
>> >> This last point is especially troubling.  I don't find it a comforting
>> >> path to go down if the drivers have to start caring about which PM
>> >> policy is currently in use.
>
>> I'll echo Arve here -- all drivers should seek to be in the lowest
>> power state possible at all times.  We've never suggested that
>> suspend_block is a substitute for that.
>
> Looking at this from a subsystem/driver author point of view the problem
> I'm faced with is that as a result of using system suspend much more
> aggressively the subsystem and driver layers are getting conflicting
> instructions about what the lowest power state possible is.

Exactly.

With runtime PM, there is flexibility in choosing the lowest power
state at the device/subsystem level, based on activity, timeouts,
bitrate, dependencies, latency/throughput constraints, etc.

With opportunistic suspend, all of this flexibility is gone, and the
device/subsystem is told to go into the lowest power, highest latency
state, period.

>> Suspend blockers give us some flexibility on systems where runtime pm
>> will not get us all the way there. If you can meet your power needs
>> without needing suspend blockers, awesome, you don't need them on that
>> platform.  The patchset Arve sent out makes this feature an
>> off-by-default kernel configuration option that compiles out to no-ops
>> when disabled.
>
> I think a big part of this for me is that this approach changes the
> intended use of the system-wide suspend a bit, complicating it a bit
> further than it already is.  We end up doing a suspend (which in the
> normal course of affairs means that the driver should shut everything
> down) partly as a substitute for runtime PM on the core system devices
> and partly because our runtime PM isn't doing as well as it should on
> the individual devices.

Agreed, and because of this, part of my concern is that opportunistic
suspend will take the place of doing the "right thing" which (IMHO) 
would be to improve runtime PM for devices.

> I'd be a lot more comfortable with this if it came with a mechanism for
> communicating the intended effect of a suspend on a per-device level so
> that the drivers have a clear way of figuring out what to do when the
> system suspends.  If there isn't one we can add subsystem or driver
> specific hooks, of course, but it'd be better to address this at the
> system level.

I agree.

I think there needs to be more discussion on the indended usage
of suspend blockers by drivers/subsystems, especially those PM aware
drivers and subsystems already doing runtime PM with constraints etc.

>> In our experience, periodic timers and polling, both userspace side
>> and kernelside make suspend blockers a win even on platforms like OMAP
>> which have pretty flexible hardware power management.  Going to low
>> power states in idle results in higher average power consumption than
>> going to the same states in full suspend, at least on Android devices
>> shipping today.
>
> There's definite work to be done here, yes.

And I've admitted this to be the only compelling reason for
opportunistic suspend so far.

But the driver/subsystem implications of opportunistic suspend still
need some fleshing out IMO.

Kevin

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

[Kevin Hilman]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
>> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
>> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
>
>> >> This last point is especially troubling.  I don't find it a comforting
>> >> path to go down if the drivers have to start caring about which PM
>> >> policy is currently in use.
>
>> I'll echo Arve here -- all drivers should seek to be in the lowest
>> power state possible at all times.  We've never suggested that
>> suspend_block is a substitute for that.
>
> Looking at this from a subsystem/driver author point of view the problem
> I'm faced with is that as a result of using system suspend much more
> aggressively the subsystem and driver layers are getting conflicting
> instructions about what the lowest power state possible is.

Exactly.

With runtime PM, there is flexibility in choosing the lowest power
state at the device/subsystem level, based on activity, timeouts,
bitrate, dependencies, latency/throughput constraints, etc.

With opportunistic suspend, all of this flexibility is gone, and the
device/subsystem is told to go into the lowest power, highest latency
state, period.

>> Suspend blockers give us some flexibility on systems where runtime pm
>> will not get us all the way there. If you can meet your power needs
>> without needing suspend blockers, awesome, you don't need them on that
>> platform.  The patchset Arve sent out makes this feature an
>> off-by-default kernel configuration option that compiles out to no-ops
>> when disabled.
>
> I think a big part of this for me is that this approach changes the
> intended use of the system-wide suspend a bit, complicating it a bit
> further than it already is.  We end up doing a suspend (which in the
> normal course of affairs means that the driver should shut everything
> down) partly as a substitute for runtime PM on the core system devices
> and partly because our runtime PM isn't doing as well as it should on
> the individual devices.

Agreed, and because of this, part of my concern is that opportunistic
suspend will take the place of doing the "right thing" which (IMHO) 
would be to improve runtime PM for devices.

> I'd be a lot more comfortable with this if it came with a mechanism for
> communicating the intended effect of a suspend on a per-device level so
> that the drivers have a clear way of figuring out what to do when the
> system suspends.  If there isn't one we can add subsystem or driver
> specific hooks, of course, but it'd be better to address this at the
> system level.

I agree.

I think there needs to be more discussion on the indended usage
of suspend blockers by drivers/subsystems, especially those PM aware
drivers and subsystems already doing runtime PM with constraints etc.

>> In our experience, periodic timers and polling, both userspace side
>> and kernelside make suspend blockers a win even on platforms like OMAP
>> which have pretty flexible hardware power management.  Going to low
>> power states in idle results in higher average power consumption than
>> going to the same states in full suspend, at least on Android devices
>> shipping today.
>
> There's definite work to be done here, yes.

And I've admitted this to be the only compelling reason for
opportunistic suspend so far.

But the driver/subsystem implications of opportunistic suspend still
need some fleshing out IMO.

Kevin

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

[Mark Brown]

On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:

> With opportunistic suspend, all of this flexibility is gone, and the
> device/subsystem is told to go into the lowest power, highest latency
> state, period.

Well, half the problem I have is that unfortunately it's not a case of
doing that period.  The prime example I'm familiar with is that for
understandable reasons users become irate when you power down the audio
CODEC while they're in the middle of a call so if opportunistic PM is in
use then the audio subsystem needs some additional help interpreting a
suspend request so that it can figure out how to handle it.  Similar
issues apply to PMICs, though less pressingly for various reasons.

Just to be clear, I do understand and mostly agree with the idea that
opportunistic suspend presents a reasonable workaround for our current
inability to deliver good power savings with runtime PM methods on many
important platforms but I do think that if we're going to make this
standard Linux PM functionality then we need to be clearer about how
everything is intended to hang together.

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

[Mark Brown]

On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:

> With opportunistic suspend, all of this flexibility is gone, and the
> device/subsystem is told to go into the lowest power, highest latency
> state, period.

Well, half the problem I have is that unfortunately it's not a case of
doing that period.  The prime example I'm familiar with is that for
understandable reasons users become irate when you power down the audio
CODEC while they're in the middle of a call so if opportunistic PM is in
use then the audio subsystem needs some additional help interpreting a
suspend request so that it can figure out how to handle it.  Similar
issues apply to PMICs, though less pressingly for various reasons.

Just to be clear, I do understand and mostly agree with the idea that
opportunistic suspend presents a reasonable workaround for our current
inability to deliver good power savings with runtime PM methods on many
important platforms but I do think that if we're going to make this
standard Linux PM functionality then we need to be clearer about how
everything is intended to hang together.

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Arve Hjønnevåg wrote:
> 2010/5/3 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Monday 03 May 2010, Arve Hjønnevåg wrote:
> >> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > On Sunday 02 May 2010, Alan Stern wrote:
> >> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> >> >>
> >> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> >> >> > using the same file handle.  So, what exactly is a process supposed to do to
> >> >> > use two suspend blockers at the same time?
> >> >>
> >> >> Open the file twice, thereby obtaining two file handles.
> >> >
> >> > Well, that's what I thought.
> >> >
> >> > I must admit I'm not really comfortable with this interface.  IMO it would
> >> > be better if _open() created the suspend blocker giving it a name based on
> >> > the name of the process that called it.  Something like
> >> > "<process name>_<timestamp>" might work at first sight.
> >> >
> >> > Alternatively, "<process_name><number>", where <number> is 0 for the first
> >> > suspend blocker created by the given process, 1 for the second one etc., also
> >> > seems to be doable.
> >>
> >> I think it is important to let user-space specify the name. If a
> >> process uses multiple suspend blockers, it is impossible to tell what
> >> each one is used for if they are automatically named.
> >
> > Well, the problem is the only purpose of this is user space debugging, isn't it?
> >
> At the moment, yes.

OK

> But having an explicit init call also simplifies future expansion.

That's irrelevant.  Let's focus _only_ on the "at the moment" part, please.

And BTW, a "future expansion" is not relevant at all to the patchset at hand
and let's work with this assumption from now on.  OK?

> If we ever need to add back multiple types of
> suspend blockers, we can add an init call with a type argument and
> have the current init call use the default type. If the past we have
> had types that keeps the screen on and prevented idle sleep modes. In
> the future we could for instance want to specify if a suspend blocker
> should prevent suspend when the battery is low or when the lid is
> closed.

_If_ we ever do anything like thie, _then_ we will extend the interface.

> > Now, while I don't think it's generally bad to provide kernel interfaces
> > helping to debug user space, I'm not quite sure if that should be done at the
> > expense of the clarity of kernel-user space interfaces.
> >
> > I wonder how many cases there are in which distinguishing between suspend
> > blockers used by the same user space task is practically relevant.
> >
> 
> I think all of them (when more than one suspend blocker is used).

So how many user space processes use more than one suspend blocker right
now on Android?  I'm interested only in the order of magnitude.

Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Arve Hjønnevåg wrote:
> 2010/5/3 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Monday 03 May 2010, Arve Hjønnevåg wrote:
> >> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > On Sunday 02 May 2010, Alan Stern wrote:
> >> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> >> >>
> >> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> >> >> > using the same file handle.  So, what exactly is a process supposed to do to
> >> >> > use two suspend blockers at the same time?
> >> >>
> >> >> Open the file twice, thereby obtaining two file handles.
> >> >
> >> > Well, that's what I thought.
> >> >
> >> > I must admit I'm not really comfortable with this interface.  IMO it would
> >> > be better if _open() created the suspend blocker giving it a name based on
> >> > the name of the process that called it.  Something like
> >> > "<process name>_<timestamp>" might work at first sight.
> >> >
> >> > Alternatively, "<process_name><number>", where <number> is 0 for the first
> >> > suspend blocker created by the given process, 1 for the second one etc., also
> >> > seems to be doable.
> >>
> >> I think it is important to let user-space specify the name. If a
> >> process uses multiple suspend blockers, it is impossible to tell what
> >> each one is used for if they are automatically named.
> >
> > Well, the problem is the only purpose of this is user space debugging, isn't it?
> >
> At the moment, yes.

OK

> But having an explicit init call also simplifies future expansion.

That's irrelevant.  Let's focus _only_ on the "at the moment" part, please.

And BTW, a "future expansion" is not relevant at all to the patchset at hand
and let's work with this assumption from now on.  OK?

> If we ever need to add back multiple types of
> suspend blockers, we can add an init call with a type argument and
> have the current init call use the default type. If the past we have
> had types that keeps the screen on and prevented idle sleep modes. In
> the future we could for instance want to specify if a suspend blocker
> should prevent suspend when the battery is low or when the lid is
> closed.

_If_ we ever do anything like thie, _then_ we will extend the interface.

> > Now, while I don't think it's generally bad to provide kernel interfaces
> > helping to debug user space, I'm not quite sure if that should be done at the
> > expense of the clarity of kernel-user space interfaces.
> >
> > I wonder how many cases there are in which distinguishing between suspend
> > blockers used by the same user space task is practically relevant.
> >
> 
> I think all of them (when more than one suspend blocker is used).

So how many user space processes use more than one suspend blocker right
now on Android?  I'm interested only in the order of magnitude.

Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Kevin Hilman wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> 
> > On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> >> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> >> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> >
> >> >> This last point is especially troubling.  I don't find it a comforting
> >> >> path to go down if the drivers have to start caring about which PM
> >> >> policy is currently in use.
> >
> >> I'll echo Arve here -- all drivers should seek to be in the lowest
> >> power state possible at all times.  We've never suggested that
> >> suspend_block is a substitute for that.
> >
> > Looking at this from a subsystem/driver author point of view the problem
> > I'm faced with is that as a result of using system suspend much more
> > aggressively the subsystem and driver layers are getting conflicting
> > instructions about what the lowest power state possible is.
> 
> Exactly.
> 
> With runtime PM, there is flexibility in choosing the lowest power
> state at the device/subsystem level, based on activity, timeouts,
> bitrate, dependencies, latency/throughput constraints, etc.
> 
> With opportunistic suspend, all of this flexibility is gone, and the
> device/subsystem is told to go into the lowest power, highest latency
> state, period.

Guys, please.

The opportunistic suspend feature is _not_ to replace runtime PM by any means!

However, there are situations in which runtime PM is clearly insufficient.
The idea behind runtime PM is that subsystems and device drivers will know
when to put devices into low power states and save energy this way.  Still,
even if all subsystems do that 100% efficiently, there may be more savings
possible by putting the entire system into a sleep state (like on ACPI-based
PCs) and we can reach there by runtime PM alone.

> >> Suspend blockers give us some flexibility on systems where runtime pm
> >> will not get us all the way there. If you can meet your power needs
> >> without needing suspend blockers, awesome, you don't need them on that
> >> platform.  The patchset Arve sent out makes this feature an
> >> off-by-default kernel configuration option that compiles out to no-ops
> >> when disabled.
> >
> > I think a big part of this for me is that this approach changes the
> > intended use of the system-wide suspend a bit, complicating it a bit
> > further than it already is.  We end up doing a suspend (which in the
> > normal course of affairs means that the driver should shut everything
> > down) partly as a substitute for runtime PM on the core system devices
> > and partly because our runtime PM isn't doing as well as it should on
> > the individual devices.
> 
> Agreed, and because of this, part of my concern is that opportunistic
> suspend will take the place of doing the "right thing" which (IMHO) 
> would be to improve runtime PM for devices.

It really can't, at least on some platforms.  For example, resuming a PC
notebook from suspend to RAM takes more than 1s (with an SSD; rotational disks
add more latency here) which is way too much for such a replacement.

Besides, there also is room for runtime PM in the Android framework, because
it needs to suspend certain devices without freezing processes, for example.

The freezing of processes is the most important difference to me.  Runtime PM
works with the assumption that processes are not frozen (hence the name), but
arguably energy savings you can get without going behind that point are
naturally limited.

> > I'd be a lot more comfortable with this if it came with a mechanism for
> > communicating the intended effect of a suspend on a per-device level so
> > that the drivers have a clear way of figuring out what to do when the
> > system suspends.  If there isn't one we can add subsystem or driver
> > specific hooks, of course, but it'd be better to address this at the
> > system level.
> 
> I agree.

I'm not sure.  Why _exactly_ would you need that?

> I think there needs to be more discussion on the indended usage
> of suspend blockers by drivers/subsystems, especially those PM aware
> drivers and subsystems already doing runtime PM with constraints etc.
> 
> >> In our experience, periodic timers and polling, both userspace side
> >> and kernelside make suspend blockers a win even on platforms like OMAP
> >> which have pretty flexible hardware power management.  Going to low
> >> power states in idle results in higher average power consumption than
> >> going to the same states in full suspend, at least on Android devices
> >> shipping today.
> >
> > There's definite work to be done here, yes.
> 
> And I've admitted this to be the only compelling reason for
> opportunistic suspend so far.
> 
> But the driver/subsystem implications of opportunistic suspend still
> need some fleshing out IMO.

At the moment, if you're not on Android, there are none.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Kevin Hilman wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> 
> > On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> >> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> >> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> >
> >> >> This last point is especially troubling.  I don't find it a comforting
> >> >> path to go down if the drivers have to start caring about which PM
> >> >> policy is currently in use.
> >
> >> I'll echo Arve here -- all drivers should seek to be in the lowest
> >> power state possible at all times.  We've never suggested that
> >> suspend_block is a substitute for that.
> >
> > Looking at this from a subsystem/driver author point of view the problem
> > I'm faced with is that as a result of using system suspend much more
> > aggressively the subsystem and driver layers are getting conflicting
> > instructions about what the lowest power state possible is.
> 
> Exactly.
> 
> With runtime PM, there is flexibility in choosing the lowest power
> state at the device/subsystem level, based on activity, timeouts,
> bitrate, dependencies, latency/throughput constraints, etc.
> 
> With opportunistic suspend, all of this flexibility is gone, and the
> device/subsystem is told to go into the lowest power, highest latency
> state, period.

Guys, please.

The opportunistic suspend feature is _not_ to replace runtime PM by any means!

However, there are situations in which runtime PM is clearly insufficient.
The idea behind runtime PM is that subsystems and device drivers will know
when to put devices into low power states and save energy this way.  Still,
even if all subsystems do that 100% efficiently, there may be more savings
possible by putting the entire system into a sleep state (like on ACPI-based
PCs) and we can reach there by runtime PM alone.

> >> Suspend blockers give us some flexibility on systems where runtime pm
> >> will not get us all the way there. If you can meet your power needs
> >> without needing suspend blockers, awesome, you don't need them on that
> >> platform.  The patchset Arve sent out makes this feature an
> >> off-by-default kernel configuration option that compiles out to no-ops
> >> when disabled.
> >
> > I think a big part of this for me is that this approach changes the
> > intended use of the system-wide suspend a bit, complicating it a bit
> > further than it already is.  We end up doing a suspend (which in the
> > normal course of affairs means that the driver should shut everything
> > down) partly as a substitute for runtime PM on the core system devices
> > and partly because our runtime PM isn't doing as well as it should on
> > the individual devices.
> 
> Agreed, and because of this, part of my concern is that opportunistic
> suspend will take the place of doing the "right thing" which (IMHO) 
> would be to improve runtime PM for devices.

It really can't, at least on some platforms.  For example, resuming a PC
notebook from suspend to RAM takes more than 1s (with an SSD; rotational disks
add more latency here) which is way too much for such a replacement.

Besides, there also is room for runtime PM in the Android framework, because
it needs to suspend certain devices without freezing processes, for example.

The freezing of processes is the most important difference to me.  Runtime PM
works with the assumption that processes are not frozen (hence the name), but
arguably energy savings you can get without going behind that point are
naturally limited.

> > I'd be a lot more comfortable with this if it came with a mechanism for
> > communicating the intended effect of a suspend on a per-device level so
> > that the drivers have a clear way of figuring out what to do when the
> > system suspends.  If there isn't one we can add subsystem or driver
> > specific hooks, of course, but it'd be better to address this at the
> > system level.
> 
> I agree.

I'm not sure.  Why _exactly_ would you need that?

> I think there needs to be more discussion on the indended usage
> of suspend blockers by drivers/subsystems, especially those PM aware
> drivers and subsystems already doing runtime PM with constraints etc.
> 
> >> In our experience, periodic timers and polling, both userspace side
> >> and kernelside make suspend blockers a win even on platforms like OMAP
> >> which have pretty flexible hardware power management.  Going to low
> >> power states in idle results in higher average power consumption than
> >> going to the same states in full suspend, at least on Android devices
> >> shipping today.
> >
> > There's definite work to be done here, yes.
> 
> And I've admitted this to be the only compelling reason for
> opportunistic suspend so far.
> 
> But the driver/subsystem implications of opportunistic suspend still
> need some fleshing out IMO.

At the moment, if you're not on Android, there are none.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Mark Brown wrote:
> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
> 
> > With opportunistic suspend, all of this flexibility is gone, and the
> > device/subsystem is told to go into the lowest power, highest latency
> > state, period.
> 
> Well, half the problem I have is that unfortunately it's not a case of
> doing that period.  The prime example I'm familiar with is that for
> understandable reasons users become irate when you power down the audio
> CODEC while they're in the middle of a call so if opportunistic PM is in
> use then the audio subsystem needs some additional help interpreting a
> suspend request so that it can figure out how to handle it.  Similar
> issues apply to PMICs, though less pressingly for various reasons.
> 
> Just to be clear, I do understand and mostly agree with the idea that
> opportunistic suspend presents a reasonable workaround for our current
> inability to deliver good power savings with runtime PM methods on many
> important platforms but I do think that if we're going to make this
> standard Linux PM functionality then we need to be clearer about how
> everything is intended to hang together.

At the moment the rule of thumb is: if you don't need the opportunistic
suspend, don't use it.  It is not going to be enabled by default on anything
other than Android right now.

However, since Android is a legitimate user of the Linux kernel, I see no
reason to reject this feature right away.  There are many kernel features
that aren't used by all platforms.

Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Mark Brown wrote:
> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
> 
> > With opportunistic suspend, all of this flexibility is gone, and the
> > device/subsystem is told to go into the lowest power, highest latency
> > state, period.
> 
> Well, half the problem I have is that unfortunately it's not a case of
> doing that period.  The prime example I'm familiar with is that for
> understandable reasons users become irate when you power down the audio
> CODEC while they're in the middle of a call so if opportunistic PM is in
> use then the audio subsystem needs some additional help interpreting a
> suspend request so that it can figure out how to handle it.  Similar
> issues apply to PMICs, though less pressingly for various reasons.
> 
> Just to be clear, I do understand and mostly agree with the idea that
> opportunistic suspend presents a reasonable workaround for our current
> inability to deliver good power savings with runtime PM methods on many
> important platforms but I do think that if we're going to make this
> standard Linux PM functionality then we need to be clearer about how
> everything is intended to hang together.

At the moment the rule of thumb is: if you don't need the opportunistic
suspend, don't use it.  It is not going to be enabled by default on anything
other than Android right now.

However, since Android is a legitimate user of the Linux kernel, I see no
reason to reject this feature right away.  There are many kernel features
that aren't used by all platforms.

Rafael

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Rafael J. Wysocki wrote:
> On Tuesday 04 May 2010, Kevin Hilman wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> > 
> > > On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> > >> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> > >> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> > >
> > >> >> This last point is especially troubling.  I don't find it a comforting
> > >> >> path to go down if the drivers have to start caring about which PM
> > >> >> policy is currently in use.
> > >
> > >> I'll echo Arve here -- all drivers should seek to be in the lowest
> > >> power state possible at all times.  We've never suggested that
> > >> suspend_block is a substitute for that.
> > >
> > > Looking at this from a subsystem/driver author point of view the problem
> > > I'm faced with is that as a result of using system suspend much more
> > > aggressively the subsystem and driver layers are getting conflicting
> > > instructions about what the lowest power state possible is.
> > 
> > Exactly.
> > 
> > With runtime PM, there is flexibility in choosing the lowest power
> > state at the device/subsystem level, based on activity, timeouts,
> > bitrate, dependencies, latency/throughput constraints, etc.
> > 
> > With opportunistic suspend, all of this flexibility is gone, and the
> > device/subsystem is told to go into the lowest power, highest latency
> > state, period.
> 
> Guys, please.
> 
> The opportunistic suspend feature is _not_ to replace runtime PM by any means!
> 
> However, there are situations in which runtime PM is clearly insufficient.
> The idea behind runtime PM is that subsystems and device drivers will know
> when to put devices into low power states and save energy this way.  Still,
> even if all subsystems do that 100% efficiently, there may be more savings
> possible by putting the entire system into a sleep state (like on ACPI-based
> PCs) and we can reach there by runtime PM alone.

s/can/can't/; s/reach/go/

Rafael

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

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Rafael J. Wysocki wrote:
> On Tuesday 04 May 2010, Kevin Hilman wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> > 
> > > On Mon, May 03, 2010 at 05:43:34PM -0700, Brian Swetland wrote:
> > >> On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> > >> > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> > >
> > >> >> This last point is especially troubling.  I don't find it a comforting
> > >> >> path to go down if the drivers have to start caring about which PM
> > >> >> policy is currently in use.
> > >
> > >> I'll echo Arve here -- all drivers should seek to be in the lowest
> > >> power state possible at all times.  We've never suggested that
> > >> suspend_block is a substitute for that.
> > >
> > > Looking at this from a subsystem/driver author point of view the problem
> > > I'm faced with is that as a result of using system suspend much more
> > > aggressively the subsystem and driver layers are getting conflicting
> > > instructions about what the lowest power state possible is.
> > 
> > Exactly.
> > 
> > With runtime PM, there is flexibility in choosing the lowest power
> > state at the device/subsystem level, based on activity, timeouts,
> > bitrate, dependencies, latency/throughput constraints, etc.
> > 
> > With opportunistic suspend, all of this flexibility is gone, and the
> > device/subsystem is told to go into the lowest power, highest latency
> > state, period.
> 
> Guys, please.
> 
> The opportunistic suspend feature is _not_ to replace runtime PM by any means!
> 
> However, there are situations in which runtime PM is clearly insufficient.
> The idea behind runtime PM is that subsystems and device drivers will know
> when to put devices into low power states and save energy this way.  Still,
> even if all subsystems do that 100% efficiently, there may be more savings
> possible by putting the entire system into a sleep state (like on ACPI-based
> PCs) and we can reach there by runtime PM alone.

s/can/can't/; s/reach/go/

Rafael

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

[Arve Hjønnevåg]

2010/5/4 Andi Kleen <andi@halobates.de>:
> Arve Hjønnevåg <arve@android.com> writes:
>>
>> +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);
>
> Could you report the pid here too?
>

Most of the suspend blockers are in the kernel, and does not have a pid.

> The name set by the application might be meaningless or duplicated.
>

Currently all the names set by android user-space are unique but the
pids are not. We can add columns, or extend the name of user space
suspend blockers in the ioctl interface, later if needed.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/5/4 Andi Kleen <andi@halobates.de>:
> Arve Hjønnevåg <arve@android.com> writes:
>>
>> +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);
>
> Could you report the pid here too?
>

Most of the suspend blockers are in the kernel, and does not have a pid.

> The name set by the application might be meaningless or duplicated.
>

Currently all the names set by android user-space are unique but the
pids are not. We can add columns, or extend the name of user space
suspend blockers in the ioctl interface, later if needed.

-- 
Arve Hjønnevåg

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

[Kevin Hilman]

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

> On Tuesday 04 May 2010, Mark Brown wrote:
>> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
>> 
>> > With opportunistic suspend, all of this flexibility is gone, and the
>> > device/subsystem is told to go into the lowest power, highest latency
>> > state, period.
>> 
>> Well, half the problem I have is that unfortunately it's not a case of
>> doing that period.  The prime example I'm familiar with is that for
>> understandable reasons users become irate when you power down the audio
>> CODEC while they're in the middle of a call so if opportunistic PM is in
>> use then the audio subsystem needs some additional help interpreting a
>> suspend request so that it can figure out how to handle it.  Similar
>> issues apply to PMICs, though less pressingly for various reasons.
>> 
>> Just to be clear, I do understand and mostly agree with the idea that
>> opportunistic suspend presents a reasonable workaround for our current
>> inability to deliver good power savings with runtime PM methods on many
>> important platforms but I do think that if we're going to make this
>> standard Linux PM functionality then we need to be clearer about how
>> everything is intended to hang together.
>
> At the moment the rule of thumb is: if you don't need the opportunistic
> suspend, don't use it.  It is not going to be enabled by default on anything
> other than Android right now.

Sure, but there are driver authors and subsystem maintainers who care
about optimal PM in "normal" Linux *and* in Android.

As a PM maintainer for an embedded platform (OMAP) used in both, I
certainly care about both, so "disable it if you don't like it" is not
really an option.

IMO, driver/subsystem authors should not have to care if the userspace
is Android or not.  We should be working towards a world where Android
is not a special case.

Kevin

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

[Kevin Hilman]

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

> On Tuesday 04 May 2010, Mark Brown wrote:
>> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
>> 
>> > With opportunistic suspend, all of this flexibility is gone, and the
>> > device/subsystem is told to go into the lowest power, highest latency
>> > state, period.
>> 
>> Well, half the problem I have is that unfortunately it's not a case of
>> doing that period.  The prime example I'm familiar with is that for
>> understandable reasons users become irate when you power down the audio
>> CODEC while they're in the middle of a call so if opportunistic PM is in
>> use then the audio subsystem needs some additional help interpreting a
>> suspend request so that it can figure out how to handle it.  Similar
>> issues apply to PMICs, though less pressingly for various reasons.
>> 
>> Just to be clear, I do understand and mostly agree with the idea that
>> opportunistic suspend presents a reasonable workaround for our current
>> inability to deliver good power savings with runtime PM methods on many
>> important platforms but I do think that if we're going to make this
>> standard Linux PM functionality then we need to be clearer about how
>> everything is intended to hang together.
>
> At the moment the rule of thumb is: if you don't need the opportunistic
> suspend, don't use it.  It is not going to be enabled by default on anything
> other than Android right now.

Sure, but there are driver authors and subsystem maintainers who care
about optimal PM in "normal" Linux *and* in Android.

As a PM maintainer for an embedded platform (OMAP) used in both, I
certainly care about both, so "disable it if you don't like it" is not
really an option.

IMO, driver/subsystem authors should not have to care if the userspace
is Android or not.  We should be working towards a world where Android
is not a special case.

Kevin

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Tuesday 04 May 2010, Mark Brown wrote:
> >> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
> >> 
> >> > With opportunistic suspend, all of this flexibility is gone, and the
> >> > device/subsystem is told to go into the lowest power, highest latency
> >> > state, period.
> >> 
> >> Well, half the problem I have is that unfortunately it's not a case of
> >> doing that period.  The prime example I'm familiar with is that for
> >> understandable reasons users become irate when you power down the audio
> >> CODEC while they're in the middle of a call so if opportunistic PM is in
> >> use then the audio subsystem needs some additional help interpreting a
> >> suspend request so that it can figure out how to handle it.  Similar
> >> issues apply to PMICs, though less pressingly for various reasons.
> >> 
> >> Just to be clear, I do understand and mostly agree with the idea that
> >> opportunistic suspend presents a reasonable workaround for our current
> >> inability to deliver good power savings with runtime PM methods on many
> >> important platforms but I do think that if we're going to make this
> >> standard Linux PM functionality then we need to be clearer about how
> >> everything is intended to hang together.
> >
> > At the moment the rule of thumb is: if you don't need the opportunistic
> > suspend, don't use it.  It is not going to be enabled by default on anything
> > other than Android right now.
> 
> Sure, but there are driver authors and subsystem maintainers who care
> about optimal PM in "normal" Linux *and* in Android.
> 
> As a PM maintainer for an embedded platform (OMAP) used in both, I
> certainly care about both, so "disable it if you don't like it" is not
> really an option.
> 
> IMO, driver/subsystem authors should not have to care if the userspace
> is Android or not.  We should be working towards a world where Android
> is not a special case.

I agree, but "working on towards a world where ..." need not mean "be there
from day one" IMO.  Also, I guess you'll agree that using the same _binary_
kernel with Android and non-Android user spaces doesn't necessarily make sense
(regardless of the fact that Android kernels have hardware-specific board files
included), so probably you'll still disable opportunistic suspend building the
kernel for non-Android systems (at least for the time being).

It looks like you're thinking the opportunistic suspend somehow is (or can be
used as) a replacement for runtime PM, but this is not the case.  The reason
why it's not the case is that runtime PM works with the assumption that user
space is not frozen and it works on individual devices.

OTOH, generally, there is a limit on the amount of energy savings you can
achieve with runtime PM alone and something like the opportunistic suspend is
necessary to go beyond that limit.

Now, I can easily imagine using suspend blockers and runtime PM in the same
driver with the general rule that you'll probably want to call suspend_unblock()
whenever the device is suspended with the help of the runtime PM framework.
That really depends on the device and the driver in question, though.

Rafael

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Tuesday 04 May 2010, Mark Brown wrote:
> >> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
> >> 
> >> > With opportunistic suspend, all of this flexibility is gone, and the
> >> > device/subsystem is told to go into the lowest power, highest latency
> >> > state, period.
> >> 
> >> Well, half the problem I have is that unfortunately it's not a case of
> >> doing that period.  The prime example I'm familiar with is that for
> >> understandable reasons users become irate when you power down the audio
> >> CODEC while they're in the middle of a call so if opportunistic PM is in
> >> use then the audio subsystem needs some additional help interpreting a
> >> suspend request so that it can figure out how to handle it.  Similar
> >> issues apply to PMICs, though less pressingly for various reasons.
> >> 
> >> Just to be clear, I do understand and mostly agree with the idea that
> >> opportunistic suspend presents a reasonable workaround for our current
> >> inability to deliver good power savings with runtime PM methods on many
> >> important platforms but I do think that if we're going to make this
> >> standard Linux PM functionality then we need to be clearer about how
> >> everything is intended to hang together.
> >
> > At the moment the rule of thumb is: if you don't need the opportunistic
> > suspend, don't use it.  It is not going to be enabled by default on anything
> > other than Android right now.
> 
> Sure, but there are driver authors and subsystem maintainers who care
> about optimal PM in "normal" Linux *and* in Android.
> 
> As a PM maintainer for an embedded platform (OMAP) used in both, I
> certainly care about both, so "disable it if you don't like it" is not
> really an option.
> 
> IMO, driver/subsystem authors should not have to care if the userspace
> is Android or not.  We should be working towards a world where Android
> is not a special case.

I agree, but "working on towards a world where ..." need not mean "be there
from day one" IMO.  Also, I guess you'll agree that using the same _binary_
kernel with Android and non-Android user spaces doesn't necessarily make sense
(regardless of the fact that Android kernels have hardware-specific board files
included), so probably you'll still disable opportunistic suspend building the
kernel for non-Android systems (at least for the time being).

It looks like you're thinking the opportunistic suspend somehow is (or can be
used as) a replacement for runtime PM, but this is not the case.  The reason
why it's not the case is that runtime PM works with the assumption that user
space is not frozen and it works on individual devices.

OTOH, generally, there is a limit on the amount of energy savings you can
achieve with runtime PM alone and something like the opportunistic suspend is
necessary to go beyond that limit.

Now, I can easily imagine using suspend blockers and runtime PM in the same
driver with the general rule that you'll probably want to call suspend_unblock()
whenever the device is suspended with the help of the runtime PM framework.
That really depends on the device and the driver in question, though.

Rafael

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

[Mark Brown]

On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 04 May 2010, Kevin Hilman wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> Guys, please.

> The opportunistic suspend feature is _not_ to replace runtime PM by any means!

Certainly in my case and I think Kevin's I agree with the need for the
bodge at the minute if we can get a clearer idea of how it's supposed to
work.

> when to put devices into low power states and save energy this way.  Still,
> even if all subsystems do that 100% efficiently, there may be more savings
> possible by putting the entire system into a sleep state (like on ACPI-based
> PCs) and we can reach there by runtime PM alone.

Right, this is likely to be a win for PCs - for embedded systems we
rarely have other software to interoperate with so if you can make the
hardware do it then it's unlikely there would be any fundamental issue
with Linux doing it at runtime.

> > > I'd be a lot more comfortable with this if it came with a mechanism for
> > > communicating the intended effect of a suspend on a per-device level so
> > > that the drivers have a clear way of figuring out what to do when the
> > > system suspends.  If there isn't one we can add subsystem or driver
> > > specific hooks, of course, but it'd be better to address this at the
> > > system level.

> > I agree.

> I'm not sure.  Why _exactly_ would you need that?

The use case that causes serious issues with this at the minute in the
domains I work is this:

On a mobile phone when the system is in a voice call the data flow for
the call is entirely handled outside the CPU (normally referred to as
Applications Processor or AP here) by the baseband and audio CODEC,
which are either integrated or directly connected by analogue or digital
audio links on the board.  If the user has the phone to their ear and is
talking away with the screen blanked then the AP is just waiting for
input, will appear idle and so trigger an opportunistic suspend.  If the
audio CODEC is managed by Linux (as is standard) then running through
the suspend process will as things stand cause the audio subsystem to be
suspended.  Since in the normal course of affairs suspend means power
down that's what will happen, but this is clearly highly undesirable in
this situation.

Now, the solution here if we're going to use opportunistic suspend like
this is to provide some method for the audio subsystem to figure out
that the system doesn't actually want it to suspend when it gets told do
do so.  Like I say ideally we'd provide some standard interface in the
PM subsystem for userspace to communicate this to subsystems and drivers
so that we've got a joined up story when people run into issues in cases
like this, though obviously if this goes in then we'll have to put in
something subsystem or driver specific for affected areas.  I know what
I'd implement generically for audio, but I've held back since the option
is fairly messy when not used in conjunction with a deliberate choice to
use opportunistic suspend and I was expecting a standard mechanism to
slot into to provide control for userspace.

In other words, the issue is that we run into situations where we need
an element of suspend control to go along with the opportunistic suspend
in order to allow some elements to be kept running - since suspend
blocking is taken suspend suppression seems like a reasonable term.

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

[Mark Brown]

On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 04 May 2010, Kevin Hilman wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> Guys, please.

> The opportunistic suspend feature is _not_ to replace runtime PM by any means!

Certainly in my case and I think Kevin's I agree with the need for the
bodge at the minute if we can get a clearer idea of how it's supposed to
work.

> when to put devices into low power states and save energy this way.  Still,
> even if all subsystems do that 100% efficiently, there may be more savings
> possible by putting the entire system into a sleep state (like on ACPI-based
> PCs) and we can reach there by runtime PM alone.

Right, this is likely to be a win for PCs - for embedded systems we
rarely have other software to interoperate with so if you can make the
hardware do it then it's unlikely there would be any fundamental issue
with Linux doing it at runtime.

> > > I'd be a lot more comfortable with this if it came with a mechanism for
> > > communicating the intended effect of a suspend on a per-device level so
> > > that the drivers have a clear way of figuring out what to do when the
> > > system suspends.  If there isn't one we can add subsystem or driver
> > > specific hooks, of course, but it'd be better to address this at the
> > > system level.

> > I agree.

> I'm not sure.  Why _exactly_ would you need that?

The use case that causes serious issues with this at the minute in the
domains I work is this:

On a mobile phone when the system is in a voice call the data flow for
the call is entirely handled outside the CPU (normally referred to as
Applications Processor or AP here) by the baseband and audio CODEC,
which are either integrated or directly connected by analogue or digital
audio links on the board.  If the user has the phone to their ear and is
talking away with the screen blanked then the AP is just waiting for
input, will appear idle and so trigger an opportunistic suspend.  If the
audio CODEC is managed by Linux (as is standard) then running through
the suspend process will as things stand cause the audio subsystem to be
suspended.  Since in the normal course of affairs suspend means power
down that's what will happen, but this is clearly highly undesirable in
this situation.

Now, the solution here if we're going to use opportunistic suspend like
this is to provide some method for the audio subsystem to figure out
that the system doesn't actually want it to suspend when it gets told do
do so.  Like I say ideally we'd provide some standard interface in the
PM subsystem for userspace to communicate this to subsystems and drivers
so that we've got a joined up story when people run into issues in cases
like this, though obviously if this goes in then we'll have to put in
something subsystem or driver specific for affected areas.  I know what
I'd implement generically for audio, but I've held back since the option
is fairly messy when not used in conjunction with a deliberate choice to
use opportunistic suspend and I was expecting a standard mechanism to
slot into to provide control for userspace.

In other words, the issue is that we run into situations where we need
an element of suspend control to go along with the opportunistic suspend
in order to allow some elements to be kept running - since suspend
blocking is taken suspend suppression seems like a reasonable term.

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 04 May 2010, Kevin Hilman wrote:
> > > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> 
> > Guys, please.
> 
> > The opportunistic suspend feature is _not_ to replace runtime PM by any means!
> 
> Certainly in my case and I think Kevin's I agree with the need for the
> bodge at the minute if we can get a clearer idea of how it's supposed to
> work.
> 
> > when to put devices into low power states and save energy this way.  Still,
> > even if all subsystems do that 100% efficiently, there may be more savings
> > possible by putting the entire system into a sleep state (like on ACPI-based
> > PCs) and we can reach there by runtime PM alone.
> 
> Right, this is likely to be a win for PCs - for embedded systems we
> rarely have other software to interoperate with so if you can make the
> hardware do it then it's unlikely there would be any fundamental issue
> with Linux doing it at runtime.

Evidently, the Android developers had a problem with that.  Of course, you can
argue that they didn't consider using runtime PM for this purpose, but the real
question is how much time it would take to achieve the same level of energy
saving using runtime PM without opportunistic suspend.

> > > > I'd be a lot more comfortable with this if it came with a mechanism for
> > > > communicating the intended effect of a suspend on a per-device level so
> > > > that the drivers have a clear way of figuring out what to do when the
> > > > system suspends.  If there isn't one we can add subsystem or driver
> > > > specific hooks, of course, but it'd be better to address this at the
> > > > system level.
> 
> > > I agree.
> 
> > I'm not sure.  Why _exactly_ would you need that?
> 
> The use case that causes serious issues with this at the minute in the
> domains I work is this:
> 
> On a mobile phone when the system is in a voice call the data flow for
> the call is entirely handled outside the CPU (normally referred to as
> Applications Processor or AP here) by the baseband and audio CODEC,
> which are either integrated or directly connected by analogue or digital
> audio links on the board.  If the user has the phone to their ear and is
> talking away with the screen blanked then the AP is just waiting for
> input, will appear idle and so trigger an opportunistic suspend.  If the
> audio CODEC is managed by Linux (as is standard) then running through
> the suspend process will as things stand cause the audio subsystem to be
> suspended.  Since in the normal course of affairs suspend means power
> down that's what will happen, but this is clearly highly undesirable in
> this situation.

In that case someone (either a driver or, most likely, user space) will need to
keep a suspend blocker active.

> Now, the solution here if we're going to use opportunistic suspend like
> this is to provide some method for the audio subsystem to figure out
> that the system doesn't actually want it to suspend when it gets told do
> do so.  Like I say ideally we'd provide some standard interface in the
> PM subsystem for userspace to communicate this to subsystems and drivers
> so that we've got a joined up story when people run into issues in cases
> like this, though obviously if this goes in then we'll have to put in
> something subsystem or driver specific for affected areas.

My understanding is that on Android suspend blockers are used for this
purpose.

> I know what I'd implement generically for audio, but I've held back since
> the option is fairly messy when not used in conjunction with a deliberate
> choice to use opportunistic suspend and I was expecting a standard mechanism
> to slot into to provide control for userspace.
> 
> In other words, the issue is that we run into situations where we need
> an element of suspend control to go along with the opportunistic suspend
> in order to allow some elements to be kept running - since suspend
> blocking is taken suspend suppression seems like a reasonable term.

Suspend really is a sledgehammer thing.  Either you suspend the whole system
or you don't suspend at all.  You can prevent opportunistic suspend from
happening using suspend blockers (that's what they are for), but that's pretty
much everything you can do about it.  If you want power savings while some
parts of the system are active, use runtime PM for that.

What I'd use opportunistic suspend for is not the saving of energy when there's
a call in progress, because in that case some parts of the system need to be
active, but to save energy when the device is completely idle, ie. the user
interface is not used, music is not played "in the background" etc. (my phone
is in such a state 90% of the time at least).

Rafael

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 04 May 2010, Kevin Hilman wrote:
> > > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> 
> > Guys, please.
> 
> > The opportunistic suspend feature is _not_ to replace runtime PM by any means!
> 
> Certainly in my case and I think Kevin's I agree with the need for the
> bodge at the minute if we can get a clearer idea of how it's supposed to
> work.
> 
> > when to put devices into low power states and save energy this way.  Still,
> > even if all subsystems do that 100% efficiently, there may be more savings
> > possible by putting the entire system into a sleep state (like on ACPI-based
> > PCs) and we can reach there by runtime PM alone.
> 
> Right, this is likely to be a win for PCs - for embedded systems we
> rarely have other software to interoperate with so if you can make the
> hardware do it then it's unlikely there would be any fundamental issue
> with Linux doing it at runtime.

Evidently, the Android developers had a problem with that.  Of course, you can
argue that they didn't consider using runtime PM for this purpose, but the real
question is how much time it would take to achieve the same level of energy
saving using runtime PM without opportunistic suspend.

> > > > I'd be a lot more comfortable with this if it came with a mechanism for
> > > > communicating the intended effect of a suspend on a per-device level so
> > > > that the drivers have a clear way of figuring out what to do when the
> > > > system suspends.  If there isn't one we can add subsystem or driver
> > > > specific hooks, of course, but it'd be better to address this at the
> > > > system level.
> 
> > > I agree.
> 
> > I'm not sure.  Why _exactly_ would you need that?
> 
> The use case that causes serious issues with this at the minute in the
> domains I work is this:
> 
> On a mobile phone when the system is in a voice call the data flow for
> the call is entirely handled outside the CPU (normally referred to as
> Applications Processor or AP here) by the baseband and audio CODEC,
> which are either integrated or directly connected by analogue or digital
> audio links on the board.  If the user has the phone to their ear and is
> talking away with the screen blanked then the AP is just waiting for
> input, will appear idle and so trigger an opportunistic suspend.  If the
> audio CODEC is managed by Linux (as is standard) then running through
> the suspend process will as things stand cause the audio subsystem to be
> suspended.  Since in the normal course of affairs suspend means power
> down that's what will happen, but this is clearly highly undesirable in
> this situation.

In that case someone (either a driver or, most likely, user space) will need to
keep a suspend blocker active.

> Now, the solution here if we're going to use opportunistic suspend like
> this is to provide some method for the audio subsystem to figure out
> that the system doesn't actually want it to suspend when it gets told do
> do so.  Like I say ideally we'd provide some standard interface in the
> PM subsystem for userspace to communicate this to subsystems and drivers
> so that we've got a joined up story when people run into issues in cases
> like this, though obviously if this goes in then we'll have to put in
> something subsystem or driver specific for affected areas.

My understanding is that on Android suspend blockers are used for this
purpose.

> I know what I'd implement generically for audio, but I've held back since
> the option is fairly messy when not used in conjunction with a deliberate
> choice to use opportunistic suspend and I was expecting a standard mechanism
> to slot into to provide control for userspace.
> 
> In other words, the issue is that we run into situations where we need
> an element of suspend control to go along with the opportunistic suspend
> in order to allow some elements to be kept running - since suspend
> blocking is taken suspend suppression seems like a reasonable term.

Suspend really is a sledgehammer thing.  Either you suspend the whole system
or you don't suspend at all.  You can prevent opportunistic suspend from
happening using suspend blockers (that's what they are for), but that's pretty
much everything you can do about it.  If you want power savings while some
parts of the system are active, use runtime PM for that.

What I'd use opportunistic suspend for is not the saving of energy when there's
a call in progress, because in that case some parts of the system need to be
active, but to save energy when the device is completely idle, ie. the user
interface is not used, music is not played "in the background" etc. (my phone
is in such a state 90% of the time at least).

Rafael

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

[Brian Swetland]

On Tue, May 4, 2010 at 5:22 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> In other words, the issue is that we run into situations where we need
>> an element of suspend control to go along with the opportunistic suspend
>> in order to allow some elements to be kept running - since suspend
>> blocking is taken suspend suppression seems like a reasonable term.
>
> Suspend really is a sledgehammer thing.  Either you suspend the whole system
> or you don't suspend at all.  You can prevent opportunistic suspend from
> happening using suspend blockers (that's what they are for), but that's pretty
> much everything you can do about it.  If you want power savings while some
> parts of the system are active, use runtime PM for that.
>
> What I'd use opportunistic suspend for is not the saving of energy when there's
> a call in progress, because in that case some parts of the system need to be
> active, but to save energy when the device is completely idle, ie. the user
> interface is not used, music is not played "in the background" etc. (my phone
> is in such a state 90% of the time at least).

We actually do use opportunistic suspend for cases like this on
Android today.  It mostly comes down to a question of latency for
return from full suspend.  For example:

Some MSM7201 based devices typically resume from power collapse in
3-5ms, but absolute worst case (because the L1 radio services are
higher priority than the wake-the-apps-cpu services) is ~90ms.  On
these devices we hold a suspend_blocker while playing audio.  Before
discovery of this we went into full suspend while playing audio which
worked fine, but in certain network conditions we would drop buffers
if we could not wake fast enough.

So, it's somewhat system dependent, but it can be very helpful in a
lot of cases.

Brian

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

[Brian Swetland]

On Tue, May 4, 2010 at 5:22 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> In other words, the issue is that we run into situations where we need
>> an element of suspend control to go along with the opportunistic suspend
>> in order to allow some elements to be kept running - since suspend
>> blocking is taken suspend suppression seems like a reasonable term.
>
> Suspend really is a sledgehammer thing.  Either you suspend the whole system
> or you don't suspend at all.  You can prevent opportunistic suspend from
> happening using suspend blockers (that's what they are for), but that's pretty
> much everything you can do about it.  If you want power savings while some
> parts of the system are active, use runtime PM for that.
>
> What I'd use opportunistic suspend for is not the saving of energy when there's
> a call in progress, because in that case some parts of the system need to be
> active, but to save energy when the device is completely idle, ie. the user
> interface is not used, music is not played "in the background" etc. (my phone
> is in such a state 90% of the time at least).

We actually do use opportunistic suspend for cases like this on
Android today.  It mostly comes down to a question of latency for
return from full suspend.  For example:

Some MSM7201 based devices typically resume from power collapse in
3-5ms, but absolute worst case (because the L1 radio services are
higher priority than the wake-the-apps-cpu services) is ~90ms.  On
these devices we hold a suspend_blocker while playing audio.  Before
discovery of this we went into full suspend while playing audio which
worked fine, but in certain network conditions we would drop buffers
if we could not wake fast enough.

So, it's somewhat system dependent, but it can be very helpful in a
lot of cases.

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

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote:
> On Wednesday 05 May 2010, Mark Brown wrote:

> > On a mobile phone when the system is in a voice call the data flow for
> > the call is entirely handled outside the CPU (normally referred to as
> > Applications Processor or AP here) by the baseband and audio CODEC,

> In that case someone (either a driver or, most likely, user space) will need to
> keep a suspend blocker active.

That is not actually what Android systems are doing, and if it is what's
supposed to happen then I'd really expect to see a patch to ASoC as part
of this series which shows how this is supposed to be integrated - it's
the sort of thing I'd expect to see some kernel space management for.

Honestly I don't think that's a very good solution for actual systems,
though.  A part of the reasoning behind designing systems in this way is
allowing the AP to go into the lowest possible power state while on a
voice call so it doesn't seem at all unreasonable for the system
integrator to expect that the AP will be driven into the standard low
power state the system uses for it during a call and in a system using
opportunistic suspend that's suspend mode.

> > In other words, the issue is that we run into situations where we need
> > an element of suspend control to go along with the opportunistic suspend
> > in order to allow some elements to be kept running - since suspend
> > blocking is taken suspend suppression seems like a reasonable term.

> Suspend really is a sledgehammer thing.  Either you suspend the whole system
> or you don't suspend at all.  You can prevent opportunistic suspend from
> happening using suspend blockers (that's what they are for), but that's pretty
> much everything you can do about it.  If you want power savings while some
> parts of the system are active, use runtime PM for that.

On the one hand that's the answer that works well with the existing
Linux design here so great.  On the other hand as discussed above that
doesn't match so well with user expectations.

> What I'd use opportunistic suspend for is not the saving of energy when there's
> a call in progress, because in that case some parts of the system need to be
> active, but to save energy when the device is completely idle, ie. the user
> interface is not used, music is not played "in the background" etc. (my phone
> is in such a state 90% of the time at least).

Remember that even in your full system suspend the system is not
actually fully idle - the baseband is still sitting there looking after
itself, keeping the phone on the network.  The only difference between
on call and off call from the point of view of the Linux system is that
there is an active audio path which happens to have been set up by the
Linux system.

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

[Mark Brown]

On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote:
> On Wednesday 05 May 2010, Mark Brown wrote:

> > On a mobile phone when the system is in a voice call the data flow for
> > the call is entirely handled outside the CPU (normally referred to as
> > Applications Processor or AP here) by the baseband and audio CODEC,

> In that case someone (either a driver or, most likely, user space) will need to
> keep a suspend blocker active.

That is not actually what Android systems are doing, and if it is what's
supposed to happen then I'd really expect to see a patch to ASoC as part
of this series which shows how this is supposed to be integrated - it's
the sort of thing I'd expect to see some kernel space management for.

Honestly I don't think that's a very good solution for actual systems,
though.  A part of the reasoning behind designing systems in this way is
allowing the AP to go into the lowest possible power state while on a
voice call so it doesn't seem at all unreasonable for the system
integrator to expect that the AP will be driven into the standard low
power state the system uses for it during a call and in a system using
opportunistic suspend that's suspend mode.

> > In other words, the issue is that we run into situations where we need
> > an element of suspend control to go along with the opportunistic suspend
> > in order to allow some elements to be kept running - since suspend
> > blocking is taken suspend suppression seems like a reasonable term.

> Suspend really is a sledgehammer thing.  Either you suspend the whole system
> or you don't suspend at all.  You can prevent opportunistic suspend from
> happening using suspend blockers (that's what they are for), but that's pretty
> much everything you can do about it.  If you want power savings while some
> parts of the system are active, use runtime PM for that.

On the one hand that's the answer that works well with the existing
Linux design here so great.  On the other hand as discussed above that
doesn't match so well with user expectations.

> What I'd use opportunistic suspend for is not the saving of energy when there's
> a call in progress, because in that case some parts of the system need to be
> active, but to save energy when the device is completely idle, ie. the user
> interface is not used, music is not played "in the background" etc. (my phone
> is in such a state 90% of the time at least).

Remember that even in your full system suspend the system is not
actually fully idle - the baseband is still sitting there looking after
itself, keeping the phone on the network.  The only difference between
on call and off call from the point of view of the Linux system is that
there is an active audio path which happens to have been set up by the
Linux system.

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

[Brian Swetland]

On Wed, May 5, 2010 at 4:06 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote:
>> On Wednesday 05 May 2010, Mark Brown wrote:
>
>> > On a mobile phone when the system is in a voice call the data flow for
>> > the call is entirely handled outside the CPU (normally referred to as
>> > Applications Processor or AP here) by the baseband and audio CODEC,
>
>> In that case someone (either a driver or, most likely, user space) will need to
>> keep a suspend blocker active.
>
> That is not actually what Android systems are doing, and if it is what's
> supposed to happen then I'd really expect to see a patch to ASoC as part
> of this series which shows how this is supposed to be integrated - it's
> the sort of thing I'd expect to see some kernel space management for.
>
> Honestly I don't think that's a very good solution for actual systems,
> though.  A part of the reasoning behind designing systems in this way is
> allowing the AP to go into the lowest possible power state while on a
> voice call so it doesn't seem at all unreasonable for the system
> integrator to expect that the AP will be driven into the standard low
> power state the system uses for it during a call and in a system using
> opportunistic suspend that's suspend mode.

Yup.  And that's exactly what happens on the platforms we've shipped
on so far -- the apps side of the world fully suspends while in a
voice call.  Some events (prox sensor, buttons, modem sending a state
notification) will wake it up, of course.

I haven't spent much time looking at alsa/asoc yet, but it's on my
list for 2010 -- I'm hoping to migrate the very simple audio drivers I
wrote for the msm platform originally to actually be alsa drivers as
part of the general "try to use existing interfaces if they fit" plan
we've been working toward.

The suspend_block system gets us what we need today (well what we
needed three years ago too!) to ship and hit reasonable power targets
on a number of platforms.  There's been a lot of various handwaving
about "android kernel forks" and what have you, but here we are again,
trying to work out perhaps the only "new subsystem" type change that
our driver code depends on (almost all other contentious stuff is self
contained and you can take or leave it).

Our hope here is to get something out there in the near term so that
the various drivers we maintain would "just work" in mainline (your
choice of if you use suspend_block or not -- it's designed to be an
option) and we can move forward.  If in the future runtime power
management or other systems completely obsolete suspend_blockers,
awesome, we remove 'em.

Brian

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

[Brian Swetland]

On Wed, May 5, 2010 at 4:06 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote:
>> On Wednesday 05 May 2010, Mark Brown wrote:
>
>> > On a mobile phone when the system is in a voice call the data flow for
>> > the call is entirely handled outside the CPU (normally referred to as
>> > Applications Processor or AP here) by the baseband and audio CODEC,
>
>> In that case someone (either a driver or, most likely, user space) will need to
>> keep a suspend blocker active.
>
> That is not actually what Android systems are doing, and if it is what's
> supposed to happen then I'd really expect to see a patch to ASoC as part
> of this series which shows how this is supposed to be integrated - it's
> the sort of thing I'd expect to see some kernel space management for.
>
> Honestly I don't think that's a very good solution for actual systems,
> though.  A part of the reasoning behind designing systems in this way is
> allowing the AP to go into the lowest possible power state while on a
> voice call so it doesn't seem at all unreasonable for the system
> integrator to expect that the AP will be driven into the standard low
> power state the system uses for it during a call and in a system using
> opportunistic suspend that's suspend mode.

Yup.  And that's exactly what happens on the platforms we've shipped
on so far -- the apps side of the world fully suspends while in a
voice call.  Some events (prox sensor, buttons, modem sending a state
notification) will wake it up, of course.

I haven't spent much time looking at alsa/asoc yet, but it's on my
list for 2010 -- I'm hoping to migrate the very simple audio drivers I
wrote for the msm platform originally to actually be alsa drivers as
part of the general "try to use existing interfaces if they fit" plan
we've been working toward.

The suspend_block system gets us what we need today (well what we
needed three years ago too!) to ship and hit reasonable power targets
on a number of platforms.  There's been a lot of various handwaving
about "android kernel forks" and what have you, but here we are again,
trying to work out perhaps the only "new subsystem" type change that
our driver code depends on (almost all other contentious stuff is self
contained and you can take or leave it).

Our hope here is to get something out there in the near term so that
the various drivers we maintain would "just work" in mainline (your
choice of if you use suspend_block or not -- it's designed to be an
option) and we can move forward.  If in the future runtime power
management or other systems completely obsolete suspend_blockers,
awesome, we remove 'em.

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

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 05:00:33AM -0700, Brian Swetland wrote:

> I haven't spent much time looking at alsa/asoc yet, but it's on my
> list for 2010 -- I'm hoping to migrate the very simple audio drivers I
> wrote for the msm platform originally to actually be alsa drivers as
> part of the general "try to use existing interfaces if they fit" plan
> we've been working toward.

Yup, that'd be good - even with the AP/CP/CODEC SoCs like the MSM
devices we really need to get ASoC integration since systems are being
built hanging external components such as speaker drivers off the line
outputs, and some of those have registers so really do benefit from the
sequencing, automated PM and so on that ASoC offers.

There was some work on MSM ASoC support posted last year back but there
were a number of review issues with it.  Daniel Walker also talked about
submitting stuff just before Christmas, quite possibly independently of
the other work which looked like a community effort, but I've not seen
anything through from that yet.

> The suspend_block system gets us what we need today (well what we
> needed three years ago too!) to ship and hit reasonable power targets
> on a number of platforms.  There's been a lot of various handwaving
> about "android kernel forks" and what have you, but here we are again,
> trying to work out perhaps the only "new subsystem" type change that
> our driver code depends on (almost all other contentious stuff is self
> contained and you can take or leave it).

> Our hope here is to get something out there in the near term so that
> the various drivers we maintain would "just work" in mainline (your
> choice of if you use suspend_block or not -- it's designed to be an
> option) and we can move forward.  If in the future runtime power
> management or other systems completely obsolete suspend_blockers,
> awesome, we remove 'em.

Like I've said a few times here I broadly agree with your goals - they
seem to be a reasonable solution to the engineering problems we face
presently, even though they're not where we actually want to be.  What
I do miss from the current proposal is more consideration of how things
that do need to ignore the suspend should integrate.

If the conclusion is that we don't have anything generic within the
kernel then it'd be good to at least have this explicitly spelled out so
that we're clear what everyone thinks is going on here and how things
are supposed to work.  At the minute it doesn't feel like we've had the
discussion so we could end up working at cross purposes.  I don't want
to end up in the situation where I have to work around the APIs I'm
using without the relevant maintainers having sight of that since that
not only am I likely to be missing some existing solution to the problem
but is also prone to causing problems maintaining the underlying API.

This hasn't been a pressing issue while the Android code is out of tree
since we can just say it's an out of tree patch that has a different
design approach to current mainline and it's fairly straightforward for
users to introduce suitable system-specific changes.  Once it's mainline
and part of the standard Linux PM toolkit then obviously subsystems and
drivers need to support opportunistic suspend properly in mainline.

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

[Mark Brown]

On Wed, May 05, 2010 at 05:00:33AM -0700, Brian Swetland wrote:

> I haven't spent much time looking at alsa/asoc yet, but it's on my
> list for 2010 -- I'm hoping to migrate the very simple audio drivers I
> wrote for the msm platform originally to actually be alsa drivers as
> part of the general "try to use existing interfaces if they fit" plan
> we've been working toward.

Yup, that'd be good - even with the AP/CP/CODEC SoCs like the MSM
devices we really need to get ASoC integration since systems are being
built hanging external components such as speaker drivers off the line
outputs, and some of those have registers so really do benefit from the
sequencing, automated PM and so on that ASoC offers.

There was some work on MSM ASoC support posted last year back but there
were a number of review issues with it.  Daniel Walker also talked about
submitting stuff just before Christmas, quite possibly independently of
the other work which looked like a community effort, but I've not seen
anything through from that yet.

> The suspend_block system gets us what we need today (well what we
> needed three years ago too!) to ship and hit reasonable power targets
> on a number of platforms.  There's been a lot of various handwaving
> about "android kernel forks" and what have you, but here we are again,
> trying to work out perhaps the only "new subsystem" type change that
> our driver code depends on (almost all other contentious stuff is self
> contained and you can take or leave it).

> Our hope here is to get something out there in the near term so that
> the various drivers we maintain would "just work" in mainline (your
> choice of if you use suspend_block or not -- it's designed to be an
> option) and we can move forward.  If in the future runtime power
> management or other systems completely obsolete suspend_blockers,
> awesome, we remove 'em.

Like I've said a few times here I broadly agree with your goals - they
seem to be a reasonable solution to the engineering problems we face
presently, even though they're not where we actually want to be.  What
I do miss from the current proposal is more consideration of how things
that do need to ignore the suspend should integrate.

If the conclusion is that we don't have anything generic within the
kernel then it'd be good to at least have this explicitly spelled out so
that we're clear what everyone thinks is going on here and how things
are supposed to work.  At the minute it doesn't feel like we've had the
discussion so we could end up working at cross purposes.  I don't want
to end up in the situation where I have to work around the APIs I'm
using without the relevant maintainers having sight of that since that
not only am I likely to be missing some existing solution to the problem
but is also prone to causing problems maintaining the underlying API.

This hasn't been a pressing issue while the Android code is out of tree
since we can just say it's an out of tree patch that has a different
design approach to current mainline and it's fairly straightforward for
users to introduce suitable system-specific changes.  Once it's mainline
and part of the standard Linux PM toolkit then obviously subsystems and
drivers need to support opportunistic suspend properly in mainline.

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

[Alan Stern]

On Wed, 5 May 2010, Mark Brown wrote:

> Now, the solution here if we're going to use opportunistic suspend like
> this is to provide some method for the audio subsystem to figure out
> that the system doesn't actually want it to suspend when it gets told do
> do so.  Like I say ideally we'd provide some standard interface in the
> PM subsystem for userspace to communicate this to subsystems and drivers
> so that we've got a joined up story when people run into issues in cases
> like this, though obviously if this goes in then we'll have to put in
> something subsystem or driver specific for affected areas.  I know what
> I'd implement generically for audio, but I've held back since the option
> is fairly messy when not used in conjunction with a deliberate choice to
> use opportunistic suspend and I was expecting a standard mechanism to
> slot into to provide control for userspace.
> 
> In other words, the issue is that we run into situations where we need
> an element of suspend control to go along with the opportunistic suspend
> in order to allow some elements to be kept running - since suspend
> blocking is taken suspend suppression seems like a reasonable term.

Android must already include some solution to this problem.  Why not 
use that solution more generally?

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Mark Brown wrote:

> Now, the solution here if we're going to use opportunistic suspend like
> this is to provide some method for the audio subsystem to figure out
> that the system doesn't actually want it to suspend when it gets told do
> do so.  Like I say ideally we'd provide some standard interface in the
> PM subsystem for userspace to communicate this to subsystems and drivers
> so that we've got a joined up story when people run into issues in cases
> like this, though obviously if this goes in then we'll have to put in
> something subsystem or driver specific for affected areas.  I know what
> I'd implement generically for audio, but I've held back since the option
> is fairly messy when not used in conjunction with a deliberate choice to
> use opportunistic suspend and I was expecting a standard mechanism to
> slot into to provide control for userspace.
> 
> In other words, the issue is that we run into situations where we need
> an element of suspend control to go along with the opportunistic suspend
> in order to allow some elements to be kept running - since suspend
> blocking is taken suspend suppression seems like a reasonable term.

Android must already include some solution to this problem.  Why not 
use that solution more generally?

Alan Stern

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 11:35:56AM -0400, Alan Stern wrote:
> On Wed, 5 May 2010, Mark Brown wrote:

> > In other words, the issue is that we run into situations where we need
> > an element of suspend control to go along with the opportunistic suspend
> > in order to allow some elements to be kept running - since suspend
> > blocking is taken suspend suppression seems like a reasonable term.

> Android must already include some solution to this problem.  Why not 
> use that solution more generally?

Not so much; at least for audio it's being handled with platform
specific bodges as far as I've seen so far.  If there had been a
standard way of doing this I'd have expected to see it in this patch
series.  The Google systems all use Qualcomm chipsets which aren't
affected by this since the audio CODEC is hidden from Linux and none of
the audio actually uses ALSA at all in the BSPs I looked at.

It's entirely possible I'm missing something here, everything I know has
come from either talking to users or trawling code on the internet.

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

[Mark Brown]

On Wed, May 05, 2010 at 11:35:56AM -0400, Alan Stern wrote:
> On Wed, 5 May 2010, Mark Brown wrote:

> > In other words, the issue is that we run into situations where we need
> > an element of suspend control to go along with the opportunistic suspend
> > in order to allow some elements to be kept running - since suspend
> > blocking is taken suspend suppression seems like a reasonable term.

> Android must already include some solution to this problem.  Why not 
> use that solution more generally?

Not so much; at least for audio it's being handled with platform
specific bodges as far as I've seen so far.  If there had been a
standard way of doing this I'd have expected to see it in this patch
series.  The Google systems all use Qualcomm chipsets which aren't
affected by this since the audio CODEC is hidden from Linux and none of
the audio actually uses ALSA at all in the BSPs I looked at.

It's entirely possible I'm missing something here, everything I know has
come from either talking to users or trawling code on the internet.

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

[Matthew Garrett]

On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:

> If the conclusion is that we don't have anything generic within the
> kernel then it'd be good to at least have this explicitly spelled out so
> that we're clear what everyone thinks is going on here and how things
> are supposed to work.  At the minute it doesn't feel like we've had the
> discussion so we could end up working at cross purposes.  I don't want
> to end up in the situation where I have to work around the APIs I'm
> using without the relevant maintainers having sight of that since that
> not only am I likely to be missing some existing solution to the problem
> but is also prone to causing problems maintaining the underlying API.

We seem to have ended up managing most of our PM infrastructure 
iteratively. If the concern is more about best practices than intrinsic 
incompatibilities, I'd lean towards us being better off merging this now 
and then working things out over the next few releases as we get a 
better understanding of the implications. The main thing that we have to 
get right in the short term is the userspace API - everything else is 
easier to fix up as we go along.

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:

> If the conclusion is that we don't have anything generic within the
> kernel then it'd be good to at least have this explicitly spelled out so
> that we're clear what everyone thinks is going on here and how things
> are supposed to work.  At the minute it doesn't feel like we've had the
> discussion so we could end up working at cross purposes.  I don't want
> to end up in the situation where I have to work around the APIs I'm
> using without the relevant maintainers having sight of that since that
> not only am I likely to be missing some existing solution to the problem
> but is also prone to causing problems maintaining the underlying API.

We seem to have ended up managing most of our PM infrastructure 
iteratively. If the concern is more about best practices than intrinsic 
incompatibilities, I'd lean towards us being better off merging this now 
and then working things out over the next few releases as we get a 
better understanding of the implications. The main thing that we have to 
get right in the short term is the userspace API - everything else is 
easier to fix up as we go along.

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

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:
> 
> > If the conclusion is that we don't have anything generic within the
> > kernel then it'd be good to at least have this explicitly spelled out so
> > that we're clear what everyone thinks is going on here and how things
> > are supposed to work.  At the minute it doesn't feel like we've had the
> > discussion so we could end up working at cross purposes.  I don't want
> > to end up in the situation where I have to work around the APIs I'm
> > using without the relevant maintainers having sight of that since that
> > not only am I likely to be missing some existing solution to the problem
> > but is also prone to causing problems maintaining the underlying API.
> 
> We seem to have ended up managing most of our PM infrastructure 
> iteratively. If the concern is more about best practices than intrinsic 
> incompatibilities, I'd lean towards us being better off merging this now 
> and then working things out over the next few releases as we get a 
> better understanding of the implications. The main thing that we have to 
> get right in the short term is the userspace API - everything else is 
> easier to fix up as we go along.

This particular question could use a little more discussion.  I'm
interested to know, for example, under what conditions you would or
would not want to shut down an autonomous codec while going into system 
suspend on a cell phone.

Clearly if there's a call in progress you don't want to shut the codec
down.  Are there any other circumstances?  Would they vary according to
whether the suspend was forced or opportunistic?

In short, I'm trying to get at how much information drivers _really_ 
need to have about the reason for a system suspend.

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:
> 
> > If the conclusion is that we don't have anything generic within the
> > kernel then it'd be good to at least have this explicitly spelled out so
> > that we're clear what everyone thinks is going on here and how things
> > are supposed to work.  At the minute it doesn't feel like we've had the
> > discussion so we could end up working at cross purposes.  I don't want
> > to end up in the situation where I have to work around the APIs I'm
> > using without the relevant maintainers having sight of that since that
> > not only am I likely to be missing some existing solution to the problem
> > but is also prone to causing problems maintaining the underlying API.
> 
> We seem to have ended up managing most of our PM infrastructure 
> iteratively. If the concern is more about best practices than intrinsic 
> incompatibilities, I'd lean towards us being better off merging this now 
> and then working things out over the next few releases as we get a 
> better understanding of the implications. The main thing that we have to 
> get right in the short term is the userspace API - everything else is 
> easier to fix up as we go along.

This particular question could use a little more discussion.  I'm
interested to know, for example, under what conditions you would or
would not want to shut down an autonomous codec while going into system 
suspend on a cell phone.

Clearly if there's a call in progress you don't want to shut the codec
down.  Are there any other circumstances?  Would they vary according to
whether the suspend was forced or opportunistic?

In short, I'm trying to get at how much information drivers _really_ 
need to have about the reason for a system suspend.

Alan Stern

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

[Mark Brown]

On Wed, May 05, 2010 at 06:33:37PM +0100, Matthew Garrett wrote:

> We seem to have ended up managing most of our PM infrastructure 
> iteratively. If the concern is more about best practices than intrinsic 
> incompatibilities, I'd lean towards us being better off merging this now 
> and then working things out over the next few releases as we get a 
> better understanding of the implications. The main thing that we have to 
> get right in the short term is the userspace API - everything else is 
> easier to fix up as we go along.

Right, the big issue for me is that there's likely to be some form of
userspace API visible for controlling this.  I think I can keep it
mostly in-kernel for audio (by providing new APIs to mark some inputs
and outputs as being live during suspend) but need to check.

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

[Mark Brown]

On Wed, May 05, 2010 at 06:33:37PM +0100, Matthew Garrett wrote:

> We seem to have ended up managing most of our PM infrastructure 
> iteratively. If the concern is more about best practices than intrinsic 
> incompatibilities, I'd lean towards us being better off merging this now 
> and then working things out over the next few releases as we get a 
> better understanding of the implications. The main thing that we have to 
> get right in the short term is the userspace API - everything else is 
> easier to fix up as we go along.

Right, the big issue for me is that there's likely to be some form of
userspace API visible for controlling this.  I think I can keep it
mostly in-kernel for audio (by providing new APIs to mark some inputs
and outputs as being live during suspend) but need to check.

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

[Matthew Garrett]

On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> This particular question could use a little more discussion.  I'm
> interested to know, for example, under what conditions you would or
> would not want to shut down an autonomous codec while going into system 
> suspend on a cell phone.
> 
> Clearly if there's a call in progress you don't want to shut the codec
> down.  Are there any other circumstances?  Would they vary according to
> whether the suspend was forced or opportunistic?

Yeah, ok. We probably do need to figure this out.

(Cc:ing Rebecca to see how this got handled on Droid)

The current state of affairs is that a system suspend request is 
expected to put the device in as low a power state as possible given the 
required wakeup events. Runtime power management is expected to put the 
device in as low a power state as possible given its usage constraints. 
If opportunistic suspend does the former then it'll tear down devices 
that may be in use, but we don't have any real way to indicate usage 
constraints other than the phone app taking a wakelock - and that means 
leaving userspace running during calls, which seems excessive.

Mark's right in that the only case I can think of that's really relevant 
right now is the audio hardware, so the inelegant solution is that this 
is something that could be provided at the audio level. Is this 
something we want a generic solution for? If so, what should it look 
like?

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> This particular question could use a little more discussion.  I'm
> interested to know, for example, under what conditions you would or
> would not want to shut down an autonomous codec while going into system 
> suspend on a cell phone.
> 
> Clearly if there's a call in progress you don't want to shut the codec
> down.  Are there any other circumstances?  Would they vary according to
> whether the suspend was forced or opportunistic?

Yeah, ok. We probably do need to figure this out.

(Cc:ing Rebecca to see how this got handled on Droid)

The current state of affairs is that a system suspend request is 
expected to put the device in as low a power state as possible given the 
required wakeup events. Runtime power management is expected to put the 
device in as low a power state as possible given its usage constraints. 
If opportunistic suspend does the former then it'll tear down devices 
that may be in use, but we don't have any real way to indicate usage 
constraints other than the phone app taking a wakelock - and that means 
leaving userspace running during calls, which seems excessive.

Mark's right in that the only case I can think of that's really relevant 
right now is the audio hardware, so the inelegant solution is that this 
is something that could be provided at the audio level. Is this 
something we want a generic solution for? If so, what should it look 
like?

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

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

[Mark Brown]

On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> Clearly if there's a call in progress you don't want to shut the codec
> down.  Are there any other circumstances?  Would they vary according to
> whether the suspend was forced or opportunistic?

Aside from things where the CODEC is acting as a wake source (for stuff
like jack detect) which are obviously already handled it's basically
just when you've got an external audio source flowing through the device
which is going to continue to function during suspend.  Things like FM
radios, for example.  I'm not aware of non-audio examples that are use
case specific and don't just involve utterly ignoring AP suspends.

> In short, I'm trying to get at how much information drivers _really_ 
> need to have about the reason for a system suspend.

It's not exactly the *reason* that makes the difference, it's more that
this aggressive use of suspend makes much more apparent a problem which
might exist anyway for this sort of hardware.

When we get runtime PM delviering similar power levels we'll sidestep
the problem since we won't need to do a system wide suspend.

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

[Mark Brown]

On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> Clearly if there's a call in progress you don't want to shut the codec
> down.  Are there any other circumstances?  Would they vary according to
> whether the suspend was forced or opportunistic?

Aside from things where the CODEC is acting as a wake source (for stuff
like jack detect) which are obviously already handled it's basically
just when you've got an external audio source flowing through the device
which is going to continue to function during suspend.  Things like FM
radios, for example.  I'm not aware of non-audio examples that are use
case specific and don't just involve utterly ignoring AP suspends.

> In short, I'm trying to get at how much information drivers _really_ 
> need to have about the reason for a system suspend.

It's not exactly the *reason* that makes the difference, it's more that
this aggressive use of suspend makes much more apparent a problem which
might exist anyway for this sort of hardware.

When we get runtime PM delviering similar power levels we'll sidestep
the problem since we won't need to do a system wide suspend.

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> > Clearly if there's a call in progress you don't want to shut the codec
> > down.  Are there any other circumstances?  Would they vary according to
> > whether the suspend was forced or opportunistic?
> 
> Yeah, ok. We probably do need to figure this out.
> 
> (Cc:ing Rebecca to see how this got handled on Droid)
> 
> The current state of affairs is that a system suspend request is 
> expected to put the device in as low a power state as possible given the 
> required wakeup events. Runtime power management is expected to put the 
> device in as low a power state as possible given its usage constraints. 
> If opportunistic suspend does the former then it'll tear down devices 
> that may be in use, but we don't have any real way to indicate usage 
> constraints other than the phone app taking a wakelock - and that means 
> leaving userspace running during calls, which seems excessive.
> 
> Mark's right in that the only case I can think of that's really relevant 
> right now is the audio hardware, so the inelegant solution is that this 
> is something that could be provided at the audio level. Is this 
> something we want a generic solution for? If so, what should it look 
> like?

Should the audio driver be smart enough to know that the codec needs to
remain powered up during every opportunistic suspend?

Or only during opportunistic suspends while a call is in progress?  

Does it know when a call is in progress?

Does Android use forced suspends?

If it does, are they supposed to shut down the codec?

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> > Clearly if there's a call in progress you don't want to shut the codec
> > down.  Are there any other circumstances?  Would they vary according to
> > whether the suspend was forced or opportunistic?
> 
> Yeah, ok. We probably do need to figure this out.
> 
> (Cc:ing Rebecca to see how this got handled on Droid)
> 
> The current state of affairs is that a system suspend request is 
> expected to put the device in as low a power state as possible given the 
> required wakeup events. Runtime power management is expected to put the 
> device in as low a power state as possible given its usage constraints. 
> If opportunistic suspend does the former then it'll tear down devices 
> that may be in use, but we don't have any real way to indicate usage 
> constraints other than the phone app taking a wakelock - and that means 
> leaving userspace running during calls, which seems excessive.
> 
> Mark's right in that the only case I can think of that's really relevant 
> right now is the audio hardware, so the inelegant solution is that this 
> is something that could be provided at the audio level. Is this 
> something we want a generic solution for? If so, what should it look 
> like?

Should the audio driver be smart enough to know that the codec needs to
remain powered up during every opportunistic suspend?

Or only during opportunistic suspends while a call is in progress?  

Does it know when a call is in progress?

Does Android use forced suspends?

If it does, are they supposed to shut down the codec?

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Mark Brown wrote:

> > In short, I'm trying to get at how much information drivers _really_ 
> > need to have about the reason for a system suspend.
> 
> It's not exactly the *reason* that makes the difference, it's more that
> this aggressive use of suspend makes much more apparent a problem which
> might exist anyway for this sort of hardware.

Then the underlying problem should be solved -- hopefully in a nice, 
system-independent way.  But I'm still trying to understand exactly 
what that underlying problem _is_.

That means understanding when the codec needs to be shut down and when
it doesn't, and knowing how much of this information is available to
the driver.

> When we get runtime PM delviering similar power levels we'll sidestep
> the problem since we won't need to do a system wide suspend.

One the face of it, a runtime-PM solution would dictate that the
codec's driver ought to turn off the codec whenever the driver thinks
it isn't being used.  Ergo, if the driver didn't know when a call was
in progress, it would use runtime PM to turn off the codec during a
call.

For this reason I don't see how using runtime PM instead of suspend
blockers would solve anything.

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Mark Brown wrote:

> > In short, I'm trying to get at how much information drivers _really_ 
> > need to have about the reason for a system suspend.
> 
> It's not exactly the *reason* that makes the difference, it's more that
> this aggressive use of suspend makes much more apparent a problem which
> might exist anyway for this sort of hardware.

Then the underlying problem should be solved -- hopefully in a nice, 
system-independent way.  But I'm still trying to understand exactly 
what that underlying problem _is_.

That means understanding when the codec needs to be shut down and when
it doesn't, and knowing how much of this information is available to
the driver.

> When we get runtime PM delviering similar power levels we'll sidestep
> the problem since we won't need to do a system wide suspend.

One the face of it, a runtime-PM solution would dictate that the
codec's driver ought to turn off the codec whenever the driver thinks
it isn't being used.  Ergo, if the driver didn't know when a call was
in progress, it would use runtime PM to turn off the codec during a
call.

For this reason I don't see how using runtime PM instead of suspend
blockers would solve anything.

Alan Stern

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

[Matthew Garrett]

On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?
> 
> Or only during opportunistic suspends while a call is in progress?  

The latter is obviously preferable...

> Does it know when a call is in progress?

Perhaps you could infer that from the audio routing setup? I don't know 
enough about embedded codecs.

> Does Android use forced suspends?

No.

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?
> 
> Or only during opportunistic suspends while a call is in progress?  

The latter is obviously preferable...

> Does it know when a call is in progress?

Perhaps you could infer that from the audio routing setup? I don't know 
enough about embedded codecs.

> Does Android use forced suspends?

No.

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:

> One the face of it, a runtime-PM solution would dictate that the
> codec's driver ought to turn off the codec whenever the driver thinks
> it isn't being used.  Ergo, if the driver didn't know when a call was
> in progress, it would use runtime PM to turn off the codec during a
> call.

Well, part of the problem is that right now most of our beliefs about 
imposed constraints tend to be based on what userspace is doing - "Don't 
power down the audio codec when userspace has it open", for instance. 
But that goes away with opportunistic suspend. In most cases you don't 
want the audio codec to stay awake just because userspace was using it 
to make bouncing cow noises, especially if you've just frozen userspace. 
So the problem becomes more complicated than it would otherwise be.

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:

> One the face of it, a runtime-PM solution would dictate that the
> codec's driver ought to turn off the codec whenever the driver thinks
> it isn't being used.  Ergo, if the driver didn't know when a call was
> in progress, it would use runtime PM to turn off the codec during a
> call.

Well, part of the problem is that right now most of our beliefs about 
imposed constraints tend to be based on what userspace is doing - "Don't 
power down the audio codec when userspace has it open", for instance. 
But that goes away with opportunistic suspend. In most cases you don't 
want the audio codec to stay awake just because userspace was using it 
to make bouncing cow noises, especially if you've just frozen userspace. 
So the problem becomes more complicated than it would otherwise be.

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

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

[Mark Brown]

On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?

> Or only during opportunistic suspends while a call is in progress?  

I think for simplicity and maximum flexibility we should just ignore the
reason for suspend here, if I'm adding support for this in the drivers
the suspend reason is not going to be terribly useful and it makes the
feature more widely useful should people come up with other applications.

Note that we already have advanced runtime PM for embedded audio which
will drive modern CODECs into full off state when the device is idle
anyway, independently of any suspend or runtime PM that the system does.
Older CODECs need their bias levels maintaining but we can ignore the
difference there from this point of view.

> Does it know when a call is in progress?

Not at present.  This is relatively straightforward to add within ASoC,
especially for analogue links, if not completely trivial.  Digital
basebands are a bit more fun but not insurmountable (and need cleaning
up anyway, there's some ongoing work which should hit soon).

We currently drive everything into off state when we're told to suspend
since it's the right thing to do for most non-phone devices.  We'll
still need to drive some of the system into an off state (eg, some of
the drivers in the CPU) even when this is handled.

> Does Android use forced suspends?

Pass, but it's not been an issue users have raised with me - but then
we can't tell why the suspend happens and need to handle opportunistic
suspend anyway.

> If it does, are they supposed to shut down the codec?

I suspect it's a non-issue; if we're not actually using audio then ASoC
will drive a modern CODEC into power off anyway as part of its runtime
PM.  However, I believe some non-Android phone stacks are doing
something along that line.

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

[Mark Brown]

On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?

> Or only during opportunistic suspends while a call is in progress?  

I think for simplicity and maximum flexibility we should just ignore the
reason for suspend here, if I'm adding support for this in the drivers
the suspend reason is not going to be terribly useful and it makes the
feature more widely useful should people come up with other applications.

Note that we already have advanced runtime PM for embedded audio which
will drive modern CODECs into full off state when the device is idle
anyway, independently of any suspend or runtime PM that the system does.
Older CODECs need their bias levels maintaining but we can ignore the
difference there from this point of view.

> Does it know when a call is in progress?

Not at present.  This is relatively straightforward to add within ASoC,
especially for analogue links, if not completely trivial.  Digital
basebands are a bit more fun but not insurmountable (and need cleaning
up anyway, there's some ongoing work which should hit soon).

We currently drive everything into off state when we're told to suspend
since it's the right thing to do for most non-phone devices.  We'll
still need to drive some of the system into an off state (eg, some of
the drivers in the CPU) even when this is handled.

> Does Android use forced suspends?

Pass, but it's not been an issue users have raised with me - but then
we can't tell why the suspend happens and need to handle opportunistic
suspend anyway.

> If it does, are they supposed to shut down the codec?

I suspect it's a non-issue; if we're not actually using audio then ASoC
will drive a modern CODEC into power off anyway as part of its runtime
PM.  However, I believe some non-Android phone stacks are doing
something along that line.

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

[Mark Brown]

On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> > Does it know when a call is in progress?

> Perhaps you could infer that from the audio routing setup? I don't know 
> enough about embedded codecs.

Yes, you can providing we extract a bit more information from the
machine drivers and/or userspace - we already do our power management
based on paths.  The implementation I'd do here is to provide a facility
for marking some of the path endpoints as suspend insensitive then on
suspend leave those endpoints in their current state, force the other
endpoints off temporarily and re-run the standard power checks.

One thing I'll need to have a bit of a think about is if we need to
provide the ability to offer control to userspace for the suspend state
of path endpoints separately to their runtime state; I suspect the
answer is yes.

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

[Mark Brown]

On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:

> > Does it know when a call is in progress?

> Perhaps you could infer that from the audio routing setup? I don't know 
> enough about embedded codecs.

Yes, you can providing we extract a bit more information from the
machine drivers and/or userspace - we already do our power management
based on paths.  The implementation I'd do here is to provide a facility
for marking some of the path endpoints as suspend insensitive then on
suspend leave those endpoints in their current state, force the other
endpoints off temporarily and re-run the standard power checks.

One thing I'll need to have a bit of a think about is if we need to
provide the ability to offer control to userspace for the suspend state
of path endpoints separately to their runtime state; I suspect the
answer is yes.

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

[tytso]

Hi Mark,

I confess I've completely lost track of (a) what problem you are
trying to solve, and (b) how this might relate to some change that
you'd like to see in the suspend block API.  Could you do a quick
summary and recap?  I've gone over the entire thread, and it's still
not clear what change you're advocating for in suspend blockers.

Thanks, regards,

						- Ted

On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote:
> On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> > On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:
> 
> > > Does it know when a call is in progress?
> 
> > Perhaps you could infer that from the audio routing setup? I don't know 
> > enough about embedded codecs.
> 
> Yes, you can providing we extract a bit more information from the
> machine drivers and/or userspace - we already do our power management
> based on paths.  The implementation I'd do here is to provide a facility
> for marking some of the path endpoints as suspend insensitive then on
> suspend leave those endpoints in their current state, force the other
> endpoints off temporarily and re-run the standard power checks.
> 
> One thing I'll need to have a bit of a think about is if we need to
> provide the ability to offer control to userspace for the suspend state
> of path endpoints separately to their runtime state; I suspect the
> answer is yes.
> --
> 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/

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

[tytso]

Hi Mark,

I confess I've completely lost track of (a) what problem you are
trying to solve, and (b) how this might relate to some change that
you'd like to see in the suspend block API.  Could you do a quick
summary and recap?  I've gone over the entire thread, and it's still
not clear what change you're advocating for in suspend blockers.

Thanks, regards,

						- Ted

On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote:
> On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> > On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote:
> 
> > > Does it know when a call is in progress?
> 
> > Perhaps you could infer that from the audio routing setup? I don't know 
> > enough about embedded codecs.
> 
> Yes, you can providing we extract a bit more information from the
> machine drivers and/or userspace - we already do our power management
> based on paths.  The implementation I'd do here is to provide a facility
> for marking some of the path endpoints as suspend insensitive then on
> suspend leave those endpoints in their current state, force the other
> endpoints off temporarily and re-run the standard power checks.
> 
> One thing I'll need to have a bit of a think about is if we need to
> provide the ability to offer control to userspace for the suspend state
> of path endpoints separately to their runtime state; I suspect the
> answer is yes.
> --
> 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/

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

[Matthew Garrett]

On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote:
> On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> > Perhaps you could infer that from the audio routing setup? I don't know 
> > enough about embedded codecs.
> 
> Yes, you can providing we extract a bit more information from the
> machine drivers and/or userspace - we already do our power management
> based on paths.  The implementation I'd do here is to provide a facility
> for marking some of the path endpoints as suspend insensitive then on
> suspend leave those endpoints in their current state, force the other
> endpoints off temporarily and re-run the standard power checks.

One thing that's been mentioned before is that some vendors can swap the 
kernel much more easily than they can swap userspace, with the added 
constraint that they have little control over the bootloader. So if 
there's a userspace interface, it may well also be helpful to provide a 
kernel hook to allow the platform setup code to configure things. But 
otherwise, I think that'd work for audio - the only question is whether 
we need it to be more generic.

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

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

[Matthew Garrett]

On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote:
> On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote:
> > Perhaps you could infer that from the audio routing setup? I don't know 
> > enough about embedded codecs.
> 
> Yes, you can providing we extract a bit more information from the
> machine drivers and/or userspace - we already do our power management
> based on paths.  The implementation I'd do here is to provide a facility
> for marking some of the path endpoints as suspend insensitive then on
> suspend leave those endpoints in their current state, force the other
> endpoints off temporarily and re-run the standard power checks.

One thing that's been mentioned before is that some vendors can swap the 
kernel much more easily than they can swap userspace, with the added 
constraint that they have little control over the bootloader. So if 
there's a userspace interface, it may well also be helpful to provide a 
kernel hook to allow the platform setup code to configure things. But 
otherwise, I think that'd work for audio - the only question is whether 
we need it to be more generic.

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

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> 
> > One the face of it, a runtime-PM solution would dictate that the
> > codec's driver ought to turn off the codec whenever the driver thinks
> > it isn't being used.  Ergo, if the driver didn't know when a call was
> > in progress, it would use runtime PM to turn off the codec during a
> > call.
> 
> Well, part of the problem is that right now most of our beliefs about 
> imposed constraints tend to be based on what userspace is doing - "Don't 
> power down the audio codec when userspace has it open", for instance. 
> But that goes away with opportunistic suspend. In most cases you don't 
> want the audio codec to stay awake just because userspace was using it 
> to make bouncing cow noises, especially if you've just frozen userspace. 
> So the problem becomes more complicated than it would otherwise be.

It sounds like the problem can be stated simply enough: At the moment, 
nobody knows when the codec should be powered down!  Userspace might 
have some idea, but even if its ideas are right it has no way of 
communicating them to the kernel.

The power/control sysfs attribute was intended for just that purpose,
although it was aimed at runtime PM rather than system PM.  
Nevertheless, it or something like it could be used.  Of course, there 
would still remain the issue of userspace telling the kernel not to 
power down the codec while making bouncing cow noises -- but at this 
point it's not really a kernel problem any more.

Alan Stern

P.S.: What happens if a suspend occurs while a call is in progress, so
the codec is left powered up, and then the call ends?  Does the system
wake up at that point?  Or does it stay suspended with the codec still
powered, even though it's not needed any more?

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

[Alan Stern]

On Wed, 5 May 2010, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> 
> > One the face of it, a runtime-PM solution would dictate that the
> > codec's driver ought to turn off the codec whenever the driver thinks
> > it isn't being used.  Ergo, if the driver didn't know when a call was
> > in progress, it would use runtime PM to turn off the codec during a
> > call.
> 
> Well, part of the problem is that right now most of our beliefs about 
> imposed constraints tend to be based on what userspace is doing - "Don't 
> power down the audio codec when userspace has it open", for instance. 
> But that goes away with opportunistic suspend. In most cases you don't 
> want the audio codec to stay awake just because userspace was using it 
> to make bouncing cow noises, especially if you've just frozen userspace. 
> So the problem becomes more complicated than it would otherwise be.

It sounds like the problem can be stated simply enough: At the moment, 
nobody knows when the codec should be powered down!  Userspace might 
have some idea, but even if its ideas are right it has no way of 
communicating them to the kernel.

The power/control sysfs attribute was intended for just that purpose,
although it was aimed at runtime PM rather than system PM.  
Nevertheless, it or something like it could be used.  Of course, there 
would still remain the issue of userspace telling the kernel not to 
power down the codec while making bouncing cow noises -- but at this 
point it's not really a kernel problem any more.

Alan Stern

P.S.: What happens if a suspend occurs while a call is in progress, so
the codec is left powered up, and then the call ends?  Does the system
wake up at that point?  Or does it stay suspended with the codec still
powered, even though it's not needed any more?

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 09:02:43PM +0100, Matthew Garrett wrote:

> One thing that's been mentioned before is that some vendors can swap the 
> kernel much more easily than they can swap userspace, with the added 
> constraint that they have little control over the bootloader. So if 
> there's a userspace interface, it may well also be helpful to provide a 
> kernel hook to allow the platform setup code to configure things. But 

Oh, there's definitely going to be a platform-specific hook to configure
things.  The platform needs to specify how the devices that make up the
audio subsystem are interconnected on the board, and that's done in
kernel since it depends on the hardware and can potentially lead to
physical damage if done incorrectly.

> otherwise, I think that'd work for audio - the only question is whether 
> we need it to be more generic.

Agreed.

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

[Mark Brown]

On Wed, May 05, 2010 at 09:02:43PM +0100, Matthew Garrett wrote:

> One thing that's been mentioned before is that some vendors can swap the 
> kernel much more easily than they can swap userspace, with the added 
> constraint that they have little control over the bootloader. So if 
> there's a userspace interface, it may well also be helpful to provide a 
> kernel hook to allow the platform setup code to configure things. But 

Oh, there's definitely going to be a platform-specific hook to configure
things.  The platform needs to specify how the devices that make up the
audio subsystem are interconnected on the board, and that's done in
kernel since it depends on the hardware and can potentially lead to
physical damage if done incorrectly.

> otherwise, I think that'd work for audio - the only question is whether 
> we need it to be more generic.

Agreed.

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

[Mark Brown]

On Wed, May 05, 2010 at 04:04:00PM -0400, Alan Stern wrote:

> P.S.: What happens if a suspend occurs while a call is in progress, so
> the codec is left powered up, and then the call ends?  Does the system
> wake up at that point?  Or does it stay suspended with the codec still
> powered, even though it's not needed any more?

Call end will be a system wake event in pretty much all systems,
userspace will want to do some work when the call goes away anyway.
Anyone who doesn't do that will see the CODEC stay powered, hopefully
the baseband will send it a nice mute signal instead of popping.

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

[Mark Brown]

On Wed, May 05, 2010 at 04:04:00PM -0400, Alan Stern wrote:

> P.S.: What happens if a suspend occurs while a call is in progress, so
> the codec is left powered up, and then the call ends?  Does the system
> wake up at that point?  Or does it stay suspended with the codec still
> powered, even though it's not needed any more?

Call end will be a system wake event in pretty much all systems,
userspace will want to do some work when the call goes away anyway.
Anyone who doesn't do that will see the CODEC stay powered, hopefully
the baseband will send it a nice mute signal instead of popping.

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 03:55:34PM -0400, tytso@mit.edu wrote:

> I confess I've completely lost track of (a) what problem you are
> trying to solve, and (b) how this might relate to some change that
> you'd like to see in the suspend block API.  Could you do a quick
> summary and recap?  I've gone over the entire thread, and it's still
> not clear what change you're advocating for in suspend blockers.

The issue isn't suspend blockers, it's the opportunistic suspend stuff
that goes along with them.  When that is in use the system suspends
vastly more aggressively, including in situations where a runtime PM
based approach like mainline had been adopting would not suspend since
some devices still need to be active, the classic case being keeping the
audio subsystem and baseband live when in a phone call.  This problem
did not appear to have been considered as things stood.  

I'm not really advocating a change in what's there.  What I'm looking
for is some sort of agreement as to how subsystems and drivers that need
to not act on suspend requests from the core in these situations should
do that.  If there is a generic solution it'd probably be an additional
mostly orthogonal interface rather than a change to what's being
proposed here.

What we look like we're converging on is a subsystem/driver local
solution since it doesn't look like a terribly widespread problem.
That's totally OK, it's just that as I have said I don't want to go off
and do that without the general PM community being aware of it so we
avoid anyone running into nasty surprises further down the line.

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Alan Stern wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
> 
> > On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> > 
> > > One the face of it, a runtime-PM solution would dictate that the
> > > codec's driver ought to turn off the codec whenever the driver thinks
> > > it isn't being used.  Ergo, if the driver didn't know when a call was
> > > in progress, it would use runtime PM to turn off the codec during a
> > > call.
> > 
> > Well, part of the problem is that right now most of our beliefs about 
> > imposed constraints tend to be based on what userspace is doing - "Don't 
> > power down the audio codec when userspace has it open", for instance. 
> > But that goes away with opportunistic suspend. In most cases you don't 
> > want the audio codec to stay awake just because userspace was using it 
> > to make bouncing cow noises, especially if you've just frozen userspace. 
> > So the problem becomes more complicated than it would otherwise be.
> 
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
> 
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

We'd need a separate control, I think.  The problem is, though, that the
Android user space, for example, doesn't use the sysfs attributes of devices,
so this control wouldn't be particularly useful for it.

> P.S.: What happens if a suspend occurs while a call is in progress, so
> the codec is left powered up, and then the call ends?  Does the system
> wake up at that point?  Or does it stay suspended with the codec still
> powered, even though it's not needed any more?

I guess you end up telling the user that the call ended, so the system wakes up.
That's only a guess, though.

Rafael

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Alan Stern wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
> 
> > On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> > 
> > > One the face of it, a runtime-PM solution would dictate that the
> > > codec's driver ought to turn off the codec whenever the driver thinks
> > > it isn't being used.  Ergo, if the driver didn't know when a call was
> > > in progress, it would use runtime PM to turn off the codec during a
> > > call.
> > 
> > Well, part of the problem is that right now most of our beliefs about 
> > imposed constraints tend to be based on what userspace is doing - "Don't 
> > power down the audio codec when userspace has it open", for instance. 
> > But that goes away with opportunistic suspend. In most cases you don't 
> > want the audio codec to stay awake just because userspace was using it 
> > to make bouncing cow noises, especially if you've just frozen userspace. 
> > So the problem becomes more complicated than it would otherwise be.
> 
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
> 
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

We'd need a separate control, I think.  The problem is, though, that the
Android user space, for example, doesn't use the sysfs attributes of devices,
so this control wouldn't be particularly useful for it.

> P.S.: What happens if a suspend occurs while a call is in progress, so
> the codec is left powered up, and then the call ends?  Does the system
> wake up at that point?  Or does it stay suspended with the codec still
> powered, even though it's not needed any more?

I guess you end up telling the user that the call ended, so the system wakes up.
That's only a guess, though.

Rafael

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[mark gross]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> Arve Hjønnevåg <arve@android.com> writes:
> 
> > This patch series adds a suspend-block api that provides the same
> > functionality as the android wakelock api. This version fixes a race
> > in suspend blocking work, has some documentation changes and
> > opportunistic suspend now uses the same workqueue as runtime pm.
> 
> Earlier this month, several folks intersted in embedded PM had a BoF
> as part of the Embedded Linux Conference[1] in San Francisco.  Many of
> us had concerns about wakelocks/suspend-blockers and I wanted to share
> some of mine here, since I don't know if embedded folks (other than
> Google) were included in discussions during the LF Collab summmit.
> 
> I hope other embedded folks will chime in here as well.  My background
> is in embedded as one of the kernel developers on the TI OMAP SoCs,
> and I work primarily on PM stuff.
> 
> My comments are not about this implementation of suspend blockers in
> particular, but rather on the potential implications of suspend
> blockers in general.  

I also think we need to take a hard look at the process here. 

--mgross

> Sorry for the lengthy mail, it's broken up in to 3 parts:
> 
> - suspend blockers vs. runtime PM
> - how to handle PM aware drivers?
> - what about dumb or untrusted apps
> 
> 
> Suspend blockers vs runtime PM
> ------------------------------
> 
> My primary concern is that suspend blockers attempt to address the
> same problem(s) as runtime PM, but with a very different approach.
> Suspend blockers use one very large hammer whereas runtime PM hands
> out many little hammers.  Since I believe power management to be a
> problem of many little nails, I think many little hammers are better
> suited for the job.
> 
> Currently in the kernel, we have two main forms of PM
> 
> - static PM (system PM, traditional suspend/resume etc.)
> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
> 
> And with the addition of suspend blockers we have something in
> between.  In my simple world, I think of suspend_blockers as static PM
> with a retrofit of some basic dynamic capabilities.  In my view, a
> poor man's dynamic PM.
> 
> The current design of suspend blockers was (presumably) taken due to
> major limitations and/or problems in dynamic PM when it was designed.
> However, since then, some very signifcant improvements in dynamic PM
> have come along, particularily in the form of runtime PM.  What I
> still feel is missing from this discussion are details about why the
> issues addressed by suspend blockers cannot be solved with runtime PM.
> 
> It seems to me the keypad/screen example given in the doc can very
> easily be solved with runtime PM.  The goal of that example is that
> the keypad not turn on the screen unless a specific key is pressed.
> That is rather easy to accomplish using runtime PM:
>  
> 1. system is idle, all devices/drivers runtime suspended
>    (display and keypad drivers are both runtime suspended)
> -  keypress triggers wakeup ->runtime_resume() of keypad (screen is
>    still runtime suspended)
> -  key press trickles up to userspace
> -  keypad driver is done, goes idle and is runtime supended
> -  userspace decides whether or not to turn on screen based on key
> -  if not, goto 1, (display is still runtime suspended)
> -  if so, start using display and it will be runtime resumed
> 
> I realize this keypad example was only one example usage of suspend
> blockers, but I suspect the others would be solved similarily using
> runtime PM.
> 
> But anyways, to get back to the main point: 
> 
> I feel the main problems tackled by _kernel_ suspend blockers (as I
> understand them) are the same problems already addressed by runtime
> PM.  First and formost, both have the same guiding principle:
> 
>   Rule #1: Always try for lowest power state, unless X
> 
> For runtime PM, X = "activity"
> For suspend blockers, X = a held suspend_blocker
> 
> In addition, both have the same secondary goals:
> 
> - keep device PM independent of other devices (e.g. don't wake up
>   screen just because keypad was pressed)
> 
> - wakeups/events can be handled in a device specific way, without
>   affecting other devices or rest of the system, unless desired
> 
> So, the goals are the same, but the approaches are different.  Runtime
> PM makes each of the drivers and subsystems do the work, where suspend
> blockers just forces the issue from on high.  IMHO, the more flexible
> and generic approach of runtime PM is more suited to a general purpose
> kernel than the one-big-hammer approach currently taken by suspend
> blockers.
> 
> 
> What about PM aware drivers?
> ----------------------------
> 
> All of this brings up a second major concern regarding how to write PM
> aware drivers.
> 
> At least from the kernel perspective, both suspend blockers and
> runtime PM have the same goal.  Given that, which framework should the
> driver writer target?  Both?  Seems like duplicate effort.  Using
> suspend blockers assumes the system is in opportunitstic suspend mode
> and (at least in the keypad example given) assumes a suspend-blocker
> aware userspace (Android.) Without both, targeted power savings will
> not be acheived.
> 
> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.
> 
> >From my experience with OMAP, we *really* do not want to care about
> what userspace is or isn't capable of, or what suspend-mode the kernel
> is in.  Among other things, the OMAP linux kernel is used in the Nokia
> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
> Comments on the future of each SW stack aside, we really want to run
> the same kernel and drivers across all of those platforms as well as
> whatever comes next.
> 
> 
> What about dumb or untrusted apps?
> ---------------------------------------
> 
> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace.  So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)
> 
> Again, since suspend blockers were designed, there have been major
> efforts to track and fix userspace as well as underlying timer issues
> (deferrable timers, coalescing, timer slack ...) that led to
> unnecessary wakeups from userspace.  Wouldn't it be better to spend
> our collective efforts in continuing in that direction instead of just
> hiding the underlying problems by forcing suspend?  Fixing the root
> causes will be better for everyone, not just those using Android.
> 
> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem.  I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?
> 
> Anyways, that's enough rambling for now.  I hope that sheds some light
> on the concerns I have with suspend blockers.
> 
> Kevin
> 
> [1] http://embeddedlinuxconference.com/elc_2010/index.html

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

[mark gross]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> Arve Hjønnevåg <arve@android.com> writes:
> 
> > This patch series adds a suspend-block api that provides the same
> > functionality as the android wakelock api. This version fixes a race
> > in suspend blocking work, has some documentation changes and
> > opportunistic suspend now uses the same workqueue as runtime pm.
> 
> Earlier this month, several folks intersted in embedded PM had a BoF
> as part of the Embedded Linux Conference[1] in San Francisco.  Many of
> us had concerns about wakelocks/suspend-blockers and I wanted to share
> some of mine here, since I don't know if embedded folks (other than
> Google) were included in discussions during the LF Collab summmit.
> 
> I hope other embedded folks will chime in here as well.  My background
> is in embedded as one of the kernel developers on the TI OMAP SoCs,
> and I work primarily on PM stuff.
> 
> My comments are not about this implementation of suspend blockers in
> particular, but rather on the potential implications of suspend
> blockers in general.  

I also think we need to take a hard look at the process here. 

--mgross

> Sorry for the lengthy mail, it's broken up in to 3 parts:
> 
> - suspend blockers vs. runtime PM
> - how to handle PM aware drivers?
> - what about dumb or untrusted apps
> 
> 
> Suspend blockers vs runtime PM
> ------------------------------
> 
> My primary concern is that suspend blockers attempt to address the
> same problem(s) as runtime PM, but with a very different approach.
> Suspend blockers use one very large hammer whereas runtime PM hands
> out many little hammers.  Since I believe power management to be a
> problem of many little nails, I think many little hammers are better
> suited for the job.
> 
> Currently in the kernel, we have two main forms of PM
> 
> - static PM (system PM, traditional suspend/resume etc.)
> - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.)
> 
> And with the addition of suspend blockers we have something in
> between.  In my simple world, I think of suspend_blockers as static PM
> with a retrofit of some basic dynamic capabilities.  In my view, a
> poor man's dynamic PM.
> 
> The current design of suspend blockers was (presumably) taken due to
> major limitations and/or problems in dynamic PM when it was designed.
> However, since then, some very signifcant improvements in dynamic PM
> have come along, particularily in the form of runtime PM.  What I
> still feel is missing from this discussion are details about why the
> issues addressed by suspend blockers cannot be solved with runtime PM.
> 
> It seems to me the keypad/screen example given in the doc can very
> easily be solved with runtime PM.  The goal of that example is that
> the keypad not turn on the screen unless a specific key is pressed.
> That is rather easy to accomplish using runtime PM:
>  
> 1. system is idle, all devices/drivers runtime suspended
>    (display and keypad drivers are both runtime suspended)
> -  keypress triggers wakeup ->runtime_resume() of keypad (screen is
>    still runtime suspended)
> -  key press trickles up to userspace
> -  keypad driver is done, goes idle and is runtime supended
> -  userspace decides whether or not to turn on screen based on key
> -  if not, goto 1, (display is still runtime suspended)
> -  if so, start using display and it will be runtime resumed
> 
> I realize this keypad example was only one example usage of suspend
> blockers, but I suspect the others would be solved similarily using
> runtime PM.
> 
> But anyways, to get back to the main point: 
> 
> I feel the main problems tackled by _kernel_ suspend blockers (as I
> understand them) are the same problems already addressed by runtime
> PM.  First and formost, both have the same guiding principle:
> 
>   Rule #1: Always try for lowest power state, unless X
> 
> For runtime PM, X = "activity"
> For suspend blockers, X = a held suspend_blocker
> 
> In addition, both have the same secondary goals:
> 
> - keep device PM independent of other devices (e.g. don't wake up
>   screen just because keypad was pressed)
> 
> - wakeups/events can be handled in a device specific way, without
>   affecting other devices or rest of the system, unless desired
> 
> So, the goals are the same, but the approaches are different.  Runtime
> PM makes each of the drivers and subsystems do the work, where suspend
> blockers just forces the issue from on high.  IMHO, the more flexible
> and generic approach of runtime PM is more suited to a general purpose
> kernel than the one-big-hammer approach currently taken by suspend
> blockers.
> 
> 
> What about PM aware drivers?
> ----------------------------
> 
> All of this brings up a second major concern regarding how to write PM
> aware drivers.
> 
> At least from the kernel perspective, both suspend blockers and
> runtime PM have the same goal.  Given that, which framework should the
> driver writer target?  Both?  Seems like duplicate effort.  Using
> suspend blockers assumes the system is in opportunitstic suspend mode
> and (at least in the keypad example given) assumes a suspend-blocker
> aware userspace (Android.) Without both, targeted power savings will
> not be acheived.
> 
> To me, runtime PM is a generic and flexible approach that can be used
> with any userspace.  Driver writers should not have to care whether
> the system is in "opportunistic" mode or about whether userspace is
> suspend blocker capable.  They should only have to think about when
> the device is (or should be) idle.
> 
> >From my experience with OMAP, we *really* do not want to care about
> what userspace is or isn't capable of, or what suspend-mode the kernel
> is in.  Among other things, the OMAP linux kernel is used in the Nokia
> N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).
> Comments on the future of each SW stack aside, we really want to run
> the same kernel and drivers across all of those platforms as well as
> whatever comes next.
> 
> 
> What about dumb or untrusted apps?
> ---------------------------------------
> 
> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace.  So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)
> 
> Again, since suspend blockers were designed, there have been major
> efforts to track and fix userspace as well as underlying timer issues
> (deferrable timers, coalescing, timer slack ...) that led to
> unnecessary wakeups from userspace.  Wouldn't it be better to spend
> our collective efforts in continuing in that direction instead of just
> hiding the underlying problems by forcing suspend?  Fixing the root
> causes will be better for everyone, not just those using Android.
> 
> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem.  I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?
> 
> Anyways, that's enough rambling for now.  I hope that sheds some light
> on the concerns I have with suspend blockers.
> 
> Kevin
> 
> [1] http://embeddedlinuxconference.com/elc_2010/index.html

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Wed, May 05, 2010 at 03:55:34PM -0400, tytso@mit.edu wrote:
> 
> > I confess I've completely lost track of (a) what problem you are
> > trying to solve, and (b) how this might relate to some change that
> > you'd like to see in the suspend block API.  Could you do a quick
> > summary and recap?  I've gone over the entire thread, and it's still
> > not clear what change you're advocating for in suspend blockers.
> 
> The issue isn't suspend blockers, it's the opportunistic suspend stuff
> that goes along with them.  When that is in use the system suspends
> vastly more aggressively, including in situations where a runtime PM
> based approach like mainline had been adopting would not suspend since
> some devices still need to be active, the classic case being keeping the
> audio subsystem and baseband live when in a phone call.  This problem
> did not appear to have been considered as things stood.  
> 
> I'm not really advocating a change in what's there.  What I'm looking
> for is some sort of agreement as to how subsystems and drivers that need
> to not act on suspend requests from the core in these situations should
> do that.  If there is a generic solution it'd probably be an additional
> mostly orthogonal interface rather than a change to what's being
> proposed here.
> 
> What we look like we're converging on is a subsystem/driver local
> solution since it doesn't look like a terribly widespread problem.
> That's totally OK, it's just that as I have said I don't want to go off
> and do that without the general PM community being aware of it so we
> avoid anyone running into nasty surprises further down the line.

To me, the above may be summarized that in your opinion some components of
the system will generally need to stay powered when it's suspended
opportunistically, so we need an interface to specify which components they are.
Is that correct?

Rafael

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Wed, May 05, 2010 at 03:55:34PM -0400, tytso@mit.edu wrote:
> 
> > I confess I've completely lost track of (a) what problem you are
> > trying to solve, and (b) how this might relate to some change that
> > you'd like to see in the suspend block API.  Could you do a quick
> > summary and recap?  I've gone over the entire thread, and it's still
> > not clear what change you're advocating for in suspend blockers.
> 
> The issue isn't suspend blockers, it's the opportunistic suspend stuff
> that goes along with them.  When that is in use the system suspends
> vastly more aggressively, including in situations where a runtime PM
> based approach like mainline had been adopting would not suspend since
> some devices still need to be active, the classic case being keeping the
> audio subsystem and baseband live when in a phone call.  This problem
> did not appear to have been considered as things stood.  
> 
> I'm not really advocating a change in what's there.  What I'm looking
> for is some sort of agreement as to how subsystems and drivers that need
> to not act on suspend requests from the core in these situations should
> do that.  If there is a generic solution it'd probably be an additional
> mostly orthogonal interface rather than a change to what's being
> proposed here.
> 
> What we look like we're converging on is a subsystem/driver local
> solution since it doesn't look like a terribly widespread problem.
> That's totally OK, it's just that as I have said I don't want to go off
> and do that without the general PM community being aware of it so we
> avoid anyone running into nasty surprises further down the line.

To me, the above may be summarized that in your opinion some components of
the system will generally need to stay powered when it's suspended
opportunistically, so we need an interface to specify which components they are.
Is that correct?

Rafael

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

[Brian Swetland]

On Wed, May 5, 2010 at 12:13 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> > Clearly if there's a call in progress you don't want to shut the codec
>> > down.  Are there any other circumstances?  Would they vary according to
>> > whether the suspend was forced or opportunistic?
>>
>> Yeah, ok. We probably do need to figure this out.
>>
>> (Cc:ing Rebecca to see how this got handled on Droid)
>>
>> The current state of affairs is that a system suspend request is
>> expected to put the device in as low a power state as possible given the
>> required wakeup events. Runtime power management is expected to put the
>> device in as low a power state as possible given its usage constraints.
>> If opportunistic suspend does the former then it'll tear down devices
>> that may be in use, but we don't have any real way to indicate usage
>> constraints other than the phone app taking a wakelock - and that means
>> leaving userspace running during calls, which seems excessive.
>>
>> Mark's right in that the only case I can think of that's really relevant
>> right now is the audio hardware, so the inelegant solution is that this
>> is something that could be provided at the audio level. Is this
>> something we want a generic solution for? If so, what should it look
>> like?
>
> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?
>
> Or only during opportunistic suspends while a call is in progress?
>
> Does it know when a call is in progress?

>From my point of view, the codec should be powered up while audio is
playing and powered down when it's not -- that's the approach I've
taken on MSM, regardless of suspend state.  I don't view suspend as
something that stops audio playback in progress.  Sort of similar to
how the modem doesn't power off down when the system is in suspend,
etc.

In effect, we have followed a sort of runtime pm model of
clocking/powering peripherals at the lowest possible level at all
times, which is why I've never viewed suspend_block as somehow
competing with runtime pm -- we always want all drivers/peripherals in
the lowers power state.  Sometimes the lowest power state possible is
higher than "full suspend" (for example when we can't meet latency
requirements on audio on 7201A) and suspend_blockers cover that case.

Brian

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

[Brian Swetland]

On Wed, May 5, 2010 at 12:13 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> > Clearly if there's a call in progress you don't want to shut the codec
>> > down.  Are there any other circumstances?  Would they vary according to
>> > whether the suspend was forced or opportunistic?
>>
>> Yeah, ok. We probably do need to figure this out.
>>
>> (Cc:ing Rebecca to see how this got handled on Droid)
>>
>> The current state of affairs is that a system suspend request is
>> expected to put the device in as low a power state as possible given the
>> required wakeup events. Runtime power management is expected to put the
>> device in as low a power state as possible given its usage constraints.
>> If opportunistic suspend does the former then it'll tear down devices
>> that may be in use, but we don't have any real way to indicate usage
>> constraints other than the phone app taking a wakelock - and that means
>> leaving userspace running during calls, which seems excessive.
>>
>> Mark's right in that the only case I can think of that's really relevant
>> right now is the audio hardware, so the inelegant solution is that this
>> is something that could be provided at the audio level. Is this
>> something we want a generic solution for? If so, what should it look
>> like?
>
> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?
>
> Or only during opportunistic suspends while a call is in progress?
>
> Does it know when a call is in progress?

From my point of view, the codec should be powered up while audio is
playing and powered down when it's not -- that's the approach I've
taken on MSM, regardless of suspend state.  I don't view suspend as
something that stops audio playback in progress.  Sort of similar to
how the modem doesn't power off down when the system is in suspend,
etc.

In effect, we have followed a sort of runtime pm model of
clocking/powering peripherals at the lowest possible level at all
times, which is why I've never viewed suspend_block as somehow
competing with runtime pm -- we always want all drivers/peripherals in
the lowers power state.  Sometimes the lowest power state possible is
higher than "full suspend" (for example when we can't meet latency
requirements on audio on 7201A) and suspend_blockers cover that case.

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

Re: [linux-pm] [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.

[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: [linux-pm] [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

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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:

> To me, the above may be summarized that in your opinion some components of
> the system will generally need to stay powered when it's suspended
> opportunistically, so we need an interface to specify which components they are.
> Is that correct?

Yes, though I think I'd be inclined to treat the problem orthogonally to
opportunistic suspend to allow more flexibility in use and since
treating it as part of opportunistic suspend would imply that there's
some meaningful difference between the end result of that and a manual
suspend which AIUI there isn't.

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

[Mark Brown]

On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:

> To me, the above may be summarized that in your opinion some components of
> the system will generally need to stay powered when it's suspended
> opportunistically, so we need an interface to specify which components they are.
> Is that correct?

Yes, though I think I'd be inclined to treat the problem orthogonally to
opportunistic suspend to allow more flexibility in use and since
treating it as part of opportunistic suspend would imply that there's
some meaningful difference between the end result of that and a manual
suspend which AIUI there isn't.

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

[Brian Swetland]

On Wed, May 5, 2010 at 2:57 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:
>
>> To me, the above may be summarized that in your opinion some components of
>> the system will generally need to stay powered when it's suspended
>> opportunistically, so we need an interface to specify which components they are.
>> Is that correct?
>
> Yes, though I think I'd be inclined to treat the problem orthogonally to
> opportunistic suspend to allow more flexibility in use and since
> treating it as part of opportunistic suspend would imply that there's
> some meaningful difference between the end result of that and a manual
> suspend which AIUI there isn't.

I'd agree with this.  This is one of the reasons I haven't felt
opportunistic suspend is a big departure from other work here -- there
are always some cases in which drivers will need to keep external
resources active even when suspended.  Also, as I mentioned earlier,
we (Android at least, but hopefully this is non-controversial) would
always like drivers to put everything in the lowest possible power
state they can get away with.  Every little savings adds up.

Brian

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

[Brian Swetland]

On Wed, May 5, 2010 at 2:57 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:
>
>> To me, the above may be summarized that in your opinion some components of
>> the system will generally need to stay powered when it's suspended
>> opportunistically, so we need an interface to specify which components they are.
>> Is that correct?
>
> Yes, though I think I'd be inclined to treat the problem orthogonally to
> opportunistic suspend to allow more flexibility in use and since
> treating it as part of opportunistic suspend would imply that there's
> some meaningful difference between the end result of that and a manual
> suspend which AIUI there isn't.

I'd agree with this.  This is one of the reasons I haven't felt
opportunistic suspend is a big departure from other work here -- there
are always some cases in which drivers will need to keep external
resources active even when suspended.  Also, as I mentioned earlier,
we (Android at least, but hopefully this is non-controversial) would
always like drivers to put everything in the lowest possible power
state they can get away with.  Every little savings adds up.

Brian

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:
> 
> > To me, the above may be summarized that in your opinion some components of
> > the system will generally need to stay powered when it's suspended
> > opportunistically, so we need an interface to specify which components they are.
> > Is that correct?
> 
> Yes, though I think I'd be inclined to treat the problem orthogonally to
> opportunistic suspend to allow more flexibility in use and since
> treating it as part of opportunistic suspend would imply that there's
> some meaningful difference between the end result of that and a manual
> suspend which AIUI there isn't.

No, there's no such difference.

So, gnerenally, we may need a mechanism to specify which components of the
system need to stay powered while the whole system is suspended (in addition to
wakeup devices, that is).

That certainly I can agree with.

I'm not sure, however, in what way this is relevant to the $subject patchset.

Rafael

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

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote:
> 
> > To me, the above may be summarized that in your opinion some components of
> > the system will generally need to stay powered when it's suspended
> > opportunistically, so we need an interface to specify which components they are.
> > Is that correct?
> 
> Yes, though I think I'd be inclined to treat the problem orthogonally to
> opportunistic suspend to allow more flexibility in use and since
> treating it as part of opportunistic suspend would imply that there's
> some meaningful difference between the end result of that and a manual
> suspend which AIUI there isn't.

No, there's no such difference.

So, gnerenally, we may need a mechanism to specify which components of the
system need to stay powered while the whole system is suspended (in addition to
wakeup devices, that is).

That certainly I can agree with.

I'm not sure, however, in what way this is relevant to the $subject patchset.

Rafael

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
>> 
>> > One the face of it, a runtime-PM solution would dictate that the
>> > codec's driver ought to turn off the codec whenever the driver thinks
>> > it isn't being used.  Ergo, if the driver didn't know when a call was
>> > in progress, it would use runtime PM to turn off the codec during a
>> > call.
>> 
>> Well, part of the problem is that right now most of our beliefs about 
>> imposed constraints tend to be based on what userspace is doing - "Don't 
>> power down the audio codec when userspace has it open", for instance. 
>> But that goes away with opportunistic suspend. In most cases you don't 
>> want the audio codec to stay awake just because userspace was using it 
>> to make bouncing cow noises, especially if you've just frozen userspace. 
>> So the problem becomes more complicated than it would otherwise be.
>
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
>
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

I guess what we're talking about here is a set of per-device
constraints that could be used by both [opportunistic|system] suspend
and runtime PM.  For lack of a better term, per-device PM QoS (as
compared to the current system-wide PM QoS.)

For example, if userspace (or some other device) has communicated that
it has a constraint on the audio HW, then both the suspend path and the
runtime PM path could check those constraints before making a decision
on how to act.  Hopefully the phone app would set a constraint and the
cow-noise app would not.  :)

On OMAP, we keep track of per-device constraints (currently latency
and throughput) in order to make proper run-time PM decicions in the
kernel, but we are realizing that we need a way for userspace to
communicate these constraints as well, so that userspace can make
power vs. performance policy decisions instead of the kernel.

Probably generalizing these into the LDM is the direction to go so
userspace can set constraints on a per-device (or per-class?) basis:

/sys/devices/.../power/constraint/throughput
/sys/devices/.../power/constraint/wakeup_latency
/sys/devices/.../power/constraint/... ?

Kevin

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
>> 
>> > One the face of it, a runtime-PM solution would dictate that the
>> > codec's driver ought to turn off the codec whenever the driver thinks
>> > it isn't being used.  Ergo, if the driver didn't know when a call was
>> > in progress, it would use runtime PM to turn off the codec during a
>> > call.
>> 
>> Well, part of the problem is that right now most of our beliefs about 
>> imposed constraints tend to be based on what userspace is doing - "Don't 
>> power down the audio codec when userspace has it open", for instance. 
>> But that goes away with opportunistic suspend. In most cases you don't 
>> want the audio codec to stay awake just because userspace was using it 
>> to make bouncing cow noises, especially if you've just frozen userspace. 
>> So the problem becomes more complicated than it would otherwise be.
>
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
>
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

I guess what we're talking about here is a set of per-device
constraints that could be used by both [opportunistic|system] suspend
and runtime PM.  For lack of a better term, per-device PM QoS (as
compared to the current system-wide PM QoS.)

For example, if userspace (or some other device) has communicated that
it has a constraint on the audio HW, then both the suspend path and the
runtime PM path could check those constraints before making a decision
on how to act.  Hopefully the phone app would set a constraint and the
cow-noise app would not.  :)

On OMAP, we keep track of per-device constraints (currently latency
and throughput) in order to make proper run-time PM decicions in the
kernel, but we are realizing that we need a way for userspace to
communicate these constraints as well, so that userspace can make
power vs. performance policy decisions instead of the kernel.

Probably generalizing these into the LDM is the direction to go so
userspace can set constraints on a per-device (or per-class?) basis:

/sys/devices/.../power/constraint/throughput
/sys/devices/.../power/constraint/wakeup_latency
/sys/devices/.../power/constraint/... ?

Kevin

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

[Mark Brown]

On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote:

> So, gnerenally, we may need a mechanism to specify which components of the
> system need to stay powered while the whole system is suspended (in addition to
> wakeup devices, that is).

> That certainly I can agree with.

> I'm not sure, however, in what way this is relevant to the $subject patchset.

The patch set essentially makes using a full system suspend as the
lowest power state for runtime PM part of the standard Linux power
management toolkit which means that it's no longer clear as it used to
be that suspend is an instruction to cease all activity and go into a
minimal power state if the device is not a wake source.  In the primary
existing application this change interoperates very poorly with at least
the current audio subsystem since that handles suspend by ceasing all
activity and powering as much as it can off, which is sensible for
manual only suspends but highly undesirable for opportunistic suspend in
phones.  We should therefore have some idea how this and any other
affected areas are supposed to work.

As I said in my reply to Ted earlier I think we may actually be
converging on not worrying too much about it at the global level and
doing subsystem specific things to discover and handle affected cases,
at least for the time being.  Ideally we'd have something standard to
hook into but no subsystems apart from audio have actually been
identified as being affected so it's not clear to me that a general
solution is going to be worth the effort, if there's no actual users it
may just confuse people by adding yet more power managment stuff to
learn.

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

[Mark Brown]

On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote:

> So, gnerenally, we may need a mechanism to specify which components of the
> system need to stay powered while the whole system is suspended (in addition to
> wakeup devices, that is).

> That certainly I can agree with.

> I'm not sure, however, in what way this is relevant to the $subject patchset.

The patch set essentially makes using a full system suspend as the
lowest power state for runtime PM part of the standard Linux power
management toolkit which means that it's no longer clear as it used to
be that suspend is an instruction to cease all activity and go into a
minimal power state if the device is not a wake source.  In the primary
existing application this change interoperates very poorly with at least
the current audio subsystem since that handles suspend by ceasing all
activity and powering as much as it can off, which is sensible for
manual only suspends but highly undesirable for opportunistic suspend in
phones.  We should therefore have some idea how this and any other
affected areas are supposed to work.

As I said in my reply to Ted earlier I think we may actually be
converging on not worrying too much about it at the global level and
doing subsystem specific things to discover and handle affected cases,
at least for the time being.  Ideally we'd have something standard to
hook into but no subsystems apart from audio have actually been
identified as being affected so it's not clear to me that a general
solution is going to be worth the effort, if there's no actual users it
may just confuse people by adding yet more power managment stuff to
learn.

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Kevin Hilman wrote:
> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> > On Wed, 5 May 2010, Matthew Garrett wrote:
> >
> >> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> >> 
> >> > One the face of it, a runtime-PM solution would dictate that the
> >> > codec's driver ought to turn off the codec whenever the driver thinks
> >> > it isn't being used.  Ergo, if the driver didn't know when a call was
> >> > in progress, it would use runtime PM to turn off the codec during a
> >> > call.
> >> 
> >> Well, part of the problem is that right now most of our beliefs about 
> >> imposed constraints tend to be based on what userspace is doing - "Don't 
> >> power down the audio codec when userspace has it open", for instance. 
> >> But that goes away with opportunistic suspend. In most cases you don't 
> >> want the audio codec to stay awake just because userspace was using it 
> >> to make bouncing cow noises, especially if you've just frozen userspace. 
> >> So the problem becomes more complicated than it would otherwise be.
> >
> > It sounds like the problem can be stated simply enough: At the moment, 
> > nobody knows when the codec should be powered down!  Userspace might 
> > have some idea, but even if its ideas are right it has no way of 
> > communicating them to the kernel.
> >
> > The power/control sysfs attribute was intended for just that purpose,
> > although it was aimed at runtime PM rather than system PM.  
> > Nevertheless, it or something like it could be used.  Of course, there 
> > would still remain the issue of userspace telling the kernel not to 
> > power down the codec while making bouncing cow noises -- but at this 
> > point it's not really a kernel problem any more.
> 
> I guess what we're talking about here is a set of per-device
> constraints that could be used by both [opportunistic|system] suspend
> and runtime PM.  For lack of a better term, per-device PM QoS (as
> compared to the current system-wide PM QoS.)
> 
> For example, if userspace (or some other device) has communicated that
> it has a constraint on the audio HW, then both the suspend path and the
> runtime PM path could check those constraints before making a decision
> on how to act.  Hopefully the phone app would set a constraint and the
> cow-noise app would not.  :)
> 
> On OMAP, we keep track of per-device constraints (currently latency
> and throughput) in order to make proper run-time PM decicions in the
> kernel, but we are realizing that we need a way for userspace to
> communicate these constraints as well, so that userspace can make
> power vs. performance policy decisions instead of the kernel.
> 
> Probably generalizing these into the LDM is the direction to go so
> userspace can set constraints on a per-device (or per-class?) basis:
> 
> /sys/devices/.../power/constraint/throughput
> /sys/devices/.../power/constraint/wakeup_latency
> /sys/devices/.../power/constraint/... ?

That sounds reasonable although it may be a challenge to find a set of
universal constraints common to all devices.

Rafael

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Kevin Hilman wrote:
> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> > On Wed, 5 May 2010, Matthew Garrett wrote:
> >
> >> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> >> 
> >> > One the face of it, a runtime-PM solution would dictate that the
> >> > codec's driver ought to turn off the codec whenever the driver thinks
> >> > it isn't being used.  Ergo, if the driver didn't know when a call was
> >> > in progress, it would use runtime PM to turn off the codec during a
> >> > call.
> >> 
> >> Well, part of the problem is that right now most of our beliefs about 
> >> imposed constraints tend to be based on what userspace is doing - "Don't 
> >> power down the audio codec when userspace has it open", for instance. 
> >> But that goes away with opportunistic suspend. In most cases you don't 
> >> want the audio codec to stay awake just because userspace was using it 
> >> to make bouncing cow noises, especially if you've just frozen userspace. 
> >> So the problem becomes more complicated than it would otherwise be.
> >
> > It sounds like the problem can be stated simply enough: At the moment, 
> > nobody knows when the codec should be powered down!  Userspace might 
> > have some idea, but even if its ideas are right it has no way of 
> > communicating them to the kernel.
> >
> > The power/control sysfs attribute was intended for just that purpose,
> > although it was aimed at runtime PM rather than system PM.  
> > Nevertheless, it or something like it could be used.  Of course, there 
> > would still remain the issue of userspace telling the kernel not to 
> > power down the codec while making bouncing cow noises -- but at this 
> > point it's not really a kernel problem any more.
> 
> I guess what we're talking about here is a set of per-device
> constraints that could be used by both [opportunistic|system] suspend
> and runtime PM.  For lack of a better term, per-device PM QoS (as
> compared to the current system-wide PM QoS.)
> 
> For example, if userspace (or some other device) has communicated that
> it has a constraint on the audio HW, then both the suspend path and the
> runtime PM path could check those constraints before making a decision
> on how to act.  Hopefully the phone app would set a constraint and the
> cow-noise app would not.  :)
> 
> On OMAP, we keep track of per-device constraints (currently latency
> and throughput) in order to make proper run-time PM decicions in the
> kernel, but we are realizing that we need a way for userspace to
> communicate these constraints as well, so that userspace can make
> power vs. performance policy decisions instead of the kernel.
> 
> Probably generalizing these into the LDM is the direction to go so
> userspace can set constraints on a per-device (or per-class?) basis:
> 
> /sys/devices/.../power/constraint/throughput
> /sys/devices/.../power/constraint/wakeup_latency
> /sys/devices/.../power/constraint/... ?

That sounds reasonable although it may be a challenge to find a set of
universal constraints common to all devices.

Rafael

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote:
> 
> > So, gnerenally, we may need a mechanism to specify which components of the
> > system need to stay powered while the whole system is suspended (in addition to
> > wakeup devices, that is).
> 
> > That certainly I can agree with.
> 
> > I'm not sure, however, in what way this is relevant to the $subject patchset.
> 
> The patch set essentially makes using a full system suspend as the
> lowest power state for runtime PM part of the standard Linux power
> management toolkit which means that it's no longer clear as it used to
> be that suspend is an instruction to cease all activity and go into a
> minimal power state if the device is not a wake source.

I don't see why, really.  This patchset doesn't change the meaning of suspend
at all, it only changes the way in which suspend is triggered (if specifically
set up that way).  Even without the patchset you may implement a power
manager in user space that will suspend the system whenever it thinks it's
idle.

> In the primary existing application this change interoperates very poorly
> with at least the current audio subsystem since that handles suspend by
> ceasing all activity and powering as much as it can off, which is sensible for
> manual only suspends but highly undesirable for opportunistic suspend in
> phones.

You said that there's no fundamental difference between manual and
opportunistic suspend.  It only matters what _you_ are going to use suspend
for.  I agree that at the moment it's not suitable for aggressive power
management in phones because of the audio problem, but that applies to
"manual" as well as to "opportunistic" suspend.

You're saying that suspend is not suitable for one particular purpose in its
current form, which is entirely correct, but that doesn't imply that the
patchset is wrong.

Rafael

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote:
> 
> > So, gnerenally, we may need a mechanism to specify which components of the
> > system need to stay powered while the whole system is suspended (in addition to
> > wakeup devices, that is).
> 
> > That certainly I can agree with.
> 
> > I'm not sure, however, in what way this is relevant to the $subject patchset.
> 
> The patch set essentially makes using a full system suspend as the
> lowest power state for runtime PM part of the standard Linux power
> management toolkit which means that it's no longer clear as it used to
> be that suspend is an instruction to cease all activity and go into a
> minimal power state if the device is not a wake source.

I don't see why, really.  This patchset doesn't change the meaning of suspend
at all, it only changes the way in which suspend is triggered (if specifically
set up that way).  Even without the patchset you may implement a power
manager in user space that will suspend the system whenever it thinks it's
idle.

> In the primary existing application this change interoperates very poorly
> with at least the current audio subsystem since that handles suspend by
> ceasing all activity and powering as much as it can off, which is sensible for
> manual only suspends but highly undesirable for opportunistic suspend in
> phones.

You said that there's no fundamental difference between manual and
opportunistic suspend.  It only matters what _you_ are going to use suspend
for.  I agree that at the moment it's not suitable for aggressive power
management in phones because of the audio problem, but that applies to
"manual" as well as to "opportunistic" suspend.

You're saying that suspend is not suitable for one particular purpose in its
current form, which is entirely correct, but that doesn't imply that the
patchset is wrong.

Rafael

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

[Mark Brown]

On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote:

> From my point of view, the codec should be powered up while audio is
> playing and powered down when it's not -- that's the approach I've

This is what we've got already with Linux - we've had rather aggressive
runtime PM for embedded audio as standard for years now.  It's only very
recently that mobile hardware has got to the point where you can
actually totally kill the power without introducing problems but it's
been getting pretty much as close as possible.

> taken on MSM, regardless of suspend state.  I don't view suspend as
> something that stops audio playback in progress.  Sort of similar to
> how the modem doesn't power off down when the system is in suspend,
> etc.

This really does depend heavily on system design and the intended
function of the suspend on the part of the initiator.  In many systems
suspend will remove sufficient power to stop audio running even if it
were desired, and there's the idea with existing manually initiated
suspends that the system should stop what it's doing and go into a low
power, low responsiveness state.  Some systems will initiate a suspend
with active audio paths (especially those to or from the AP) which they
expect to be stopped.

> In effect, we have followed a sort of runtime pm model of
> clocking/powering peripherals at the lowest possible level at all
> times, which is why I've never viewed suspend_block as somehow
> competing with runtime pm -- we always want all drivers/peripherals in

Right, and this will work well on systems like your current devices
because the problem hardware is not directly visible to the AP (the
actual audio hardware is hidden behind the DSP which functions as
autonomously as the modem does) so it's not affected by the Linux
suspend process in the first place.  It causes confusion when the power
for the audio device is managed by Linux since the opportunistic suspend
will include suspending the audio device and so the code handling the
suspend then has to decide what exactly it's being asked to do.

> the lowers power state.  Sometimes the lowest power state possible is
> higher than "full suspend" (for example when we can't meet latency
> requirements on audio on 7201A) and suspend_blockers cover that case.

In this situation there's no physical reason why the lower power state
is not achievable so blocking the suspend would just waste power, it's
just that our way of getting into it is creating some confusion.

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

[Mark Brown]

On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote:

> From my point of view, the codec should be powered up while audio is
> playing and powered down when it's not -- that's the approach I've

This is what we've got already with Linux - we've had rather aggressive
runtime PM for embedded audio as standard for years now.  It's only very
recently that mobile hardware has got to the point where you can
actually totally kill the power without introducing problems but it's
been getting pretty much as close as possible.

> taken on MSM, regardless of suspend state.  I don't view suspend as
> something that stops audio playback in progress.  Sort of similar to
> how the modem doesn't power off down when the system is in suspend,
> etc.

This really does depend heavily on system design and the intended
function of the suspend on the part of the initiator.  In many systems
suspend will remove sufficient power to stop audio running even if it
were desired, and there's the idea with existing manually initiated
suspends that the system should stop what it's doing and go into a low
power, low responsiveness state.  Some systems will initiate a suspend
with active audio paths (especially those to or from the AP) which they
expect to be stopped.

> In effect, we have followed a sort of runtime pm model of
> clocking/powering peripherals at the lowest possible level at all
> times, which is why I've never viewed suspend_block as somehow
> competing with runtime pm -- we always want all drivers/peripherals in

Right, and this will work well on systems like your current devices
because the problem hardware is not directly visible to the AP (the
actual audio hardware is hidden behind the DSP which functions as
autonomously as the modem does) so it's not affected by the Linux
suspend process in the first place.  It causes confusion when the power
for the audio device is managed by Linux since the opportunistic suspend
will include suspending the audio device and so the code handling the
suspend then has to decide what exactly it's being asked to do.

> the lowers power state.  Sometimes the lowest power state possible is
> higher than "full suspend" (for example when we can't meet latency
> requirements on audio on 7201A) and suspend_blockers cover that case.

In this situation there's no physical reason why the lower power state
is not achievable so blocking the suspend would just waste power, it's
just that our way of getting into it is creating some confusion.

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

[Brian Swetland]

On Wed, May 5, 2010 at 4:03 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> I guess what we're talking about here is a set of per-device
> constraints that could be used by both [opportunistic|system] suspend
> and runtime PM.  For lack of a better term, per-device PM QoS (as
> compared to the current system-wide PM QoS.)
>
> For example, if userspace (or some other device) has communicated that
> it has a constraint on the audio HW, then both the suspend path and the
> runtime PM path could check those constraints before making a decision
> on how to act.  Hopefully the phone app would set a constraint and the
> cow-noise app would not.  :)
>
> On OMAP, we keep track of per-device constraints (currently latency
> and throughput) in order to make proper run-time PM decicions in the
> kernel, but we are realizing that we need a way for userspace to
> communicate these constraints as well, so that userspace can make
> power vs. performance policy decisions instead of the kernel.
>
> Probably generalizing these into the LDM is the direction to go so
> userspace can set constraints on a per-device (or per-class?) basis:
>
> /sys/devices/.../power/constraint/throughput
> /sys/devices/.../power/constraint/wakeup_latency
> /sys/devices/.../power/constraint/... ?

The constraint stuff is definitely something I'd love to talk about in
detail.  It's a problem that I think is common to every SoC I've
worked with.  Having a general solution for this problem (of
specifying and observing various constraints for clock, power, qos,
etc) kernel-wide would seem like a big win.

Might be worth kicking some design ideas around and getting a bunch of
the interested parties together at some of the upcoming linux
conference things this fall on the east coast?

Brian

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

[Brian Swetland]

On Wed, May 5, 2010 at 4:03 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> I guess what we're talking about here is a set of per-device
> constraints that could be used by both [opportunistic|system] suspend
> and runtime PM.  For lack of a better term, per-device PM QoS (as
> compared to the current system-wide PM QoS.)
>
> For example, if userspace (or some other device) has communicated that
> it has a constraint on the audio HW, then both the suspend path and the
> runtime PM path could check those constraints before making a decision
> on how to act.  Hopefully the phone app would set a constraint and the
> cow-noise app would not.  :)
>
> On OMAP, we keep track of per-device constraints (currently latency
> and throughput) in order to make proper run-time PM decicions in the
> kernel, but we are realizing that we need a way for userspace to
> communicate these constraints as well, so that userspace can make
> power vs. performance policy decisions instead of the kernel.
>
> Probably generalizing these into the LDM is the direction to go so
> userspace can set constraints on a per-device (or per-class?) basis:
>
> /sys/devices/.../power/constraint/throughput
> /sys/devices/.../power/constraint/wakeup_latency
> /sys/devices/.../power/constraint/... ?

The constraint stuff is definitely something I'd love to talk about in
detail.  It's a problem that I think is common to every SoC I've
worked with.  Having a general solution for this problem (of
specifying and observing various constraints for clock, power, qos,
etc) kernel-wide would seem like a big win.

Might be worth kicking some design ideas around and getting a bunch of
the interested parties together at some of the upcoming linux
conference things this fall on the east coast?

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

Re: [linux-pm] [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

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: [linux-pm] [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

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: [linux-pm] [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

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 0/8] Suspend block api (version 6)

[Mark Brown]

On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote:

> set up that way).  Even without the patchset you may implement a power
> manager in user space that will suspend the system whenever it thinks it's
> idle.

Clearly, but...

> On Thursday 06 May 2010, Mark Brown wrote:

> > In the primary existing application this change interoperates very poorly
> > with at least the current audio subsystem since that handles suspend by
> > ceasing all activity and powering as much as it can off, which is sensible for
> > manual only suspends but highly undesirable for opportunistic suspend in
> > phones.

> You said that there's no fundamental difference between manual and
> opportunistic suspend.  It only matters what _you_ are going to use suspend
> for.  I agree that at the moment it's not suitable for aggressive power
> management in phones because of the audio problem, but that applies to
> "manual" as well as to "opportunistic" suspend.

...on the other hand there's exactly one existing application for this,
and that's the one that's most likely to run into problems since it's a
phone OS and aggressive power management is pretty important for phones.

Merging a feature into mainline makes it much more something which one
would expect to play nicely with the rest of the kernel - if it's
something that isn't part of the standard kernel or userspaces it's much
less surprising that additional changes may be required to produce a
well integrated system.

> You're saying that suspend is not suitable for one particular purpose in its
> current form, which is entirely correct, but that doesn't imply that the
> patchset is wrong.

As I keep saying I agree that merging this is reasonable given the
additional power savings it brings in practical systems today.  As I
also keep saying I do want to have some understanding about what the
story is for dealing with the problems so that people can easily use
this feature out of the box.

Like I say, my current impression is that the best approach is for
affected subsystems or drivers to implement a custom solution - does
that match your understanding and that of the other PM maintainers?

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

[Mark Brown]

On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote:

> set up that way).  Even without the patchset you may implement a power
> manager in user space that will suspend the system whenever it thinks it's
> idle.

Clearly, but...

> On Thursday 06 May 2010, Mark Brown wrote:

> > In the primary existing application this change interoperates very poorly
> > with at least the current audio subsystem since that handles suspend by
> > ceasing all activity and powering as much as it can off, which is sensible for
> > manual only suspends but highly undesirable for opportunistic suspend in
> > phones.

> You said that there's no fundamental difference between manual and
> opportunistic suspend.  It only matters what _you_ are going to use suspend
> for.  I agree that at the moment it's not suitable for aggressive power
> management in phones because of the audio problem, but that applies to
> "manual" as well as to "opportunistic" suspend.

...on the other hand there's exactly one existing application for this,
and that's the one that's most likely to run into problems since it's a
phone OS and aggressive power management is pretty important for phones.

Merging a feature into mainline makes it much more something which one
would expect to play nicely with the rest of the kernel - if it's
something that isn't part of the standard kernel or userspaces it's much
less surprising that additional changes may be required to produce a
well integrated system.

> You're saying that suspend is not suitable for one particular purpose in its
> current form, which is entirely correct, but that doesn't imply that the
> patchset is wrong.

As I keep saying I agree that merging this is reasonable given the
additional power savings it brings in practical systems today.  As I
also keep saying I do want to have some understanding about what the
story is for dealing with the problems so that people can easily use
this feature out of the box.

Like I say, my current impression is that the best approach is for
affected subsystems or drivers to implement a custom solution - does
that match your understanding and that of the other PM maintainers?

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote:
> 
> > set up that way).  Even without the patchset you may implement a power
> > manager in user space that will suspend the system whenever it thinks it's
> > idle.
> 
> Clearly, but...
> 
> > On Thursday 06 May 2010, Mark Brown wrote:
> 
> > > In the primary existing application this change interoperates very poorly
> > > with at least the current audio subsystem since that handles suspend by
> > > ceasing all activity and powering as much as it can off, which is sensible for
> > > manual only suspends but highly undesirable for opportunistic suspend in
> > > phones.
> 
> > You said that there's no fundamental difference between manual and
> > opportunistic suspend.  It only matters what _you_ are going to use suspend
> > for.  I agree that at the moment it's not suitable for aggressive power
> > management in phones because of the audio problem, but that applies to
> > "manual" as well as to "opportunistic" suspend.
> 
> ...on the other hand there's exactly one existing application for this,
> and that's the one that's most likely to run into problems since it's a
> phone OS and aggressive power management is pretty important for phones.
> 
> Merging a feature into mainline makes it much more something which one
> would expect to play nicely with the rest of the kernel - if it's
> something that isn't part of the standard kernel or userspaces it's much
> less surprising that additional changes may be required to produce a
> well integrated system.
> 
> > You're saying that suspend is not suitable for one particular purpose in its
> > current form, which is entirely correct, but that doesn't imply that the
> > patchset is wrong.
> 
> As I keep saying I agree that merging this is reasonable given the
> additional power savings it brings in practical systems today.  As I
> also keep saying I do want to have some understanding about what the
> story is for dealing with the problems so that people can easily use
> this feature out of the box.
> 
> Like I say, my current impression is that the best approach is for
> affected subsystems or drivers to implement a custom solution - does
> that match your understanding and that of the other PM maintainers?

I agree that this appears to be the best approach for the time being, although
I can only speak for myself.

Rafael

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote:
> 
> > set up that way).  Even without the patchset you may implement a power
> > manager in user space that will suspend the system whenever it thinks it's
> > idle.
> 
> Clearly, but...
> 
> > On Thursday 06 May 2010, Mark Brown wrote:
> 
> > > In the primary existing application this change interoperates very poorly
> > > with at least the current audio subsystem since that handles suspend by
> > > ceasing all activity and powering as much as it can off, which is sensible for
> > > manual only suspends but highly undesirable for opportunistic suspend in
> > > phones.
> 
> > You said that there's no fundamental difference between manual and
> > opportunistic suspend.  It only matters what _you_ are going to use suspend
> > for.  I agree that at the moment it's not suitable for aggressive power
> > management in phones because of the audio problem, but that applies to
> > "manual" as well as to "opportunistic" suspend.
> 
> ...on the other hand there's exactly one existing application for this,
> and that's the one that's most likely to run into problems since it's a
> phone OS and aggressive power management is pretty important for phones.
> 
> Merging a feature into mainline makes it much more something which one
> would expect to play nicely with the rest of the kernel - if it's
> something that isn't part of the standard kernel or userspaces it's much
> less surprising that additional changes may be required to produce a
> well integrated system.
> 
> > You're saying that suspend is not suitable for one particular purpose in its
> > current form, which is entirely correct, but that doesn't imply that the
> > patchset is wrong.
> 
> As I keep saying I agree that merging this is reasonable given the
> additional power savings it brings in practical systems today.  As I
> also keep saying I do want to have some understanding about what the
> story is for dealing with the problems so that people can easily use
> this feature out of the box.
> 
> Like I say, my current impression is that the best approach is for
> affected subsystems or drivers to implement a custom solution - does
> that match your understanding and that of the other PM maintainers?

I agree that this appears to be the best approach for the time being, although
I can only speak for myself.

Rafael

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

[Magnus Damm]

On Wed, May 5, 2010 at 12:27 AM, Matthew Garrett <mjg@redhat.com> wrote:
> On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:
>
>> Another thing that Kevin is missing: There is more to the system than
>> the devices and the CPU.  For example: RAM, an embedded controller (on
>> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
>> for the CPU and the devices won't power-down these things, but system
>> PM will.
>
> Somewhat true - machines with C1E support will put the RAM into self
> refresh when the cpu is idle, but you're right that there are various
> components that we simply don't have control over in the desktop world
> at present.

As a contrast, at least on some embedded SoCs without firmware
limitations the low level sleep code for Runtime PM / CPU Idle is
shared with system wide suspend. So the RAM is put into self refresh
regardless of entering a half-deep CPU Idle state or entering
suspend-to-memory.

I've heard that newer SH-Mobile ARM hardware monitors the memory bus
activity behind the scenes and can put the system RAM into self
refresh automatically. On older parts we had to manage that from CPU
idle context.

/ magnus

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

[Magnus Damm]

On Wed, May 5, 2010 at 12:27 AM, Matthew Garrett <mjg@redhat.com> wrote:
> On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote:
>
>> Another thing that Kevin is missing: There is more to the system than
>> the devices and the CPU.  For example: RAM, an embedded controller (on
>> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
>> for the CPU and the devices won't power-down these things, but system
>> PM will.
>
> Somewhat true - machines with C1E support will put the RAM into self
> refresh when the cpu is idle, but you're right that there are various
> components that we simply don't have control over in the desktop world
> at present.

As a contrast, at least on some embedded SoCs without firmware
limitations the low level sleep code for Runtime PM / CPU Idle is
shared with system wide suspend. So the RAM is put into self refresh
regardless of entering a half-deep CPU Idle state or entering
suspend-to-memory.

I've heard that newer SH-Mobile ARM hardware monitors the memory bus
activity behind the scenes and can put the system RAM into self
refresh automatically. On older parts we had to manage that from CPU
idle context.

/ magnus

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

On Wed, May 5, 2010 at 4:40 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote:
...
>> taken on MSM, regardless of suspend state.  I don't view suspend as
>> something that stops audio playback in progress.  Sort of similar to
>> how the modem doesn't power off down when the system is in suspend,
>> etc.
>
> This really does depend heavily on system design and the intended
> function of the suspend on the part of the initiator.  In many systems
> suspend will remove sufficient power to stop audio running even if it
> were desired, and there's the idea with existing manually initiated
> suspends that the system should stop what it's doing and go into a low
> power, low responsiveness state.  Some systems will initiate a suspend
> with active audio paths (especially those to or from the AP) which they
> expect to be stopped.
>

You can support both in the same driver in some cases (without a
switch). If the hardware cannot wake the system when it needs more
audio buffers, then the driver needs to block suspend while audio is
playing. Since suspend blockers only block opportunistic suspend, the
driver can also implement suspend to stop audio playback and it will
only be called for forced suspend.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Wed, May 5, 2010 at 4:40 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote:
...
>> taken on MSM, regardless of suspend state.  I don't view suspend as
>> something that stops audio playback in progress.  Sort of similar to
>> how the modem doesn't power off down when the system is in suspend,
>> etc.
>
> This really does depend heavily on system design and the intended
> function of the suspend on the part of the initiator.  In many systems
> suspend will remove sufficient power to stop audio running even if it
> were desired, and there's the idea with existing manually initiated
> suspends that the system should stop what it's doing and go into a low
> power, low responsiveness state.  Some systems will initiate a suspend
> with active audio paths (especially those to or from the AP) which they
> expect to be stopped.
>

You can support both in the same driver in some cases (without a
switch). If the hardware cannot wake the system when it needs more
audio buffers, then the driver needs to block suspend while audio is
playing. Since suspend blockers only block opportunistic suspend, the
driver can also implement suspend to stop audio playback and it will
only be called for forced suspend.

-- 
Arve Hjønnevåg

Re: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Alan Stern]

On Wed, 5 May 2010, Brian Swetland wrote:

> > Probably generalizing these into the LDM is the direction to go so
> > userspace can set constraints on a per-device (or per-class?) basis:
> >
> > /sys/devices/.../power/constraint/throughput
> > /sys/devices/.../power/constraint/wakeup_latency
> > /sys/devices/.../power/constraint/... ?
> 
> The constraint stuff is definitely something I'd love to talk about in
> detail.  It's a problem that I think is common to every SoC I've
> worked with.  Having a general solution for this problem (of
> specifying and observing various constraints for clock, power, qos,
> etc) kernel-wide would seem like a big win.
> 
> Might be worth kicking some design ideas around and getting a bunch of
> the interested parties together at some of the upcoming linux
> conference things this fall on the east coast?

The Linux Power-Management Summit is scheduled for August 9, at the 
start of the LinuxCon meeting in Boston.  This would make an excellent 
topic for discussion.

Alan Stern

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

[Alan Stern]

On Wed, 5 May 2010, Brian Swetland wrote:

> > Probably generalizing these into the LDM is the direction to go so
> > userspace can set constraints on a per-device (or per-class?) basis:
> >
> > /sys/devices/.../power/constraint/throughput
> > /sys/devices/.../power/constraint/wakeup_latency
> > /sys/devices/.../power/constraint/... ?
> 
> The constraint stuff is definitely something I'd love to talk about in
> detail.  It's a problem that I think is common to every SoC I've
> worked with.  Having a general solution for this problem (of
> specifying and observing various constraints for clock, power, qos,
> etc) kernel-wide would seem like a big win.
> 
> Might be worth kicking some design ideas around and getting a bunch of
> the interested parties together at some of the upcoming linux
> conference things this fall on the east coast?

The Linux Power-Management Summit is scheduled for August 9, at the 
start of the LinuxCon meeting in Boston.  This would make an excellent 
topic for discussion.

Alan Stern

Re: [linux-pm] [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.

[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: [linux-pm] [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

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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 06 May 2010, Alan Stern wrote:
> On Wed, 5 May 2010, Brian Swetland wrote:
> 
> > > Probably generalizing these into the LDM is the direction to go so
> > > userspace can set constraints on a per-device (or per-class?) basis:
> > >
> > > /sys/devices/.../power/constraint/throughput
> > > /sys/devices/.../power/constraint/wakeup_latency
> > > /sys/devices/.../power/constraint/... ?
> > 
> > The constraint stuff is definitely something I'd love to talk about in
> > detail.  It's a problem that I think is common to every SoC I've
> > worked with.  Having a general solution for this problem (of
> > specifying and observing various constraints for clock, power, qos,
> > etc) kernel-wide would seem like a big win.
> > 
> > Might be worth kicking some design ideas around and getting a bunch of
> > the interested parties together at some of the upcoming linux
> > conference things this fall on the east coast?
> 
> The Linux Power-Management Summit is scheduled for August 9, at the 
> start of the LinuxCon meeting in Boston.  This would make an excellent 
> topic for discussion.

Agreed.

Rafael

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

[Rafael J. Wysocki]

On Thursday 06 May 2010, Alan Stern wrote:
> On Wed, 5 May 2010, Brian Swetland wrote:
> 
> > > Probably generalizing these into the LDM is the direction to go so
> > > userspace can set constraints on a per-device (or per-class?) basis:
> > >
> > > /sys/devices/.../power/constraint/throughput
> > > /sys/devices/.../power/constraint/wakeup_latency
> > > /sys/devices/.../power/constraint/... ?
> > 
> > The constraint stuff is definitely something I'd love to talk about in
> > detail.  It's a problem that I think is common to every SoC I've
> > worked with.  Having a general solution for this problem (of
> > specifying and observing various constraints for clock, power, qos,
> > etc) kernel-wide would seem like a big win.
> > 
> > Might be worth kicking some design ideas around and getting a bunch of
> > the interested parties together at some of the upcoming linux
> > conference things this fall on the east coast?
> 
> The Linux Power-Management Summit is scheduled for August 9, at the 
> start of the LinuxCon meeting in Boston.  This would make an excellent 
> topic for discussion.

Agreed.

Rafael

Re: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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 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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote:
> On Wed, May 5, 2010 at 4:40 PM, Mark Brown

> > This really does depend heavily on system design and the intended
> > function of the suspend on the part of the initiator.  In many systems
> > suspend will remove sufficient power to stop audio running even if it
> > were desired, and there's the idea with existing manually initiated
> > suspends that the system should stop what it's doing and go into a low
> > power, low responsiveness state.  Some systems will initiate a suspend
> > with active audio paths (especially those to or from the AP) which they
> > expect to be stopped.

> You can support both in the same driver in some cases (without a
> switch). If the hardware cannot wake the system when it needs more
> audio buffers, then the driver needs to block suspend while audio is
> playing. Since suspend blockers only block opportunistic suspend, the
> driver can also implement suspend to stop audio playback and it will
> only be called for forced suspend.

As discussed elsewhere in the thread a suspend blocker is not desirable
here - the AP is not doing anything useful on a voice call so blocking
the suspend will just waste power unless runtime PM is good enough to
mean opportunistic suspend isn't adding anything anyway.  It will avoid
the immediate issue with loosing audio but it's not really what we want
to happen.

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

[Mark Brown]

On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote:
> On Wed, May 5, 2010 at 4:40 PM, Mark Brown

> > This really does depend heavily on system design and the intended
> > function of the suspend on the part of the initiator.  In many systems
> > suspend will remove sufficient power to stop audio running even if it
> > were desired, and there's the idea with existing manually initiated
> > suspends that the system should stop what it's doing and go into a low
> > power, low responsiveness state.  Some systems will initiate a suspend
> > with active audio paths (especially those to or from the AP) which they
> > expect to be stopped.

> You can support both in the same driver in some cases (without a
> switch). If the hardware cannot wake the system when it needs more
> audio buffers, then the driver needs to block suspend while audio is
> playing. Since suspend blockers only block opportunistic suspend, the
> driver can also implement suspend to stop audio playback and it will
> only be called for forced suspend.

As discussed elsewhere in the thread a suspend blocker is not desirable
here - the AP is not doing anything useful on a voice call so blocking
the suspend will just waste power unless runtime PM is good enough to
mean opportunistic suspend isn't adding anything anyway.  It will avoid
the immediate issue with loosing audio but it's not really what we want
to happen.

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

[Arve Hjønnevåg]

2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote:
>> On Wed, May 5, 2010 at 4:40 PM, Mark Brown
>
>> > This really does depend heavily on system design and the intended
>> > function of the suspend on the part of the initiator.  In many systems
>> > suspend will remove sufficient power to stop audio running even if it
>> > were desired, and there's the idea with existing manually initiated
>> > suspends that the system should stop what it's doing and go into a low
>> > power, low responsiveness state.  Some systems will initiate a suspend
>> > with active audio paths (especially those to or from the AP) which they
>> > expect to be stopped.
>
>> You can support both in the same driver in some cases (without a
>> switch). If the hardware cannot wake the system when it needs more
>> audio buffers, then the driver needs to block suspend while audio is
>> playing. Since suspend blockers only block opportunistic suspend, the
>> driver can also implement suspend to stop audio playback and it will
>> only be called for forced suspend.
>
> As discussed elsewhere in the thread a suspend blocker is not desirable
> here - the AP is not doing anything useful on a voice call so blocking
> the suspend will just waste power unless runtime PM is good enough to
> mean opportunistic suspend isn't adding anything anyway.  It will avoid
> the immediate issue with loosing audio but it's not really what we want
> to happen.
>

I was talking about audio from the AP. Why would you ever turn off
another core's audio path on suspend?

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote:
>> On Wed, May 5, 2010 at 4:40 PM, Mark Brown
>
>> > This really does depend heavily on system design and the intended
>> > function of the suspend on the part of the initiator.  In many systems
>> > suspend will remove sufficient power to stop audio running even if it
>> > were desired, and there's the idea with existing manually initiated
>> > suspends that the system should stop what it's doing and go into a low
>> > power, low responsiveness state.  Some systems will initiate a suspend
>> > with active audio paths (especially those to or from the AP) which they
>> > expect to be stopped.
>
>> You can support both in the same driver in some cases (without a
>> switch). If the hardware cannot wake the system when it needs more
>> audio buffers, then the driver needs to block suspend while audio is
>> playing. Since suspend blockers only block opportunistic suspend, the
>> driver can also implement suspend to stop audio playback and it will
>> only be called for forced suspend.
>
> As discussed elsewhere in the thread a suspend blocker is not desirable
> here - the AP is not doing anything useful on a voice call so blocking
> the suspend will just waste power unless runtime PM is good enough to
> mean opportunistic suspend isn't adding anything anyway.  It will avoid
> the immediate issue with loosing audio but it's not really what we want
> to happen.
>

I was talking about audio from the AP. Why would you ever turn off
another core's audio path on suspend?

-- 
Arve Hjønnevåg

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

[Mark Brown]

On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > As discussed elsewhere in the thread a suspend blocker is not desirable
> > here - the AP is not doing anything useful on a voice call so blocking
> > the suspend will just waste power unless runtime PM is good enough to
> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
> > the immediate issue with loosing audio but it's not really what we want
> > to happen.

> I was talking about audio from the AP. Why would you ever turn off
> another core's audio path on suspend?

This goes back to the thing about a full system suspend being a
sledgehammer which doesn't give enough information about what's going
on when it's used like this.  As discussed we need a way to know that
the connections involved are able to stay live during suspend (on a
large proportion of systems suspend is going to mean that the relevant
bits of the board will loose power so need to be shut down) and that
that the intention of the user is that they should do so (this isn't
clear in the general system, especially not if the suspend is initiated
manually).  

With a runtime PM approach this is trivial - we just turn off anything
that isn't in use at the current time.  I'll need to extend ASoC to add
information about what to do on suspend to the existing power data.

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

[Mark Brown]

On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > As discussed elsewhere in the thread a suspend blocker is not desirable
> > here - the AP is not doing anything useful on a voice call so blocking
> > the suspend will just waste power unless runtime PM is good enough to
> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
> > the immediate issue with loosing audio but it's not really what we want
> > to happen.

> I was talking about audio from the AP. Why would you ever turn off
> another core's audio path on suspend?

This goes back to the thing about a full system suspend being a
sledgehammer which doesn't give enough information about what's going
on when it's used like this.  As discussed we need a way to know that
the connections involved are able to stay live during suspend (on a
large proportion of systems suspend is going to mean that the relevant
bits of the board will loose power so need to be shut down) and that
that the intention of the user is that they should do so (this isn't
clear in the general system, especially not if the suspend is initiated
manually).  

With a runtime PM approach this is trivial - we just turn off anything
that isn't in use at the current time.  I'll need to extend ASoC to add
information about what to do on suspend to the existing power data.

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

[Theodore Tso]

On May 7, 2010, at 7:21 AM, Mark Brown wrote:
> 
> This goes back to the thing about a full system suspend being a
> sledgehammer which doesn't give enough information about what's going
> on when it's used like this.  As discussed we need a way to know that
> the connections involved are able to stay live during suspend (on a
> large proportion of systems suspend is going to mean that the relevant
> bits of the board will loose power so need to be shut down) and that
> that the intention of the user is that they should do so (this isn't
> clear in the general system, especially not if the suspend is initiated
> manually).  

This sounds like it may be something unique to your board/product.  Or am I missing something?

One of the challenges with PM in the embedded world is that everybody seems to have slightly different assumptions, and hardware that doesn't behave the same way.

More than once this discussion has wandered off into the weeds wrt to whether this patch series is ready to be merged, since there are so many drivers blocked on it....

-- Ted

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

[Theodore Tso]

On May 7, 2010, at 7:21 AM, Mark Brown wrote:
> 
> This goes back to the thing about a full system suspend being a
> sledgehammer which doesn't give enough information about what's going
> on when it's used like this.  As discussed we need a way to know that
> the connections involved are able to stay live during suspend (on a
> large proportion of systems suspend is going to mean that the relevant
> bits of the board will loose power so need to be shut down) and that
> that the intention of the user is that they should do so (this isn't
> clear in the general system, especially not if the suspend is initiated
> manually).  

This sounds like it may be something unique to your board/product.  Or am I missing something?

One of the challenges with PM in the embedded world is that everybody seems to have slightly different assumptions, and hardware that doesn't behave the same way.

More than once this discussion has wandered off into the weeds wrt to whether this patch series is ready to be merged, since there are so many drivers blocked on it....

-- Ted

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

[Arve Hjønnevåg]

2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
>> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>
>> > As discussed elsewhere in the thread a suspend blocker is not desirable
>> > here - the AP is not doing anything useful on a voice call so blocking
>> > the suspend will just waste power unless runtime PM is good enough to
>> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
>> > the immediate issue with loosing audio but it's not really what we want
>> > to happen.
>
>> I was talking about audio from the AP. Why would you ever turn off
>> another core's audio path on suspend?
>
> This goes back to the thing about a full system suspend being a
> sledgehammer which doesn't give enough information about what's going
> on when it's used like this.  As discussed we need a way to know that
> the connections involved are able to stay live during suspend (on a
> large proportion of systems suspend is going to mean that the relevant
> bits of the board will loose power so need to be shut down) and that

Are you trying to use the same driver on systems that can support
audio while suspend and on systems where this is impossible? If audio
cannot work while suspended, supporting opportunistic suspend is easy.
You block suspend while audio is active.

If the hardware does support some audio paths while suspended, I'll
ask again, is there a reason to turn them off on suspend?

> that the intention of the user is that they should do so (this isn't
> clear in the general system, especially not if the suspend is initiated
> manually).
>
> With a runtime PM approach this is trivial - we just turn off anything
> that isn't in use at the current time.  I'll need to extend ASoC to add
> information about what to do on suspend to the existing power data.
>
OK, but is this at all related to opportunistic suspend?

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
>> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>
>> > As discussed elsewhere in the thread a suspend blocker is not desirable
>> > here - the AP is not doing anything useful on a voice call so blocking
>> > the suspend will just waste power unless runtime PM is good enough to
>> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
>> > the immediate issue with loosing audio but it's not really what we want
>> > to happen.
>
>> I was talking about audio from the AP. Why would you ever turn off
>> another core's audio path on suspend?
>
> This goes back to the thing about a full system suspend being a
> sledgehammer which doesn't give enough information about what's going
> on when it's used like this.  As discussed we need a way to know that
> the connections involved are able to stay live during suspend (on a
> large proportion of systems suspend is going to mean that the relevant
> bits of the board will loose power so need to be shut down) and that

Are you trying to use the same driver on systems that can support
audio while suspend and on systems where this is impossible? If audio
cannot work while suspended, supporting opportunistic suspend is easy.
You block suspend while audio is active.

If the hardware does support some audio paths while suspended, I'll
ask again, is there a reason to turn them off on suspend?

> that the intention of the user is that they should do so (this isn't
> clear in the general system, especially not if the suspend is initiated
> manually).
>
> With a runtime PM approach this is trivial - we just turn off anything
> that isn't in use at the current time.  I'll need to extend ASoC to add
> information about what to do on suspend to the existing power data.
>
OK, but is this at all related to opportunistic suspend?

-- 
Arve Hjønnevåg

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

[Mark Brown]

On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote:

> This sounds like it may be something unique to your board/product.  Or
> am I missing something?

I suspect you're missing something here - I'm approaching this as one of
the maintainers of the embedded audio subsystem for the kernel.  I need
to worry about any system running Linux which has an embedded style
audio subsystem.  The problem might be unique to audio, but I can't say
that for certain.

> One of the challenges with PM in the embedded world is that everybody
> seems to have slightly different assumptions, and hardware that doesn't
> behave the same way.

This isn't really a problem for audio - we've already got a subsystem
which copes well with pretty much all systems and does runtime PM that's
equivalent to suspending already, which is half the problem here.  If we
had less generalisation this would probably not have come up.

> More than once this discussion has wandered off into the weeds wrt to
> whether this patch series is ready to be merged, since there are so many
> drivers blocked on it....

Once more, my main objective here has been to make sure that when this
is merged we've got a joined up story about how people think this hangs
together, which I think we have now.  As I say now that we have that
understanding I don't see any reason to block merge.

It's unfortunate that I only noticed that this was actually wakelocks
very late in the day but I think I can get an implementation which
handles paths that ignore suspends done quickly.

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

[Mark Brown]

On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote:

> This sounds like it may be something unique to your board/product.  Or
> am I missing something?

I suspect you're missing something here - I'm approaching this as one of
the maintainers of the embedded audio subsystem for the kernel.  I need
to worry about any system running Linux which has an embedded style
audio subsystem.  The problem might be unique to audio, but I can't say
that for certain.

> One of the challenges with PM in the embedded world is that everybody
> seems to have slightly different assumptions, and hardware that doesn't
> behave the same way.

This isn't really a problem for audio - we've already got a subsystem
which copes well with pretty much all systems and does runtime PM that's
equivalent to suspending already, which is half the problem here.  If we
had less generalisation this would probably not have come up.

> More than once this discussion has wandered off into the weeds wrt to
> whether this patch series is ready to be merged, since there are so many
> drivers blocked on it....

Once more, my main objective here has been to make sure that when this
is merged we've got a joined up story about how people think this hangs
together, which I think we have now.  As I say now that we have that
understanding I don't see any reason to block merge.

It's unfortunate that I only noticed that this was actually wakelocks
very late in the day but I think I can get an implementation which
handles paths that ignore suspends done quickly.

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

[Brian Swetland]

On Fri, May 7, 2010 at 5:25 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote:
>
>> This sounds like it may be something unique to your board/product.  Or
>> am I missing something?
>
> I suspect you're missing something here - I'm approaching this as one of
> the maintainers of the embedded audio subsystem for the kernel.  I need
> to worry about any system running Linux which has an embedded style
> audio subsystem.  The problem might be unique to audio, but I can't say
> that for certain.
>
>> One of the challenges with PM in the embedded world is that everybody
>> seems to have slightly different assumptions, and hardware that doesn't
>> behave the same way.
>
> This isn't really a problem for audio - we've already got a subsystem
> which copes well with pretty much all systems and does runtime PM that's
> equivalent to suspending already, which is half the problem here.  If we
> had less generalisation this would probably not have come up.
>
>> More than once this discussion has wandered off into the weeds wrt to
>> whether this patch series is ready to be merged, since there are so many
>> drivers blocked on it....
>
> Once more, my main objective here has been to make sure that when this
> is merged we've got a joined up story about how people think this hangs
> together, which I think we have now.  As I say now that we have that
> understanding I don't see any reason to block merge.
>
> It's unfortunate that I only noticed that this was actually wakelocks
> very late in the day but I think I can get an implementation which
> handles paths that ignore suspends done quickly.

Do you mean an implementation of embedded linux audio or an
implementation of suspend blockers "which handles paths that ignore
suspends"?  I assume you mean the former, but maybe I misunderstand.

We've done a lot of work around multicore SoCs where the baseband
generally owns a lot of the audio routing and so on, but we do as
general policy not disable audio, codecs, and amps while playback or
record is underway.  I suppose for environments more like a pc laptop
where the expectation is the world stops when you close the lid a
different policy would be preferable.

We typically fire up codecs and amps when playback starts (if they
were off), and usually set a timer for a couple seconds after playback
stops to spin them down (since you tend to have to delay while they're
powering up to avoid pops, etc, and if the system just played a short
sound there's a reasonable chance it'll follow that with another).

Apologies about the name confusion -- last year when we first started
pushing these patches out there was much dislike for the name wakelock
and after a lot of back and forth suspend_block ended up as the least
hated of the suggested alternatives (I kinda like "wakelock" as a
name, but maybe that's just brain rot after dealing with 'em for four
years now).

Brian

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

[Brian Swetland]

On Fri, May 7, 2010 at 5:25 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote:
>
>> This sounds like it may be something unique to your board/product.  Or
>> am I missing something?
>
> I suspect you're missing something here - I'm approaching this as one of
> the maintainers of the embedded audio subsystem for the kernel.  I need
> to worry about any system running Linux which has an embedded style
> audio subsystem.  The problem might be unique to audio, but I can't say
> that for certain.
>
>> One of the challenges with PM in the embedded world is that everybody
>> seems to have slightly different assumptions, and hardware that doesn't
>> behave the same way.
>
> This isn't really a problem for audio - we've already got a subsystem
> which copes well with pretty much all systems and does runtime PM that's
> equivalent to suspending already, which is half the problem here.  If we
> had less generalisation this would probably not have come up.
>
>> More than once this discussion has wandered off into the weeds wrt to
>> whether this patch series is ready to be merged, since there are so many
>> drivers blocked on it....
>
> Once more, my main objective here has been to make sure that when this
> is merged we've got a joined up story about how people think this hangs
> together, which I think we have now.  As I say now that we have that
> understanding I don't see any reason to block merge.
>
> It's unfortunate that I only noticed that this was actually wakelocks
> very late in the day but I think I can get an implementation which
> handles paths that ignore suspends done quickly.

Do you mean an implementation of embedded linux audio or an
implementation of suspend blockers "which handles paths that ignore
suspends"?  I assume you mean the former, but maybe I misunderstand.

We've done a lot of work around multicore SoCs where the baseband
generally owns a lot of the audio routing and so on, but we do as
general policy not disable audio, codecs, and amps while playback or
record is underway.  I suppose for environments more like a pc laptop
where the expectation is the world stops when you close the lid a
different policy would be preferable.

We typically fire up codecs and amps when playback starts (if they
were off), and usually set a timer for a couple seconds after playback
stops to spin them down (since you tend to have to delay while they're
powering up to avoid pops, etc, and if the system just played a short
sound there's a reasonable chance it'll follow that with another).

Apologies about the name confusion -- last year when we first started
pushing these patches out there was much dislike for the name wakelock
and after a lot of back and forth suspend_block ended up as the least
hated of the suggested alternatives (I kinda like "wakelock" as a
name, but maybe that's just brain rot after dealing with 'em for four
years now).

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

[Mark Brown]

On Fri, May 07, 2010 at 05:37:21AM -0700, Brian Swetland wrote:
> On Fri, May 7, 2010 at 5:25 AM, Mark Brown

> > It's unfortunate that I only noticed that this was actually wakelocks
> > very late in the day but I think I can get an implementation which
> > handles paths that ignore suspends done quickly.

> Do you mean an implementation of embedded linux audio or an
> implementation of suspend blockers "which handles paths that ignore
> suspends"?  I assume you mean the former, but maybe I misunderstand.

I mean that I will extend the embedded audio subsystem that the kernel
already has (ASoC, in sound/soc) to support ignoring suspends for some
audio paths so that they can be kept up during suspend.  This will be
primarily intended for use with opportunistic suspend but not specific
to it.

I have no intention of touching suspend blockers, except in that some of
the drivers I'm responsible for should probably use suspend blockers for
similar reasons to the other users you're merging but that's less urgent.

> We've done a lot of work around multicore SoCs where the baseband
> generally owns a lot of the audio routing and so on,

Multicore isn't really the term here - obviously on something like the
OMAP4 or the current nVidia devices you've got a multicore AP but may or
may not have an integrated baseband.  The distinction is down to how
much visibility the AP has of the audio hardware, which is in general
orthogonal to how the silicon is split and packaged.

>                                                      but we do as
> general policy not disable audio, codecs, and amps while playback or
> record is underway.

Yeah, I know.  I have been keeping an eye on the Android stuff, though
none of the audio side has been mainlined yet.

>                      I suppose for environments more like a pc laptop
> where the expectation is the world stops when you close the lid a
> different policy would be preferable.

Yes, quite.  It all depends on what the intention of the user is when
they do a suspend.  Clearly if the suspend was initiated automatically
because the system is apparently idle the intention is different to if
it was initiated because the user performed some explicit action.

> We typically fire up codecs and amps when playback starts (if they
> were off), and usually set a timer for a couple seconds after playback
> stops to spin them down (since you tend to have to delay while they're
> powering up to avoid pops, etc, and if the system just played a short
> sound there's a reasonable chance it'll follow that with another).

This is exactly what ASoC does - the two biggest wins it offers are that
it allows reuse of the code specific to a given piece of silicon on all
boards using that silicon and that it provides automatic runtime power
management in the core by keeping track of which audio paths are live.

There is the slight wrinkle that you don't really want to *fully* power
down devices that don't have ground referenced outputs since they take
a relatively long time to bring their reference level up without audible
artifacts in the output.

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

[Mark Brown]

On Fri, May 07, 2010 at 05:37:21AM -0700, Brian Swetland wrote:
> On Fri, May 7, 2010 at 5:25 AM, Mark Brown

> > It's unfortunate that I only noticed that this was actually wakelocks
> > very late in the day but I think I can get an implementation which
> > handles paths that ignore suspends done quickly.

> Do you mean an implementation of embedded linux audio or an
> implementation of suspend blockers "which handles paths that ignore
> suspends"?  I assume you mean the former, but maybe I misunderstand.

I mean that I will extend the embedded audio subsystem that the kernel
already has (ASoC, in sound/soc) to support ignoring suspends for some
audio paths so that they can be kept up during suspend.  This will be
primarily intended for use with opportunistic suspend but not specific
to it.

I have no intention of touching suspend blockers, except in that some of
the drivers I'm responsible for should probably use suspend blockers for
similar reasons to the other users you're merging but that's less urgent.

> We've done a lot of work around multicore SoCs where the baseband
> generally owns a lot of the audio routing and so on,

Multicore isn't really the term here - obviously on something like the
OMAP4 or the current nVidia devices you've got a multicore AP but may or
may not have an integrated baseband.  The distinction is down to how
much visibility the AP has of the audio hardware, which is in general
orthogonal to how the silicon is split and packaged.

>                                                      but we do as
> general policy not disable audio, codecs, and amps while playback or
> record is underway.

Yeah, I know.  I have been keeping an eye on the Android stuff, though
none of the audio side has been mainlined yet.

>                      I suppose for environments more like a pc laptop
> where the expectation is the world stops when you close the lid a
> different policy would be preferable.

Yes, quite.  It all depends on what the intention of the user is when
they do a suspend.  Clearly if the suspend was initiated automatically
because the system is apparently idle the intention is different to if
it was initiated because the user performed some explicit action.

> We typically fire up codecs and amps when playback starts (if they
> were off), and usually set a timer for a couple seconds after playback
> stops to spin them down (since you tend to have to delay while they're
> powering up to avoid pops, etc, and if the system just played a short
> sound there's a reasonable chance it'll follow that with another).

This is exactly what ASoC does - the two biggest wins it offers are that
it allows reuse of the code specific to a given piece of silicon on all
boards using that silicon and that it provides automatic runtime power
management in the core by keeping track of which audio paths are live.

There is the slight wrinkle that you don't really want to *fully* power
down devices that don't have ground referenced outputs since they take
a relatively long time to bring their reference level up without audible
artifacts in the output.

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

[Mark Brown]

On Fri, May 07, 2010 at 04:41:02AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > This goes back to the thing about a full system suspend being a
> > sledgehammer which doesn't give enough information about what's going
> > on when it's used like this.  As discussed we need a way to know that
> > the connections involved are able to stay live during suspend (on a
> > large proportion of systems suspend is going to mean that the relevant
> > bits of the board will loose power so need to be shut down) and that

> Are you trying to use the same driver on systems that can support
> audio while suspend and on systems where this is impossible? If audio

Yes, each chip in the audio subsystem gets its own device driver.  All
Linux systems using a given CODEC share the device specific driver code
(modulo out of tree code, obviously).  Further, the power management is
mostly abstracted out of the individual device drivers into the embedded
audio core so the individual drivers don't really take any decisions
about power for themselves.

> cannot work while suspended, supporting opportunistic suspend is easy.
> You block suspend while audio is active.

Right, but that's not really an interesting case here.

> If the hardware does support some audio paths while suspended, I'll
> ask again, is there a reason to turn them off on suspend?

As the mail you're replying to says:

> > that the intention of the user is that they should do so (this isn't
> > clear in the general system, especially not if the suspend is initiated
> > manually).

this all comes down to the intention of the user when they initiated the
suspend.

> > With a runtime PM approach this is trivial - we just turn off anything
> > that isn't in use at the current time.  I'll need to extend ASoC to add
> > information about what to do on suspend to the existing power data.

> OK, but is this at all related to opportunistic suspend?

Well, opportunistic suspend is essentially blurring the lines between a
suspend and runtime PM - it's using suspend as part of the automatic
drive down into the lowest possible power state.  I'm just saying that
in a pure runtime PM model this issue doesn't come up since the suspend
semantic is much clearer.

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

[Mark Brown]

On Fri, May 07, 2010 at 04:41:02AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > This goes back to the thing about a full system suspend being a
> > sledgehammer which doesn't give enough information about what's going
> > on when it's used like this.  As discussed we need a way to know that
> > the connections involved are able to stay live during suspend (on a
> > large proportion of systems suspend is going to mean that the relevant
> > bits of the board will loose power so need to be shut down) and that

> Are you trying to use the same driver on systems that can support
> audio while suspend and on systems where this is impossible? If audio

Yes, each chip in the audio subsystem gets its own device driver.  All
Linux systems using a given CODEC share the device specific driver code
(modulo out of tree code, obviously).  Further, the power management is
mostly abstracted out of the individual device drivers into the embedded
audio core so the individual drivers don't really take any decisions
about power for themselves.

> cannot work while suspended, supporting opportunistic suspend is easy.
> You block suspend while audio is active.

Right, but that's not really an interesting case here.

> If the hardware does support some audio paths while suspended, I'll
> ask again, is there a reason to turn them off on suspend?

As the mail you're replying to says:

> > that the intention of the user is that they should do so (this isn't
> > clear in the general system, especially not if the suspend is initiated
> > manually).

this all comes down to the intention of the user when they initiated the
suspend.

> > With a runtime PM approach this is trivial - we just turn off anything
> > that isn't in use at the current time.  I'll need to extend ASoC to add
> > information about what to do on suspend to the existing power data.

> OK, but is this at all related to opportunistic suspend?

Well, opportunistic suspend is essentially blurring the lines between a
suspend and runtime PM - it's using suspend as part of the automatic
drive down into the lowest possible power state.  I'm just saying that
in a pure runtime PM model this issue doesn't come up since the suspend
semantic is much clearer.

Re: [linux-pm] [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

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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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: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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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

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: [linux-pm] [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.

[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: [linux-pm] [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.

[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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Kevin Hilman]

Hello,

I think many folks are still confused about exactly the problem being
solved by this series as well as mixed up between opportunistic
suspend and suspend blockers.  Also, how this series impatcs the rest
of the kernel (especially PM-aware drivers and subsystems) has caused
a bit of confusion.

To help with the confusion, I think a much clearer description of the
problem being solved and the proposed solution is needed.  

To that end, I created a starting point for that below which
summarizes how I understand the problem and the proposed solution, but
of course this should be filled out in more detail and updated as part
of the documentation that goes with this series.

Hope this helps improve the understanding of this feature,

Kevin



Table of Contents
=================
1 Problem Statement 
2 Solution: Opportunistic suspend 
    2.1 When to use a suspend blocker 
    2.2 Usage in PM aware drivers 


1 Problem Statement 
~~~~~~~~~~~~~~~~~~~~

Want to to hit deep power state, even when the system is not actually
idle.

Why?

- some hardware is not capable of deep power states in idle
- difficulty getting userspace and/or kernel to be idle

2 Solution: Opportunistic suspend 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Create an additional "idle path" which has new rules for determining
idleness.  When this new "idle" is reached, trigger full-system
suspend.  Since a suspend is triggered whenever the opportunity
arises, this is called opportunistic suspend.

The new rules for making the idleness decision are simple:

1.  system may suspend if and only if no suspend blockers are held

2.1 When to use a suspend blocker 
==================================

[A list of reasons why suspend blockers might be used would be very
 helpful here.] 

- ensure wakeup events propagate to userspace (e.g. keypad example in doc)

- screen is on

- someone mentioned "Google use cases"
  (would be nice to hear about more of these)

2.2 Usage in PM aware drivers 
==============================

[An example of how a driver already using runtime PM would use 
 a suspend blocker would also be helpful.

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

[Kevin Hilman]

Hello,

I think many folks are still confused about exactly the problem being
solved by this series as well as mixed up between opportunistic
suspend and suspend blockers.  Also, how this series impatcs the rest
of the kernel (especially PM-aware drivers and subsystems) has caused
a bit of confusion.

To help with the confusion, I think a much clearer description of the
problem being solved and the proposed solution is needed.  

To that end, I created a starting point for that below which
summarizes how I understand the problem and the proposed solution, but
of course this should be filled out in more detail and updated as part
of the documentation that goes with this series.

Hope this helps improve the understanding of this feature,

Kevin



Table of Contents
=================
1 Problem Statement 
2 Solution: Opportunistic suspend 
    2.1 When to use a suspend blocker 
    2.2 Usage in PM aware drivers 


1 Problem Statement 
~~~~~~~~~~~~~~~~~~~~

Want to to hit deep power state, even when the system is not actually
idle.

Why?

- some hardware is not capable of deep power states in idle
- difficulty getting userspace and/or kernel to be idle

2 Solution: Opportunistic suspend 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Create an additional "idle path" which has new rules for determining
idleness.  When this new "idle" is reached, trigger full-system
suspend.  Since a suspend is triggered whenever the opportunity
arises, this is called opportunistic suspend.

The new rules for making the idleness decision are simple:

1.  system may suspend if and only if no suspend blockers are held

2.1 When to use a suspend blocker 
==================================

[A list of reasons why suspend blockers might be used would be very
 helpful here.] 

- ensure wakeup events propagate to userspace (e.g. keypad example in doc)

- screen is on

- someone mentioned "Google use cases"
  (would be nice to hear about more of these)

2.2 Usage in PM aware drivers 
==============================

[An example of how a driver already using runtime PM would use 
 a suspend blocker would also be helpful.

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

[Rafael J. Wysocki]

On Monday 10 May 2010, Kevin Hilman wrote:
> Hello,

Hi Kevin,

> I think many folks are still confused about exactly the problem being
> solved by this series as well as mixed up between opportunistic
> suspend and suspend blockers.  Also, how this series impatcs the rest
> of the kernel (especially PM-aware drivers and subsystems) has caused
> a bit of confusion.
> 
> To help with the confusion, I think a much clearer description of the
> problem being solved and the proposed solution is needed.  
> 
> To that end, I created a starting point for that below which
> summarizes how I understand the problem and the proposed solution, but
> of course this should be filled out in more detail and updated as part
> of the documentation that goes with this series.
> 
> Hope this helps improve the understanding of this feature,

Yes, I think this is helpful.

> Table of Contents
> =================
> 1 Problem Statement 
> 2 Solution: Opportunistic suspend 
>     2.1 When to use a suspend blocker 
>     2.2 Usage in PM aware drivers 
> 
> 
> 1 Problem Statement 
> ~~~~~~~~~~~~~~~~~~~~
> 
> Want to to hit deep power state, even when the system is not actually
> idle.
> 
> Why?
> 
> - some hardware is not capable of deep power states in idle
> - difficulty getting userspace and/or kernel to be idle
> 
> 2 Solution: Opportunistic suspend 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Create an additional "idle path" which has new rules for determining
> idleness.  When this new "idle" is reached, trigger full-system
> suspend.  Since a suspend is triggered whenever the opportunity
> arises, this is called opportunistic suspend.
> 
> The new rules for making the idleness decision are simple:
> 
> 1.  system may suspend if and only if no suspend blockers are held
> 
> 2.1 When to use a suspend blocker 
> ==================================
> 
> [A list of reasons why suspend blockers might be used would be very
>  helpful here.] 
> 
> - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
> 
> - screen is on
> 
> - someone mentioned "Google use cases"
>   (would be nice to hear about more of these)

Yes, I think the Android developers know quite a few cases where suspend
blockers are useful.

> 2.2 Usage in PM aware drivers 
> ==============================
> 
> [An example of how a driver already using runtime PM would use 
>  a suspend blocker would also be helpful.

When we have any drivers using both in the tree, they will be used as examples
here.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Monday 10 May 2010, Kevin Hilman wrote:
> Hello,

Hi Kevin,

> I think many folks are still confused about exactly the problem being
> solved by this series as well as mixed up between opportunistic
> suspend and suspend blockers.  Also, how this series impatcs the rest
> of the kernel (especially PM-aware drivers and subsystems) has caused
> a bit of confusion.
> 
> To help with the confusion, I think a much clearer description of the
> problem being solved and the proposed solution is needed.  
> 
> To that end, I created a starting point for that below which
> summarizes how I understand the problem and the proposed solution, but
> of course this should be filled out in more detail and updated as part
> of the documentation that goes with this series.
> 
> Hope this helps improve the understanding of this feature,

Yes, I think this is helpful.

> Table of Contents
> =================
> 1 Problem Statement 
> 2 Solution: Opportunistic suspend 
>     2.1 When to use a suspend blocker 
>     2.2 Usage in PM aware drivers 
> 
> 
> 1 Problem Statement 
> ~~~~~~~~~~~~~~~~~~~~
> 
> Want to to hit deep power state, even when the system is not actually
> idle.
> 
> Why?
> 
> - some hardware is not capable of deep power states in idle
> - difficulty getting userspace and/or kernel to be idle
> 
> 2 Solution: Opportunistic suspend 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Create an additional "idle path" which has new rules for determining
> idleness.  When this new "idle" is reached, trigger full-system
> suspend.  Since a suspend is triggered whenever the opportunity
> arises, this is called opportunistic suspend.
> 
> The new rules for making the idleness decision are simple:
> 
> 1.  system may suspend if and only if no suspend blockers are held
> 
> 2.1 When to use a suspend blocker 
> ==================================
> 
> [A list of reasons why suspend blockers might be used would be very
>  helpful here.] 
> 
> - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
> 
> - screen is on
> 
> - someone mentioned "Google use cases"
>   (would be nice to hear about more of these)

Yes, I think the Android developers know quite a few cases where suspend
blockers are useful.

> 2.2 Usage in PM aware drivers 
> ==============================
> 
> [An example of how a driver already using runtime PM would use 
>  a suspend blocker would also be helpful.

When we have any drivers using both in the tree, they will be used as examples
here.

Thanks,
Rafael

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

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100510 13:27]:
> On Monday 10 May 2010, Kevin Hilman wrote:
> > Hello,
> 
> Hi Kevin,
> 
> > I think many folks are still confused about exactly the problem being
> > solved by this series as well as mixed up between opportunistic
> > suspend and suspend blockers.  Also, how this series impatcs the rest
> > of the kernel (especially PM-aware drivers and subsystems) has caused
> > a bit of confusion.
> > 
> > To help with the confusion, I think a much clearer description of the
> > problem being solved and the proposed solution is needed.  
> > 
> > To that end, I created a starting point for that below which
> > summarizes how I understand the problem and the proposed solution, but
> > of course this should be filled out in more detail and updated as part
> > of the documentation that goes with this series.
> > 
> > Hope this helps improve the understanding of this feature,
> 
> Yes, I think this is helpful.
> 
> > Table of Contents
> > =================
> > 1 Problem Statement 
> > 2 Solution: Opportunistic suspend 
> >     2.1 When to use a suspend blocker 
> >     2.2 Usage in PM aware drivers 
> > 
> > 
> > 1 Problem Statement 
> > ~~~~~~~~~~~~~~~~~~~~
> > 
> > Want to to hit deep power state, even when the system is not actually
> > idle.
> > 
> > Why?
> > 
> > - some hardware is not capable of deep power states in idle
> > - difficulty getting userspace and/or kernel to be idle
> > 
> > 2 Solution: Opportunistic suspend 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Create an additional "idle path" which has new rules for determining
> > idleness.  When this new "idle" is reached, trigger full-system
> > suspend.  Since a suspend is triggered whenever the opportunity
> > arises, this is called opportunistic suspend.

I agree, this is is the right way to handle when to enter suspend.

Especially if the system needs to run while waiting for something
to happen before being able to suspend.

> > The new rules for making the idleness decision are simple:
> > 
> > 1.  system may suspend if and only if no suspend blockers are held

To me it sounds like this should only be allowed to happen when you do:

# echo 1 > /sys/power/suspend_while_idle

As it kills the timers and leads to non-standard behaviour of the apps
as they won't run :)

And then the remaining question is how to make sure the use cases
below can be handled in a clean way.
 
> > 2.1 When to use a suspend blocker 
> > ==================================
> > 
> > [A list of reasons why suspend blockers might be used would be very
> >  helpful here.] 
> > 
> > - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
> > 
> > - screen is on
> > 
> > - someone mentioned "Google use cases"
> >   (would be nice to hear about more of these)
> 
> Yes, I think the Android developers know quite a few cases where suspend
> blockers are useful.
> 
> > 2.2 Usage in PM aware drivers 
> > ==============================
> > 
> > [An example of how a driver already using runtime PM would use 
> >  a suspend blocker would also be helpful.
> 
> When we have any drivers using both in the tree, they will be used as examples
> here.
> 
> 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/

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

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100510 13:27]:
> On Monday 10 May 2010, Kevin Hilman wrote:
> > Hello,
> 
> Hi Kevin,
> 
> > I think many folks are still confused about exactly the problem being
> > solved by this series as well as mixed up between opportunistic
> > suspend and suspend blockers.  Also, how this series impatcs the rest
> > of the kernel (especially PM-aware drivers and subsystems) has caused
> > a bit of confusion.
> > 
> > To help with the confusion, I think a much clearer description of the
> > problem being solved and the proposed solution is needed.  
> > 
> > To that end, I created a starting point for that below which
> > summarizes how I understand the problem and the proposed solution, but
> > of course this should be filled out in more detail and updated as part
> > of the documentation that goes with this series.
> > 
> > Hope this helps improve the understanding of this feature,
> 
> Yes, I think this is helpful.
> 
> > Table of Contents
> > =================
> > 1 Problem Statement 
> > 2 Solution: Opportunistic suspend 
> >     2.1 When to use a suspend blocker 
> >     2.2 Usage in PM aware drivers 
> > 
> > 
> > 1 Problem Statement 
> > ~~~~~~~~~~~~~~~~~~~~
> > 
> > Want to to hit deep power state, even when the system is not actually
> > idle.
> > 
> > Why?
> > 
> > - some hardware is not capable of deep power states in idle
> > - difficulty getting userspace and/or kernel to be idle
> > 
> > 2 Solution: Opportunistic suspend 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Create an additional "idle path" which has new rules for determining
> > idleness.  When this new "idle" is reached, trigger full-system
> > suspend.  Since a suspend is triggered whenever the opportunity
> > arises, this is called opportunistic suspend.

I agree, this is is the right way to handle when to enter suspend.

Especially if the system needs to run while waiting for something
to happen before being able to suspend.

> > The new rules for making the idleness decision are simple:
> > 
> > 1.  system may suspend if and only if no suspend blockers are held

To me it sounds like this should only be allowed to happen when you do:

# echo 1 > /sys/power/suspend_while_idle

As it kills the timers and leads to non-standard behaviour of the apps
as they won't run :)

And then the remaining question is how to make sure the use cases
below can be handled in a clean way.
 
> > 2.1 When to use a suspend blocker 
> > ==================================
> > 
> > [A list of reasons why suspend blockers might be used would be very
> >  helpful here.] 
> > 
> > - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
> > 
> > - screen is on
> > 
> > - someone mentioned "Google use cases"
> >   (would be nice to hear about more of these)
> 
> Yes, I think the Android developers know quite a few cases where suspend
> blockers are useful.
> 
> > 2.2 Usage in PM aware drivers 
> > ==============================
> > 
> > [An example of how a driver already using runtime PM would use 
> >  a suspend blocker would also be helpful.
> 
> When we have any drivers using both in the tree, they will be used as examples
> here.
> 
> 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/

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote:

> To me it sounds like this should only be allowed to happen when you do:
> 
> # echo 1 > /sys/power/suspend_while_idle
> 
> As it kills the timers and leads to non-standard behaviour of the apps
> as they won't run :)
> 
> And then the remaining question is how to make sure the use cases
> below can be handled in a clean way.

That's handled by the /sys/power/policy opportunistic/forced switch.

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

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote:

> To me it sounds like this should only be allowed to happen when you do:
> 
> # echo 1 > /sys/power/suspend_while_idle
> 
> As it kills the timers and leads to non-standard behaviour of the apps
> as they won't run :)
> 
> And then the remaining question is how to make sure the use cases
> below can be handled in a clean way.

That's handled by the /sys/power/policy opportunistic/forced switch.

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

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:10]:
> On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote:
> 
> > To me it sounds like this should only be allowed to happen when you do:
> > 
> > # echo 1 > /sys/power/suspend_while_idle
> > 
> > As it kills the timers and leads to non-standard behaviour of the apps
> > as they won't run :)
> > 
> > And then the remaining question is how to make sure the use cases
> > below can be handled in a clean way.
> 
> That's handled by the /sys/power/policy opportunistic/forced switch.

OK, so can the suspend blocker then become just:

# Block suspend while idle, system stays running
# echo default > /sys/power/policy

and the when it's OK to suspend:

# Allow suspend while idle, system suspends when it hits kernel idle loop
# echo opportunistic > /sys/power/policy

or do you still need something more to ensure the data gets into your
app and be handled?

The part I really don't like is the idea of patching all over the drivers
and userspace for the wakelocks/suspendblocks.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:10]:
> On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote:
> 
> > To me it sounds like this should only be allowed to happen when you do:
> > 
> > # echo 1 > /sys/power/suspend_while_idle
> > 
> > As it kills the timers and leads to non-standard behaviour of the apps
> > as they won't run :)
> > 
> > And then the remaining question is how to make sure the use cases
> > below can be handled in a clean way.
> 
> That's handled by the /sys/power/policy opportunistic/forced switch.

OK, so can the suspend blocker then become just:

# Block suspend while idle, system stays running
# echo default > /sys/power/policy

and the when it's OK to suspend:

# Allow suspend while idle, system suspends when it hits kernel idle loop
# echo opportunistic > /sys/power/policy

or do you still need something more to ensure the data gets into your
app and be handled?

The part I really don't like is the idea of patching all over the drivers
and userspace for the wakelocks/suspendblocks.

Regards,

Tony

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote:
> OK, so can the suspend blocker then become just:
> 
> # Block suspend while idle, system stays running
> # echo default > /sys/power/policy
> 
> and the when it's OK to suspend:
> 
> # Allow suspend while idle, system suspends when it hits kernel idle loop
> # echo opportunistic > /sys/power/policy
> 
> or do you still need something more to ensure the data gets into your
> app and be handled?

Yes. You still need suspend blocks.

> The part I really don't like is the idea of patching all over the drivers
> and userspace for the wakelocks/suspendblocks.

I don't like the idea either, but given that nobody has actually 
provided any other ideas that would actually work then I don't think 
we've got a great deal of choice.

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

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote:
> OK, so can the suspend blocker then become just:
> 
> # Block suspend while idle, system stays running
> # echo default > /sys/power/policy
> 
> and the when it's OK to suspend:
> 
> # Allow suspend while idle, system suspends when it hits kernel idle loop
> # echo opportunistic > /sys/power/policy
> 
> or do you still need something more to ensure the data gets into your
> app and be handled?

Yes. You still need suspend blocks.

> The part I really don't like is the idea of patching all over the drivers
> and userspace for the wakelocks/suspendblocks.

I don't like the idea either, but given that nobody has actually 
provided any other ideas that would actually work then I don't think 
we've got a great deal of choice.

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

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote:
> > OK, so can the suspend blocker then become just:
> > 
> > # Block suspend while idle, system stays running
> > # echo default > /sys/power/policy
> > 
> > and the when it's OK to suspend:
> > 
> > # Allow suspend while idle, system suspends when it hits kernel idle loop
> > # echo opportunistic > /sys/power/policy
> > 
> > or do you still need something more to ensure the data gets into your
> > app and be handled?
> 
> Yes. You still need suspend blocks.

Maybe not if echo opportunistic > /sys/power/policy gets cleared by
the kernel if the kernel idle loop can't make it. That means something
has blocked the suspend attempt in a driver for example. The system
keeps running, and the userspace can deal with the situation.
 
> > The part I really don't like is the idea of patching all over the drivers
> > and userspace for the wakelocks/suspendblocks.
> 
> I don't like the idea either, but given that nobody has actually 
> provided any other ideas that would actually work then I don't think 
> we've got a great deal of choice.

If the opportunistic kernel flag is one time attempt only, then you
could take care of the wakelock/suspendblock handling in the userspace
completely. And once the userspace wakelock/suspendblock is cleared,
the userspace can again echo opportunistic > /sys/power/policy.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote:
> > OK, so can the suspend blocker then become just:
> > 
> > # Block suspend while idle, system stays running
> > # echo default > /sys/power/policy
> > 
> > and the when it's OK to suspend:
> > 
> > # Allow suspend while idle, system suspends when it hits kernel idle loop
> > # echo opportunistic > /sys/power/policy
> > 
> > or do you still need something more to ensure the data gets into your
> > app and be handled?
> 
> Yes. You still need suspend blocks.

Maybe not if echo opportunistic > /sys/power/policy gets cleared by
the kernel if the kernel idle loop can't make it. That means something
has blocked the suspend attempt in a driver for example. The system
keeps running, and the userspace can deal with the situation.
 
> > The part I really don't like is the idea of patching all over the drivers
> > and userspace for the wakelocks/suspendblocks.
> 
> I don't like the idea either, but given that nobody has actually 
> provided any other ideas that would actually work then I don't think 
> we've got a great deal of choice.

If the opportunistic kernel flag is one time attempt only, then you
could take care of the wakelock/suspendblock handling in the userspace
completely. And once the userspace wakelock/suspendblock is cleared,
the userspace can again echo opportunistic > /sys/power/policy.

Regards,

Tony

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> > Yes. You still need suspend blocks.
> 
> Maybe not if echo opportunistic > /sys/power/policy gets cleared by
> the kernel if the kernel idle loop can't make it. That means something
> has blocked the suspend attempt in a driver for example. The system
> keeps running, and the userspace can deal with the situation.

So an event arrives just as userspace does this write. How do you avoid 
the race? Plausible answers mostly appear to end up looking like suspend 
blockers.

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

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

[Matthew Garrett]

On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> > Yes. You still need suspend blocks.
> 
> Maybe not if echo opportunistic > /sys/power/policy gets cleared by
> the kernel if the kernel idle loop can't make it. That means something
> has blocked the suspend attempt in a driver for example. The system
> keeps running, and the userspace can deal with the situation.

So an event arrives just as userspace does this write. How do you avoid 
the race? Plausible answers mostly appear to end up looking like suspend 
blockers.

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

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:59]:
> On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> > > Yes. You still need suspend blocks.
> > 
> > Maybe not if echo opportunistic > /sys/power/policy gets cleared by
> > the kernel if the kernel idle loop can't make it. That means something
> > has blocked the suspend attempt in a driver for example. The system
> > keeps running, and the userspace can deal with the situation.
> 
> So an event arrives just as userspace does this write. How do you avoid 
> the race? Plausible answers mostly appear to end up looking like suspend 
> blockers.

Assuming you attempt suspend in a custom pm_idle function, any driver
handling the event can fail the suspend attempt.

And that would clear the opportunistic suspend flag. And the userspace
would be still running and could handle the event. And when the userspace
is done, it can again echo opportunistic > /sys/power/policy.

For the failed suspend path in the kernel, currently the kernel would
unwind back all the drivers because of the failed driver, but that path
should be possible to optimize.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 09:59]:
> On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100511 09:41]:
> > > Yes. You still need suspend blocks.
> > 
> > Maybe not if echo opportunistic > /sys/power/policy gets cleared by
> > the kernel if the kernel idle loop can't make it. That means something
> > has blocked the suspend attempt in a driver for example. The system
> > keeps running, and the userspace can deal with the situation.
> 
> So an event arrives just as userspace does this write. How do you avoid 
> the race? Plausible answers mostly appear to end up looking like suspend 
> blockers.

Assuming you attempt suspend in a custom pm_idle function, any driver
handling the event can fail the suspend attempt.

And that would clear the opportunistic suspend flag. And the userspace
would be still running and could handle the event. And when the userspace
is done, it can again echo opportunistic > /sys/power/policy.

For the failed suspend path in the kernel, currently the kernel would
unwind back all the drivers because of the failed driver, but that path
should be possible to optimize.

Regards,

Tony

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

[Matthew Garrett]

On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:

> For the failed suspend path in the kernel, currently the kernel would
> unwind back all the drivers because of the failed driver, but that path
> should be possible to optimize.

If you think it's possible to make this work then feel free to. But at 
the point where you're adding code to every driver's suspend function to 
determine whether or not it's got any pending events that userspace 
hasn't consumed yet, and adding code to every bit of userspace to allow 
it to indicate whether or not it's busy consuming events or just busy 
drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

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

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

[Matthew Garrett]

On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:

> For the failed suspend path in the kernel, currently the kernel would
> unwind back all the drivers because of the failed driver, but that path
> should be possible to optimize.

If you think it's possible to make this work then feel free to. But at 
the point where you're adding code to every driver's suspend function to 
determine whether or not it's got any pending events that userspace 
hasn't consumed yet, and adding code to every bit of userspace to allow 
it to indicate whether or not it's busy consuming events or just busy 
drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

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

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 10:25]:
> On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> 
> > For the failed suspend path in the kernel, currently the kernel would
> > unwind back all the drivers because of the failed driver, but that path
> > should be possible to optimize.
> 
> If you think it's possible to make this work then feel free to. But at 
> the point where you're adding code to every driver's suspend function to 
> determine whether or not it's got any pending events that userspace 
> hasn't consumed yet, and adding code to every bit of userspace to allow 
> it to indicate whether or not it's busy consuming events or just busy 
> drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

Sorry, I have a working system that idles nicely and stays up on
batteries for a long time while running. I don't need to implement
anything like this :)

Cheers,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100511 10:25]:
> On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> 
> > For the failed suspend path in the kernel, currently the kernel would
> > unwind back all the drivers because of the failed driver, but that path
> > should be possible to optimize.
> 
> If you think it's possible to make this work then feel free to. But at 
> the point where you're adding code to every driver's suspend function to 
> determine whether or not it's got any pending events that userspace 
> hasn't consumed yet, and adding code to every bit of userspace to allow 
> it to indicate whether or not it's busy consuming events or just busy 
> drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

Sorry, I have a working system that idles nicely and stays up on
batteries for a long time while running. I don't need to implement
anything like this :)

Cheers,

Tony

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

[Matthew Garrett]

On Tue, May 11, 2010 at 10:48:58AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100511 10:25]:
> > On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> > 
> > > For the failed suspend path in the kernel, currently the kernel would
> > > unwind back all the drivers because of the failed driver, but that path
> > > should be possible to optimize.
> > 
> > If you think it's possible to make this work then feel free to. But at 
> > the point where you're adding code to every driver's suspend function to 
> > determine whether or not it's got any pending events that userspace 
> > hasn't consumed yet, and adding code to every bit of userspace to allow 
> > it to indicate whether or not it's busy consuming events or just busy 
> > drawing 3D bouncing cattle, I think you've reinvented suspend blocks.
> 
> Sorry, I have a working system that idles nicely and stays up on
> batteries for a long time while running. I don't need to implement
> anything like this :)

Right, but your system will only idle nicely if all of your userspace is 
well-written. It's not reasonable to expect that all userspace will be 
well-written and thus it's necessary to implement a power management 
strategy that doesn't require that. Refusing an implementation that 
achieves that on the basis that there's hypothetically a better way of 
doing it is entirely unreasonable.

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

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

[Matthew Garrett]

On Tue, May 11, 2010 at 10:48:58AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100511 10:25]:
> > On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> > 
> > > For the failed suspend path in the kernel, currently the kernel would
> > > unwind back all the drivers because of the failed driver, but that path
> > > should be possible to optimize.
> > 
> > If you think it's possible to make this work then feel free to. But at 
> > the point where you're adding code to every driver's suspend function to 
> > determine whether or not it's got any pending events that userspace 
> > hasn't consumed yet, and adding code to every bit of userspace to allow 
> > it to indicate whether or not it's busy consuming events or just busy 
> > drawing 3D bouncing cattle, I think you've reinvented suspend blocks.
> 
> Sorry, I have a working system that idles nicely and stays up on
> batteries for a long time while running. I don't need to implement
> anything like this :)

Right, but your system will only idle nicely if all of your userspace is 
well-written. It's not reasonable to expect that all userspace will be 
well-written and thus it's necessary to implement a power management 
strategy that doesn't require that. Refusing an implementation that 
achieves that on the basis that there's hypothetically a better way of 
doing it is entirely unreasonable.

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

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

[Rafael J. Wysocki]

On Tuesday 11 May 2010, Matthew Garrett wrote:
> On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> 
> > For the failed suspend path in the kernel, currently the kernel would
> > unwind back all the drivers because of the failed driver, but that path
> > should be possible to optimize.
> 
> If you think it's possible to make this work then feel free to. But at 
> the point where you're adding code to every driver's suspend function to 
> determine whether or not it's got any pending events that userspace 
> hasn't consumed yet, and adding code to every bit of userspace to allow 
> it to indicate whether or not it's busy consuming events or just busy 
> drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

Yeah, pretty much so.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Tuesday 11 May 2010, Matthew Garrett wrote:
> On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote:
> 
> > For the failed suspend path in the kernel, currently the kernel would
> > unwind back all the drivers because of the failed driver, but that path
> > should be possible to optimize.
> 
> If you think it's possible to make this work then feel free to. But at 
> the point where you're adding code to every driver's suspend function to 
> determine whether or not it's got any pending events that userspace 
> hasn't consumed yet, and adding code to every bit of userspace to allow 
> it to indicate whether or not it's busy consuming events or just busy 
> drawing 3D bouncing cattle, I think you've reinvented suspend blocks.

Yeah, pretty much so.

Thanks,
Rafael

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

[Mark Brown]

On Fri, May 07, 2010 at 02:30:25PM +0100, Mark Brown wrote:

> I mean that I will extend the embedded audio subsystem that the kernel
> already has (ASoC, in sound/soc) to support ignoring suspends for some
> audio paths so that they can be kept up during suspend.  This will be
> primarily intended for use with opportunistic suspend but not specific
> to it.

Just for the record I've now done an implementation of this which should
show up in -next when it's rebuilt and 2.6.35.  It's not the most
thoroughly tested code I've ever written but I'm fairly happy it'll do
the right thing, especially for analogue basebands.  The functionality
needs to be explicitly requested by machine drivers so there should be
no impact on systems using suspend in a more standard fashion.

This means that there should be even less of an issue merging this from
an audio point of view.

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

[Mark Brown]

On Fri, May 07, 2010 at 02:30:25PM +0100, Mark Brown wrote:

> I mean that I will extend the embedded audio subsystem that the kernel
> already has (ASoC, in sound/soc) to support ignoring suspends for some
> audio paths so that they can be kept up during suspend.  This will be
> primarily intended for use with opportunistic suspend but not specific
> to it.

Just for the record I've now done an implementation of this which should
show up in -next when it's rebuilt and 2.6.35.  It's not the most
thoroughly tested code I've ever written but I'm fairly happy it'll do
the right thing, especially for analogue basebands.  The functionality
needs to be explicitly requested by machine drivers so there should be
no impact on systems using suspend in a more standard fashion.

This means that there should be even less of an issue merging this from
an audio point of view.

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

[Arve Hjønnevåg]

2010/5/10 Kevin Hilman <khilman@deeprootsystems.com>:
> Hello,
>
> I think many folks are still confused about exactly the problem being
> solved by this series as well as mixed up between opportunistic
> suspend and suspend blockers.  Also, how this series impatcs the rest
> of the kernel (especially PM-aware drivers and subsystems) has caused
> a bit of confusion.
>
> To help with the confusion, I think a much clearer description of the
> problem being solved and the proposed solution is needed.
>
> To that end, I created a starting point for that below which
> summarizes how I understand the problem and the proposed solution, but
> of course this should be filled out in more detail and updated as part
> of the documentation that goes with this series.
>
> Hope this helps improve the understanding of this feature,
>
> Kevin
>
>
>
> Table of Contents
> =================
> 1 Problem Statement
> 2 Solution: Opportunistic suspend
>    2.1 When to use a suspend blocker
>    2.2 Usage in PM aware drivers
>
>
> 1 Problem Statement
> ~~~~~~~~~~~~~~~~~~~~
>
> Want to to hit deep power state, even when the system is not actually
> idle.
>
> Why?
>
> - some hardware is not capable of deep power states in idle
> - difficulty getting userspace and/or kernel to be idle

There are two parts to this. Suspend freezes tasks that don't idle at
all, and it stops the monotonic clock which in turn stops tasks that
do (frequent) periodic work.

>
> 2 Solution: Opportunistic suspend
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Create an additional "idle path" which has new rules for determining
> idleness.  When this new "idle" is reached, trigger full-system
> suspend.  Since a suspend is triggered whenever the opportunity
> arises, this is called opportunistic suspend.
>
> The new rules for making the idleness decision are simple:
>
> 1.  system may suspend if and only if no suspend blockers are held
>
> 2.1 When to use a suspend blocker
> ==================================
>
> [A list of reasons why suspend blockers might be used would be very
>  helpful here.]
>
> - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
>
> - screen is on
>
> - someone mentioned "Google use cases"
>  (would be nice to hear about more of these)

Most uses of suspend blockers are in some way tied to a potential
wakeup event. We use (a) suspend blocker(s) to make sure the event
propagates to the code that will handle the event, and that code then
uses another suspend blocker while it handles the event.

Some examples:

The battery monitor on Nexus One uses a periodic alarm to wake up the
system. The alarm driver will block suspend so the timer can fire, and
the battery monitor will block suspend while reading the battery
status and changing the charge mode.

Phone rings: We use a few suspend blockers to process the low level
message from the modem which end up returning a message on a tty. The
last step in the kernel currently uses a wakelock with a timeout since
we have not modified the tty layer to block suspend. The user space
ril process then blocks suspend while it handles this message.

USB: We get a (wakeup) message from the modem that there is power on
the usb connector and we block suspend while we detect what is
connected. If we are connected to a USB host, we block suspend and
turn on the usb interface.

>
> 2.2 Usage in PM aware drivers
> ==============================
>
> [An example of how a driver already using runtime PM would use
>  a suspend blocker would also be helpful.
>

An audio driver can block suspend while audio is playing. We don't
currently use the runtime pm framework since this is new, but we do
runtime pm by turning off clocks and power when the device is
inactive.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/5/10 Kevin Hilman <khilman@deeprootsystems.com>:
> Hello,
>
> I think many folks are still confused about exactly the problem being
> solved by this series as well as mixed up between opportunistic
> suspend and suspend blockers.  Also, how this series impatcs the rest
> of the kernel (especially PM-aware drivers and subsystems) has caused
> a bit of confusion.
>
> To help with the confusion, I think a much clearer description of the
> problem being solved and the proposed solution is needed.
>
> To that end, I created a starting point for that below which
> summarizes how I understand the problem and the proposed solution, but
> of course this should be filled out in more detail and updated as part
> of the documentation that goes with this series.
>
> Hope this helps improve the understanding of this feature,
>
> Kevin
>
>
>
> Table of Contents
> =================
> 1 Problem Statement
> 2 Solution: Opportunistic suspend
>    2.1 When to use a suspend blocker
>    2.2 Usage in PM aware drivers
>
>
> 1 Problem Statement
> ~~~~~~~~~~~~~~~~~~~~
>
> Want to to hit deep power state, even when the system is not actually
> idle.
>
> Why?
>
> - some hardware is not capable of deep power states in idle
> - difficulty getting userspace and/or kernel to be idle

There are two parts to this. Suspend freezes tasks that don't idle at
all, and it stops the monotonic clock which in turn stops tasks that
do (frequent) periodic work.

>
> 2 Solution: Opportunistic suspend
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Create an additional "idle path" which has new rules for determining
> idleness.  When this new "idle" is reached, trigger full-system
> suspend.  Since a suspend is triggered whenever the opportunity
> arises, this is called opportunistic suspend.
>
> The new rules for making the idleness decision are simple:
>
> 1.  system may suspend if and only if no suspend blockers are held
>
> 2.1 When to use a suspend blocker
> ==================================
>
> [A list of reasons why suspend blockers might be used would be very
>  helpful here.]
>
> - ensure wakeup events propagate to userspace (e.g. keypad example in doc)
>
> - screen is on
>
> - someone mentioned "Google use cases"
>  (would be nice to hear about more of these)

Most uses of suspend blockers are in some way tied to a potential
wakeup event. We use (a) suspend blocker(s) to make sure the event
propagates to the code that will handle the event, and that code then
uses another suspend blocker while it handles the event.

Some examples:

The battery monitor on Nexus One uses a periodic alarm to wake up the
system. The alarm driver will block suspend so the timer can fire, and
the battery monitor will block suspend while reading the battery
status and changing the charge mode.

Phone rings: We use a few suspend blockers to process the low level
message from the modem which end up returning a message on a tty. The
last step in the kernel currently uses a wakelock with a timeout since
we have not modified the tty layer to block suspend. The user space
ril process then blocks suspend while it handles this message.

USB: We get a (wakeup) message from the modem that there is power on
the usb connector and we block suspend while we detect what is
connected. If we are connected to a USB host, we block suspend and
turn on the usb interface.

>
> 2.2 Usage in PM aware drivers
> ==============================
>
> [An example of how a driver already using runtime PM would use
>  a suspend blocker would also be helpful.
>

An audio driver can block suspend while audio is playing. We don't
currently use the runtime pm framework since this is new, but we do
runtime pm by turning off clocks and power when the device is
inactive.

-- 
Arve Hjønnevåg

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

[Mark Brown]

On Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote:

> > 2.2 Usage in PM aware drivers
> > ==============================

> > [An example of how a driver already using runtime PM would use
> > ?a suspend blocker would also be helpful.

> An audio driver can block suspend while audio is playing. We don't
> currently use the runtime pm framework since this is new, but we do
> runtime pm by turning off clocks and power when the device is
> inactive.

Could you clarify what's going on here please?  What do you mean by an
"audio driver" here - there's several different classes of driver which
work together to produce the embedded audio subsystem and I'm not clear
which you're referring to here.  I'd not expect a chip-specific audio
driver to be taking suspend blockers at all except during things like
accessory detect handling which can take a long time.  A system-specific
driver could reasonably block during playback but doing it in a chip
specific driver sounds like a bit too much of a policy decision.

The kernel runtime PM framwwork tends not to come into play for anything
except MFD and SoC drivers with audio where they're a component of PM on
the larger chip and it's useful for coordinating with the other drivers
in play.  Otherwise we already have very detailed automatic power
management (especially for the CODECs) and there's no benefit in
bouncing through runtime PM.

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

[Mark Brown]

On Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote:

> > 2.2 Usage in PM aware drivers
> > ==============================

> > [An example of how a driver already using runtime PM would use
> > ?a suspend blocker would also be helpful.

> An audio driver can block suspend while audio is playing. We don't
> currently use the runtime pm framework since this is new, but we do
> runtime pm by turning off clocks and power when the device is
> inactive.

Could you clarify what's going on here please?  What do you mean by an
"audio driver" here - there's several different classes of driver which
work together to produce the embedded audio subsystem and I'm not clear
which you're referring to here.  I'd not expect a chip-specific audio
driver to be taking suspend blockers at all except during things like
accessory detect handling which can take a long time.  A system-specific
driver could reasonably block during playback but doing it in a chip
specific driver sounds like a bit too much of a policy decision.

The kernel runtime PM framwwork tends not to come into play for anything
except MFD and SoC drivers with audio where they're a component of PM on
the larger chip and it's useful for coordinating with the other drivers
in play.  Otherwise we already have very detailed automatic power
management (especially for the CODECs) and there's no benefit in
bouncing through runtime PM.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Paul Walmsley]

Hello,

Some general comments on the suspend blockers/wakelock/opportunistic
suspend v6 patch series, posted here:

    https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html

The comments below are somewhat telegraphic in the interests of 
readability - more specific comments to follow in later E-mails. I am 
indebted to those of us who discussed these issues at LPC last year and 
ELC this year for several stimulating discussions.

There are several general problems with the design of opportunistic
suspend and suspend-blocks.

1. The opportunistic suspend code bypasses existing Linux kernel code,
   such as timers and the scheduler, that indicates when code
   needs to run, and when the system is idle.  This causes two problems:

   a. When opportunistic suspend is enabled, the default mode is to
      break all timers and scheduling on the system.  This isn't
      right: the default mode should be to preserve standard Linux
      behavior.  Exceptions can then be added for process groups that
      should run with the non-standard timer and scheduler behavior.

   b. The series introduces a de novo kernel API and userspace API
      that are unrelated to timers and the scheduler, but if the point
      is to modify the behavior of timers or the scheduler, the
      existing timer or scheduler APIs should be extended.  Any new
      APIs will need to be widely spread throughout the kernel and
      userspace.

2. The suspend-block kernel API tells the kernel _how_ to accomplish a
   goal, rather than telling the kernel _what_ the goal is.  This
   results in layering violations, unstated assumptions, and is too
   coarse-grained.  These problems in turn will cause fragile kernel
   code, kernel code with userspace dependencies, and power management
   problems on modern hardware.  Code should ask for what it wants.
   For example, if a driver needs to place an upper bound on its
   device wakeup latency, or if it needs to place an upper bound on
   interrupt response latency, that is what it should request.  Driver
   and subsystem code should not care how the kernel implements those
   requests, since the implementation can differ on different hardware
   and even on different use-cases with the same hardware.
   
3. Similarly, the suspend-block userspace API tells the kernel how to
   accomplish a goal, rather than telling the kernel what the goal is.
   Userspace processes should ask the kernel for what they really
   want.  If a process' timers should be disabled upon entering
   suspend, or the timer durations should have a lower bound, that's
   what the API should request.

Merging this series as currently designed and implemented will cause 
problems.  Suspend-blocks introduce a second, separate idle management 
approach in the Linux kernel.  The existing approach is the familiar timer 
and scheduler based approach.  The new approach is one where timers and 
runqueues no longer matter: the system is always at risk of entering 
suspend at any moment, with only suspend-blocks to stop it. Driver authors 
will effectively have to implement both approaches in their code.

Once merged, it will be nearly impossible to remove this code in favor 
of a cleaner approach.  Suspend-block calls are likely to spread 
throughout the kernel and drivers.  Patches 6, 7, and 8 are the leading 
edge of this - a quick grep through the Android common kernel at

    git://android.git.kernel.org/kernel/common.git 

shows wakelocks in the following drivers:

    drivers/input/evdev.c
    drivers/input/misc/gpio_input.c
    drivers/input/misc/gpio_matrix.c
    drivers/mmc/core/core.c
    drivers/rtc/alarm.c
    drivers/usb/gadget/f_mass_storage.c

Suspend-blocks will be difficult to convert to a finer-grained approach 
later.  The API design problems, mentioned above in points 2 and 3, will 
make it very difficult to determine what a driver author's or modifier's 
intention was when adding the suspend-block.  Also, patches 2 and 7 
introduce userspace APIs.  We will undoubtedly wish to avoid removing a 
userspace API once it is merged.  It will be quite difficult to implement 
such a general directive ("block system suspend") on a future kernel that 
may have a much finer-grained notion of low-power system modes, indeed 
that may have no useful notion of "system suspend."

...

The opportunistic suspend patches try to solve at least two real problems, 
that should be resolved in some way.  First, some types of userspace 
processes can unintentionally block system power management.  Second, the 
kernel is missing a system-wide form of CPUIdle.  This patch series, 
though, isn't the right way to solve either of these problems.  Let's 
figure out a different approach.

Figuring out a different way to do this should not limit Android at all, 
since Google can do what other Linux distributions do and continue to 
patch opportunistic suspend/suspend-block calls into their kernels as 
needed to ship devices, while contributing towards a different solution to 
the problem.

 
regards,

- Paul

(Linux-OMAP co-maintainer, focusing mostly on power management and 
software architecture issues)

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

[Paul Walmsley]

Hello,

Some general comments on the suspend blockers/wakelock/opportunistic
suspend v6 patch series, posted here:

    https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html

The comments below are somewhat telegraphic in the interests of 
readability - more specific comments to follow in later E-mails. I am 
indebted to those of us who discussed these issues at LPC last year and 
ELC this year for several stimulating discussions.

There are several general problems with the design of opportunistic
suspend and suspend-blocks.

1. The opportunistic suspend code bypasses existing Linux kernel code,
   such as timers and the scheduler, that indicates when code
   needs to run, and when the system is idle.  This causes two problems:

   a. When opportunistic suspend is enabled, the default mode is to
      break all timers and scheduling on the system.  This isn't
      right: the default mode should be to preserve standard Linux
      behavior.  Exceptions can then be added for process groups that
      should run with the non-standard timer and scheduler behavior.

   b. The series introduces a de novo kernel API and userspace API
      that are unrelated to timers and the scheduler, but if the point
      is to modify the behavior of timers or the scheduler, the
      existing timer or scheduler APIs should be extended.  Any new
      APIs will need to be widely spread throughout the kernel and
      userspace.

2. The suspend-block kernel API tells the kernel _how_ to accomplish a
   goal, rather than telling the kernel _what_ the goal is.  This
   results in layering violations, unstated assumptions, and is too
   coarse-grained.  These problems in turn will cause fragile kernel
   code, kernel code with userspace dependencies, and power management
   problems on modern hardware.  Code should ask for what it wants.
   For example, if a driver needs to place an upper bound on its
   device wakeup latency, or if it needs to place an upper bound on
   interrupt response latency, that is what it should request.  Driver
   and subsystem code should not care how the kernel implements those
   requests, since the implementation can differ on different hardware
   and even on different use-cases with the same hardware.
   
3. Similarly, the suspend-block userspace API tells the kernel how to
   accomplish a goal, rather than telling the kernel what the goal is.
   Userspace processes should ask the kernel for what they really
   want.  If a process' timers should be disabled upon entering
   suspend, or the timer durations should have a lower bound, that's
   what the API should request.

Merging this series as currently designed and implemented will cause 
problems.  Suspend-blocks introduce a second, separate idle management 
approach in the Linux kernel.  The existing approach is the familiar timer 
and scheduler based approach.  The new approach is one where timers and 
runqueues no longer matter: the system is always at risk of entering 
suspend at any moment, with only suspend-blocks to stop it. Driver authors 
will effectively have to implement both approaches in their code.

Once merged, it will be nearly impossible to remove this code in favor 
of a cleaner approach.  Suspend-block calls are likely to spread 
throughout the kernel and drivers.  Patches 6, 7, and 8 are the leading 
edge of this - a quick grep through the Android common kernel at

    git://android.git.kernel.org/kernel/common.git 

shows wakelocks in the following drivers:

    drivers/input/evdev.c
    drivers/input/misc/gpio_input.c
    drivers/input/misc/gpio_matrix.c
    drivers/mmc/core/core.c
    drivers/rtc/alarm.c
    drivers/usb/gadget/f_mass_storage.c

Suspend-blocks will be difficult to convert to a finer-grained approach 
later.  The API design problems, mentioned above in points 2 and 3, will 
make it very difficult to determine what a driver author's or modifier's 
intention was when adding the suspend-block.  Also, patches 2 and 7 
introduce userspace APIs.  We will undoubtedly wish to avoid removing a 
userspace API once it is merged.  It will be quite difficult to implement 
such a general directive ("block system suspend") on a future kernel that 
may have a much finer-grained notion of low-power system modes, indeed 
that may have no useful notion of "system suspend."

...

The opportunistic suspend patches try to solve at least two real problems, 
that should be resolved in some way.  First, some types of userspace 
processes can unintentionally block system power management.  Second, the 
kernel is missing a system-wide form of CPUIdle.  This patch series, 
though, isn't the right way to solve either of these problems.  Let's 
figure out a different approach.

Figuring out a different way to do this should not limit Android at all, 
since Google can do what other Linux distributions do and continue to 
patch opportunistic suspend/suspend-block calls into their kernels as 
needed to ship devices, while contributing towards a different solution to 
the problem.

 
regards,

- Paul

(Linux-OMAP co-maintainer, focusing mostly on power management and 
software architecture issues)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
> 
> Figuring out a different way to do this should not limit Android at all, 
> since Google can do what other Linux distributions do and continue to 
> patch opportunistic suspend/suspend-block calls into their kernels as 
> needed to ship devices, while contributing towards a different solution to 
> the problem.

I basically agree, except that despite having a year to do so none of us 
have come up with a different way that would actually work. Google have 
done this work. Who's going to prove that there is actually a different 
way to do this?

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

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

[Matthew Garrett]

On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
> 
> Figuring out a different way to do this should not limit Android at all, 
> since Google can do what other Linux distributions do and continue to 
> patch opportunistic suspend/suspend-block calls into their kernels as 
> needed to ship devices, while contributing towards a different solution to 
> the problem.

I basically agree, except that despite having a year to do so none of us 
have come up with a different way that would actually work. Google have 
done this work. Who's going to prove that there is actually a different 
way to do this?

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Wed, 12 May 2010, Paul Walmsley wrote:

> Hello,
> 
> Some general comments on the suspend blockers/wakelock/opportunistic
> suspend v6 patch series, posted here:
> 
>     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> 
> The comments below are somewhat telegraphic in the interests of 
> readability - more specific comments to follow in later E-mails. I am 
> indebted to those of us who discussed these issues at LPC last year and 
> ELC this year for several stimulating discussions.
> 
> There are several general problems with the design of opportunistic
> suspend and suspend-blocks.
> 
> 1. The opportunistic suspend code bypasses existing Linux kernel code,
>    such as timers and the scheduler, that indicates when code
>    needs to run, and when the system is idle.

Whoa!  That's not my understanding at all.

As I see it, opportunistic suspend doesn't bypass any code that isn't 
already bypassed by the existing suspend code.  Users can do

	echo mem >/sys/power/state

whenever they want, without regard to kernel timers and the scheduler 
(other than the fact that the user's thread must be running in order to 
carry out the write, of course).

>  This causes two problems:
> 
>    a. When opportunistic suspend is enabled, the default mode is to
>       break all timers and scheduling on the system.  This isn't
>       right: the default mode should be to preserve standard Linux
>       behavior.  Exceptions can then be added for process groups that
>       should run with the non-standard timer and scheduler behavior.

I don't understand this at all.  What gets broken, and how?  In 
particular, what gets broken that isn't also broken by "echo mem 
>/sys/power/state"?

>    b. The series introduces a de novo kernel API and userspace API
>       that are unrelated to timers and the scheduler, but if the point
>       is to modify the behavior of timers or the scheduler, the
>       existing timer or scheduler APIs should be extended.  Any new
>       APIs will need to be widely spread throughout the kernel and
>       userspace.

But the point _isn't_ to modify the behavior of timers and the
scheduler.  The point is to provide a way for the system to enter a
very low-power state as soon as possible while safely handling races.

> 2. The suspend-block kernel API tells the kernel _how_ to accomplish a
>    goal, rather than telling the kernel _what_ the goal is.  This
>    results in layering violations, unstated assumptions, and is too
>    coarse-grained.  These problems in turn will cause fragile kernel
>    code, kernel code with userspace dependencies, and power management
>    problems on modern hardware.  Code should ask for what it wants.
>    For example, if a driver needs to place an upper bound on its
>    device wakeup latency, or if it needs to place an upper bound on
>    interrupt response latency, that is what it should request.  Driver
>    and subsystem code should not care how the kernel implements those
>    requests, since the implementation can differ on different hardware
>    and even on different use-cases with the same hardware.

Although the first sentence is true, I don't find it useful.  The goal 
of suspend blockers is to prevent the system from entering a low-power 
state until some important task is finished.  It has little to do with 
interrupt response latency or device wakeup latency.

As far as I can tell, suspend blockers are more or less a direct
implementation of the desired goal.

> 3. Similarly, the suspend-block userspace API tells the kernel how to
>    accomplish a goal, rather than telling the kernel what the goal is.
>    Userspace processes should ask the kernel for what they really
>    want.  If a process' timers should be disabled upon entering
>    suspend, or the timer durations should have a lower bound, that's
>    what the API should request.

The userspace API has essentially the same goal as the kernel API.

> Merging this series as currently designed and implemented will cause 
> problems.  Suspend-blocks introduce a second, separate idle management 
> approach in the Linux kernel.  The existing approach is the familiar timer 
> and scheduler based approach.  The new approach is one where timers and 
> runqueues no longer matter: the system is always at risk of entering 
> suspend at any moment, with only suspend-blocks to stop it. Driver authors 
> will effectively have to implement both approaches in their code.

That's true.  Where's the problem?  The system is _already_ at risk of
entering suspend at any moment, as I described above.  If the "timer
and scheduler based" approach can be adapted to do what the Android 
people want, then all the better -- but I rather suspect it can't.

Alan Stern

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

[Alan Stern]

On Wed, 12 May 2010, Paul Walmsley wrote:

> Hello,
> 
> Some general comments on the suspend blockers/wakelock/opportunistic
> suspend v6 patch series, posted here:
> 
>     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> 
> The comments below are somewhat telegraphic in the interests of 
> readability - more specific comments to follow in later E-mails. I am 
> indebted to those of us who discussed these issues at LPC last year and 
> ELC this year for several stimulating discussions.
> 
> There are several general problems with the design of opportunistic
> suspend and suspend-blocks.
> 
> 1. The opportunistic suspend code bypasses existing Linux kernel code,
>    such as timers and the scheduler, that indicates when code
>    needs to run, and when the system is idle.

Whoa!  That's not my understanding at all.

As I see it, opportunistic suspend doesn't bypass any code that isn't 
already bypassed by the existing suspend code.  Users can do

	echo mem >/sys/power/state

whenever they want, without regard to kernel timers and the scheduler 
(other than the fact that the user's thread must be running in order to 
carry out the write, of course).

>  This causes two problems:
> 
>    a. When opportunistic suspend is enabled, the default mode is to
>       break all timers and scheduling on the system.  This isn't
>       right: the default mode should be to preserve standard Linux
>       behavior.  Exceptions can then be added for process groups that
>       should run with the non-standard timer and scheduler behavior.

I don't understand this at all.  What gets broken, and how?  In 
particular, what gets broken that isn't also broken by "echo mem 
>/sys/power/state"?

>    b. The series introduces a de novo kernel API and userspace API
>       that are unrelated to timers and the scheduler, but if the point
>       is to modify the behavior of timers or the scheduler, the
>       existing timer or scheduler APIs should be extended.  Any new
>       APIs will need to be widely spread throughout the kernel and
>       userspace.

But the point _isn't_ to modify the behavior of timers and the
scheduler.  The point is to provide a way for the system to enter a
very low-power state as soon as possible while safely handling races.

> 2. The suspend-block kernel API tells the kernel _how_ to accomplish a
>    goal, rather than telling the kernel _what_ the goal is.  This
>    results in layering violations, unstated assumptions, and is too
>    coarse-grained.  These problems in turn will cause fragile kernel
>    code, kernel code with userspace dependencies, and power management
>    problems on modern hardware.  Code should ask for what it wants.
>    For example, if a driver needs to place an upper bound on its
>    device wakeup latency, or if it needs to place an upper bound on
>    interrupt response latency, that is what it should request.  Driver
>    and subsystem code should not care how the kernel implements those
>    requests, since the implementation can differ on different hardware
>    and even on different use-cases with the same hardware.

Although the first sentence is true, I don't find it useful.  The goal 
of suspend blockers is to prevent the system from entering a low-power 
state until some important task is finished.  It has little to do with 
interrupt response latency or device wakeup latency.

As far as I can tell, suspend blockers are more or less a direct
implementation of the desired goal.

> 3. Similarly, the suspend-block userspace API tells the kernel how to
>    accomplish a goal, rather than telling the kernel what the goal is.
>    Userspace processes should ask the kernel for what they really
>    want.  If a process' timers should be disabled upon entering
>    suspend, or the timer durations should have a lower bound, that's
>    what the API should request.

The userspace API has essentially the same goal as the kernel API.

> Merging this series as currently designed and implemented will cause 
> problems.  Suspend-blocks introduce a second, separate idle management 
> approach in the Linux kernel.  The existing approach is the familiar timer 
> and scheduler based approach.  The new approach is one where timers and 
> runqueues no longer matter: the system is always at risk of entering 
> suspend at any moment, with only suspend-blocks to stop it. Driver authors 
> will effectively have to implement both approaches in their code.

That's true.  Where's the problem?  The system is _already_ at risk of
entering suspend at any moment, as I described above.  If the "timer
and scheduler based" approach can be adapted to do what the Android 
people want, then all the better -- but I rather suspect it can't.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote:
> On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
> > 
> > Figuring out a different way to do this should not limit Android at all, 
> > since Google can do what other Linux distributions do and continue to 
> > patch opportunistic suspend/suspend-block calls into their kernels as 
> > needed to ship devices, while contributing towards a different solution to 
> > the problem.
> 
> I basically agree, except that despite having a year to do so none of us 
> have come up with a different way that would actually work. Google have 
> done this work. Who's going to prove that there is actually a different 
> way to do this?

We all feel the pain of inelegance right? I think it's clear that this
system will not last (but there's no other immediate option) .. That
doesn't mean we should reject it, but we need to be clear that this
system will get replaced. So we should format the patches appropriately.
To me the userspace aspect is a permanent change .. If we could drop
that (or put it into debugfs) then it would make this a lot easy to
accept as a stepping stone.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote:
> On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
> > 
> > Figuring out a different way to do this should not limit Android at all, 
> > since Google can do what other Linux distributions do and continue to 
> > patch opportunistic suspend/suspend-block calls into their kernels as 
> > needed to ship devices, while contributing towards a different solution to 
> > the problem.
> 
> I basically agree, except that despite having a year to do so none of us 
> have come up with a different way that would actually work. Google have 
> done this work. Who's going to prove that there is actually a different 
> way to do this?

We all feel the pain of inelegance right? I think it's clear that this
system will not last (but there's no other immediate option) .. That
doesn't mean we should reject it, but we need to be clear that this
system will get replaced. So we should format the patches appropriately.
To me the userspace aspect is a permanent change .. If we could drop
that (or put it into debugfs) then it would make this a lot easy to
accept as a stepping stone.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Thu, May 13, 2010 at 10:33 AM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote:
>> On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
>> >
>> > Figuring out a different way to do this should not limit Android at all,
>> > since Google can do what other Linux distributions do and continue to
>> > patch opportunistic suspend/suspend-block calls into their kernels as
>> > needed to ship devices, while contributing towards a different solution to
>> > the problem.
>>
>> I basically agree, except that despite having a year to do so none of us
>> have come up with a different way that would actually work. Google have
>> done this work. Who's going to prove that there is actually a different
>> way to do this?
>
> We all feel the pain of inelegance right? I think it's clear that this
> system will not last (but there's no other immediate option) .. That
> doesn't mean we should reject it, but we need to be clear that this
> system will get replaced. So we should format the patches appropriately.
> To me the userspace aspect is a permanent change .. If we could drop
> that (or put it into debugfs) then it would make this a lot easy to
> accept as a stepping stone.

I'm in agreement on the first half of this -- from the Google/Android
point of view, if we can someday accomplish everything we need with
some different facility, we'll happily shift over to that.  That seems
like a normal operating mode for mainline -- new solutions arise,
drivers are migrated to those new solutions, old solutions fall to the
wayside.  We fully expect that the world will change over time and one
of our largest goals with trying to get work upstream is to reduce the
pain of those changes for everyone, while trying to get to "you can
build a kernel out of the box from mainline that Just Works with an
android userspace".

I'm not sure this necessitates using only debugfs for the userspace
interface.  A userspace interface is necessary to accomplish what
we're trying to do here, otherwise we have only half a solution, and
our hope is that it'd be a stable interface (as userspace interfaces
are supposed to be) for as long as its needed.  I could totally
imagine the userspace interface eventually becoming a no-op or
punching through to some other facility, depending on how this problem
is solved long-term in the ideal post-suspend-block future.

Brian

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

[Brian Swetland]

On Thu, May 13, 2010 at 10:33 AM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote:
>> On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
>> >
>> > Figuring out a different way to do this should not limit Android at all,
>> > since Google can do what other Linux distributions do and continue to
>> > patch opportunistic suspend/suspend-block calls into their kernels as
>> > needed to ship devices, while contributing towards a different solution to
>> > the problem.
>>
>> I basically agree, except that despite having a year to do so none of us
>> have come up with a different way that would actually work. Google have
>> done this work. Who's going to prove that there is actually a different
>> way to do this?
>
> We all feel the pain of inelegance right? I think it's clear that this
> system will not last (but there's no other immediate option) .. That
> doesn't mean we should reject it, but we need to be clear that this
> system will get replaced. So we should format the patches appropriately.
> To me the userspace aspect is a permanent change .. If we could drop
> that (or put it into debugfs) then it would make this a lot easy to
> accept as a stepping stone.

I'm in agreement on the first half of this -- from the Google/Android
point of view, if we can someday accomplish everything we need with
some different facility, we'll happily shift over to that.  That seems
like a normal operating mode for mainline -- new solutions arise,
drivers are migrated to those new solutions, old solutions fall to the
wayside.  We fully expect that the world will change over time and one
of our largest goals with trying to get work upstream is to reduce the
pain of those changes for everyone, while trying to get to "you can
build a kernel out of the box from mainline that Just Works with an
android userspace".

I'm not sure this necessitates using only debugfs for the userspace
interface.  A userspace interface is necessary to accomplish what
we're trying to do here, otherwise we have only half a solution, and
our hope is that it'd be a stable interface (as userspace interfaces
are supposed to be) for as long as its needed.  I could totally
imagine the userspace interface eventually becoming a no-op or
punching through to some other facility, depending on how this problem
is solved long-term in the ideal post-suspend-block future.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote:

> 
> I'm not sure this necessitates using only debugfs for the userspace
> interface.  A userspace interface is necessary to accomplish what
> we're trying to do here, otherwise we have only half a solution, and
> our hope is that it'd be a stable interface (as userspace interfaces
> are supposed to be) for as long as its needed.  I could totally
> imagine the userspace interface eventually becoming a no-op or
> punching through to some other facility, depending on how this problem
> is solved long-term in the ideal post-suspend-block future.

The problem is that once this userspace interface is exposed, it's
nearly permanent and has to be support for a long long time .. It might
seen trivial to just remove something your not using, but we never know
who is using what once the kernel is released.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote:

> 
> I'm not sure this necessitates using only debugfs for the userspace
> interface.  A userspace interface is necessary to accomplish what
> we're trying to do here, otherwise we have only half a solution, and
> our hope is that it'd be a stable interface (as userspace interfaces
> are supposed to be) for as long as its needed.  I could totally
> imagine the userspace interface eventually becoming a no-op or
> punching through to some other facility, depending on how this problem
> is solved long-term in the ideal post-suspend-block future.

The problem is that once this userspace interface is exposed, it's
nearly permanent and has to be support for a long long time .. It might
seen trivial to just remove something your not using, but we never know
who is using what once the kernel is released.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote:

> The problem is that once this userspace interface is exposed, it's
> nearly permanent and has to be support for a long long time .. It might
> seen trivial to just remove something your not using, but we never know
> who is using what once the kernel is released.

Deprecating sysfs interfaces can be done within 6 months or so, 
especially if there's only one real consumer.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote:

> The problem is that once this userspace interface is exposed, it's
> nearly permanent and has to be support for a long long time .. It might
> seen trivial to just remove something your not using, but we never know
> who is using what once the kernel is released.

Deprecating sysfs interfaces can be done within 6 months or so, 
especially if there's only one real consumer.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote:
> 
> > The problem is that once this userspace interface is exposed, it's
> > nearly permanent and has to be support for a long long time .. It might
> > seen trivial to just remove something your not using, but we never know
> > who is using what once the kernel is released.
> 
> Deprecating sysfs interfaces can be done within 6 months or so, 
> especially if there's only one real consumer.

I'll assume your right (can you give an example of this?), but why
should we even add it if we know it's already going to get replaced.
It's like it's pre-deprecated ..

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote:
> 
> > The problem is that once this userspace interface is exposed, it's
> > nearly permanent and has to be support for a long long time .. It might
> > seen trivial to just remove something your not using, but we never know
> > who is using what once the kernel is released.
> 
> Deprecating sysfs interfaces can be done within 6 months or so, 
> especially if there's only one real consumer.

I'll assume your right (can you give an example of this?), but why
should we even add it if we know it's already going to get replaced.
It's like it's pre-deprecated ..

Daniel

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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> > Deprecating sysfs interfaces can be done within 6 months or so, 
> > especially if there's only one real consumer.
> 
> I'll assume your right (can you give an example of this?), but why
> should we even add it if we know it's already going to get replaced.
> It's like it's pre-deprecated ..

See feature-removal-schedule.txt. So far we have no indication that it's 
going to be replaced, because nobody has actually suggested a working 
way to do this better. If we had a concrete implementation proposal for 
that then we'd be in a pretty different position right now.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> > Deprecating sysfs interfaces can be done within 6 months or so, 
> > especially if there's only one real consumer.
> 
> I'll assume your right (can you give an example of this?), but why
> should we even add it if we know it's already going to get replaced.
> It's like it's pre-deprecated ..

See feature-removal-schedule.txt. So far we have no indication that it's 
going to be replaced, because nobody has actually suggested a working 
way to do this better. If we had a concrete implementation proposal for 
that then we'd be in a pretty different position right now.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> On Wed, 12 May 2010, Paul Walmsley wrote:
> 
> > Hello,
> > 
> > Some general comments on the suspend blockers/wakelock/opportunistic
> > suspend v6 patch series, posted here:
> > 
> >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > 
> > The comments below are somewhat telegraphic in the interests of 
> > readability - more specific comments to follow in later E-mails. I am 
> > indebted to those of us who discussed these issues at LPC last year and 
> > ELC this year for several stimulating discussions.
> > 
> > There are several general problems with the design of opportunistic
> > suspend and suspend-blocks.
> > 
> > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> >    such as timers and the scheduler, that indicates when code
> >    needs to run, and when the system is idle.
> 
> Whoa!  That's not my understanding at all.
> 
> As I see it, opportunistic suspend doesn't bypass any code that isn't 
> already bypassed by the existing suspend code.  Users can do
> 
> 	echo mem >/sys/power/state
> 
> whenever they want, without regard to kernel timers and the scheduler 
> (other than the fact that the user's thread must be running in order to 
> carry out the write, of course).

The difference between echo mem > /sys/power/state and suspend blocks
is that with suspend blocks the system keeps running. And that's why 
it should be handled by runtime power management instead.

The suspend blocks seems like a hack to spam filter good and bad
apps from timer usage point of view. Applications are categorized
as good or bad depending if they grab a susped blocker or not.

I believe categorizing the apps should be instead done with some
timer flags or cgroups instead.

Cheers,

Tony

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

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> On Wed, 12 May 2010, Paul Walmsley wrote:
> 
> > Hello,
> > 
> > Some general comments on the suspend blockers/wakelock/opportunistic
> > suspend v6 patch series, posted here:
> > 
> >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > 
> > The comments below are somewhat telegraphic in the interests of 
> > readability - more specific comments to follow in later E-mails. I am 
> > indebted to those of us who discussed these issues at LPC last year and 
> > ELC this year for several stimulating discussions.
> > 
> > There are several general problems with the design of opportunistic
> > suspend and suspend-blocks.
> > 
> > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> >    such as timers and the scheduler, that indicates when code
> >    needs to run, and when the system is idle.
> 
> Whoa!  That's not my understanding at all.
> 
> As I see it, opportunistic suspend doesn't bypass any code that isn't 
> already bypassed by the existing suspend code.  Users can do
> 
> 	echo mem >/sys/power/state
> 
> whenever they want, without regard to kernel timers and the scheduler 
> (other than the fact that the user's thread must be running in order to 
> carry out the write, of course).

The difference between echo mem > /sys/power/state and suspend blocks
is that with suspend blocks the system keeps running. And that's why 
it should be handled by runtime power management instead.

The suspend blocks seems like a hack to spam filter good and bad
apps from timer usage point of view. Applications are categorized
as good or bad depending if they grab a susped blocker or not.

I believe categorizing the apps should be instead done with some
timer flags or cgroups instead.

Cheers,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> The suspend blocks seems like a hack to spam filter good and bad
> apps from timer usage point of view. Applications are categorized
> as good or bad depending if they grab a susped blocker or not.
> 
> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

I agree, but we have no mechanism for implementing that in a race-free 
way. We don't even have a realistical proposal for what that mechanism 
would look like. Should we refuse bread today for the promise of cake 
tomorrow?

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> The suspend blocks seems like a hack to spam filter good and bad
> apps from timer usage point of view. Applications are categorized
> as good or bad depending if they grab a susped blocker or not.
> 
> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

I agree, but we have no mechanism for implementing that in a race-free 
way. We don't even have a realistical proposal for what that mechanism 
would look like. Should we refuse bread today for the promise of cake 
tomorrow?

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> > > Deprecating sysfs interfaces can be done within 6 months or so, 
> > > especially if there's only one real consumer.
> > 
> > I'll assume your right (can you give an example of this?), but why
> > should we even add it if we know it's already going to get replaced.
> > It's like it's pre-deprecated ..
> 
> See feature-removal-schedule.txt. So far we have no indication that it's 
> going to be replaced, because nobody has actually suggested a working 
> way to do this better. If we had a concrete implementation proposal for 
> that then we'd be in a pretty different position right now.

Ok, feature-removal-schedule.txt applies to everything tho. What your
saying is that if this interface only last a short time it might take 6
months, if it last for a long time it would take longer. There's no easy
way to know that Google is the only user after some amount of time
passes.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> > > Deprecating sysfs interfaces can be done within 6 months or so, 
> > > especially if there's only one real consumer.
> > 
> > I'll assume your right (can you give an example of this?), but why
> > should we even add it if we know it's already going to get replaced.
> > It's like it's pre-deprecated ..
> 
> See feature-removal-schedule.txt. So far we have no indication that it's 
> going to be replaced, because nobody has actually suggested a working 
> way to do this better. If we had a concrete implementation proposal for 
> that then we'd be in a pretty different position right now.

Ok, feature-removal-schedule.txt applies to everything tho. What your
saying is that if this interface only last a short time it might take 6
months, if it last for a long time it would take longer. There's no easy
way to know that Google is the only user after some amount of time
passes.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 12:20]:
> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
> > 
> > I believe categorizing the apps should be instead done with some
> > timer flags or cgroups instead.
> 
> I agree, but we have no mechanism for implementing that in a race-free 
> way. We don't even have a realistical proposal for what that mechanism 
> would look like. Should we refuse bread today for the promise of cake 
> tomorrow?

Well this is an interesting problem, and once solved will be handy
for all kind of things. My worry is that if it's integrated in it's
current form it will be totally out of control all over the place :(

Still hoping we can come up with some clean way that avoid the patching
all over the place part.. How about the following, can you please check
if it would help with your example of guaranteed handling of event:

1. In the kernel, we add one more timer queue for critical timers.
   The current timer queue(s) stay as it is.

2. We allow selecting the timer based on some flag, the default
   behaviour being the current default timer queue.

3. Then we add next_timer_interupt_critical() to only query the
   critical timers along the lines of the current next_timer_interrupt().

4. We implement a custom pm_idle that suspends the system based on
   some logic and checking if next_timer_interrupt_critical() is
   empty. If the next_timer_interrupt_critical() does not return
   anything, we assume it's OK to suspend the system.

Now to me it sounds if your the input layer and userspace handle
both grab the timers with the critical flags, it should be guaranteed
that the events get handled before the system is suspended.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 12:20]:
> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
> > 
> > I believe categorizing the apps should be instead done with some
> > timer flags or cgroups instead.
> 
> I agree, but we have no mechanism for implementing that in a race-free 
> way. We don't even have a realistical proposal for what that mechanism 
> would look like. Should we refuse bread today for the promise of cake 
> tomorrow?

Well this is an interesting problem, and once solved will be handy
for all kind of things. My worry is that if it's integrated in it's
current form it will be totally out of control all over the place :(

Still hoping we can come up with some clean way that avoid the patching
all over the place part.. How about the following, can you please check
if it would help with your example of guaranteed handling of event:

1. In the kernel, we add one more timer queue for critical timers.
   The current timer queue(s) stay as it is.

2. We allow selecting the timer based on some flag, the default
   behaviour being the current default timer queue.

3. Then we add next_timer_interupt_critical() to only query the
   critical timers along the lines of the current next_timer_interrupt().

4. We implement a custom pm_idle that suspends the system based on
   some logic and checking if next_timer_interrupt_critical() is
   empty. If the next_timer_interrupt_critical() does not return
   anything, we assume it's OK to suspend the system.

Now to me it sounds if your the input layer and userspace handle
both grab the timers with the critical flags, it should be guaranteed
that the events get handled before the system is suspended.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > See feature-removal-schedule.txt. So far we have no indication that it's 
> > going to be replaced, because nobody has actually suggested a working 
> > way to do this better. If we had a concrete implementation proposal for 
> > that then we'd be in a pretty different position right now.
> 
> Ok, feature-removal-schedule.txt applies to everything tho. What your
> saying is that if this interface only last a short time it might take 6
> months, if it last for a long time it would take longer. There's no easy
> way to know that Google is the only user after some amount of time
> passes.

If the interface is there for a long time, it's because we haven't come 
up with anything better. And if we haven't come up with anything better, 
the interface deserves to be there.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > See feature-removal-schedule.txt. So far we have no indication that it's 
> > going to be replaced, because nobody has actually suggested a working 
> > way to do this better. If we had a concrete implementation proposal for 
> > that then we'd be in a pretty different position right now.
> 
> Ok, feature-removal-schedule.txt applies to everything tho. What your
> saying is that if this interface only last a short time it might take 6
> months, if it last for a long time it would take longer. There's no easy
> way to know that Google is the only user after some amount of time
> passes.

If the interface is there for a long time, it's because we haven't come 
up with anything better. And if we haven't come up with anything better, 
the interface deserves to be there.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote:

> 1. In the kernel, we add one more timer queue for critical timers.
>    The current timer queue(s) stay as it is.
> 
> 2. We allow selecting the timer based on some flag, the default
>    behaviour being the current default timer queue.
> 
> 3. Then we add next_timer_interupt_critical() to only query the
>    critical timers along the lines of the current next_timer_interrupt().
> 
> 4. We implement a custom pm_idle that suspends the system based on
>    some logic and checking if next_timer_interrupt_critical() is
>    empty. If the next_timer_interrupt_critical() does not return
>    anything, we assume it's OK to suspend the system.

Ok. So we stick the untrusted bits of userspace on the critical timer 
list. Now we get a network packet that generates a wakeup event and gets 
read by an application. What happens if that application can't fully 
process the packet in a single timeslice?

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote:

> 1. In the kernel, we add one more timer queue for critical timers.
>    The current timer queue(s) stay as it is.
> 
> 2. We allow selecting the timer based on some flag, the default
>    behaviour being the current default timer queue.
> 
> 3. Then we add next_timer_interupt_critical() to only query the
>    critical timers along the lines of the current next_timer_interrupt().
> 
> 4. We implement a custom pm_idle that suspends the system based on
>    some logic and checking if next_timer_interrupt_critical() is
>    empty. If the next_timer_interrupt_critical() does not return
>    anything, we assume it's OK to suspend the system.

Ok. So we stick the untrusted bits of userspace on the critical timer 
list. Now we get a network packet that generates a wakeup event and gets 
read by an application. What happens if that application can't fully 
process the packet in a single timeslice?

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 12:49]:
> On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote:
> 
> > 1. In the kernel, we add one more timer queue for critical timers.
> >    The current timer queue(s) stay as it is.
> > 
> > 2. We allow selecting the timer based on some flag, the default
> >    behaviour being the current default timer queue.
> > 
> > 3. Then we add next_timer_interupt_critical() to only query the
> >    critical timers along the lines of the current next_timer_interrupt().
> > 
> > 4. We implement a custom pm_idle that suspends the system based on
> >    some logic and checking if next_timer_interrupt_critical() is
> >    empty. If the next_timer_interrupt_critical() does not return
> >    anything, we assume it's OK to suspend the system.
> 
> Ok. So we stick the untrusted bits of userspace on the critical timer 
> list.

I guess you mean the trusted instead of untrusted apps in the userspace
above, the ones that are critical to keep running.

> Now we get a network packet that generates a wakeup event and gets 
> read by an application. What happens if that application can't fully 
> process the packet in a single timeslice?

The system stays running because there's something to do. The system
won't suspend until all the processors hit the kernel idle loop and
the next_timer_interrupt_critical() returns nothing.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 12:49]:
> On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote:
> 
> > 1. In the kernel, we add one more timer queue for critical timers.
> >    The current timer queue(s) stay as it is.
> > 
> > 2. We allow selecting the timer based on some flag, the default
> >    behaviour being the current default timer queue.
> > 
> > 3. Then we add next_timer_interupt_critical() to only query the
> >    critical timers along the lines of the current next_timer_interrupt().
> > 
> > 4. We implement a custom pm_idle that suspends the system based on
> >    some logic and checking if next_timer_interrupt_critical() is
> >    empty. If the next_timer_interrupt_critical() does not return
> >    anything, we assume it's OK to suspend the system.
> 
> Ok. So we stick the untrusted bits of userspace on the critical timer 
> list.

I guess you mean the trusted instead of untrusted apps in the userspace
above, the ones that are critical to keep running.

> Now we get a network packet that generates a wakeup event and gets 
> read by an application. What happens if that application can't fully 
> process the packet in a single timeslice?

The system stays running because there's something to do. The system
won't suspend until all the processors hit the kernel idle loop and
the next_timer_interrupt_critical() returns nothing.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:

> The system stays running because there's something to do. The system
> won't suspend until all the processors hit the kernel idle loop and
> the next_timer_interrupt_critical() returns nothing.

At which point an application in a busy loop cripples you. I think we 
could implement your suggestion more easily by just giving untrusted 
applications an effectively infinite amount of timer slack, but it still 
doesn't handle the case where an app behaves excrutiatingly badly.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:

> The system stays running because there's something to do. The system
> won't suspend until all the processors hit the kernel idle loop and
> the next_timer_interrupt_critical() returns nothing.

At which point an application in a busy loop cripples you. I think we 
could implement your suggestion more easily by just giving untrusted 
applications an effectively infinite amount of timer slack, but it still 
doesn't handle the case where an app behaves excrutiatingly badly.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> 
> > The system stays running because there's something to do. The system
> > won't suspend until all the processors hit the kernel idle loop and
> > the next_timer_interrupt_critical() returns nothing.
> 
> At which point an application in a busy loop cripples you.

Maybe you could deal with the misbehaving untrusted apps in the userspace
by sending kill -STOP to them when the screen blanks? Then continue
when some event wakes up the system again.

> I think we could implement your suggestion more easily by just giving
> untrusted applications an effectively infinite amount of timer slack,
> but it still doesn't handle the case where an app behaves excrutiatingly
> badly.

Hmm, if you use timer slack then you still need to search through
the whole timer list instead of a smaller critical timer list.
Both ways sound doable though.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> 
> > The system stays running because there's something to do. The system
> > won't suspend until all the processors hit the kernel idle loop and
> > the next_timer_interrupt_critical() returns nothing.
> 
> At which point an application in a busy loop cripples you.

Maybe you could deal with the misbehaving untrusted apps in the userspace
by sending kill -STOP to them when the screen blanks? Then continue
when some event wakes up the system again.

> I think we could implement your suggestion more easily by just giving
> untrusted applications an effectively infinite amount of timer slack,
> but it still doesn't handle the case where an app behaves excrutiatingly
> badly.

Hmm, if you use timer slack then you still need to search through
the whole timer list instead of a smaller critical timer list.
Both ways sound doable though.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > 
> > > The system stays running because there's something to do. The system
> > > won't suspend until all the processors hit the kernel idle loop and
> > > the next_timer_interrupt_critical() returns nothing.
> > 
> > At which point an application in a busy loop cripples you.
> 
> Maybe you could deal with the misbehaving untrusted apps in the userspace
> by sending kill -STOP to them when the screen blanks? Then continue
> when some event wakes up the system again.

And if that's the application that's listening to the network socket 
that you want to get a wakeup event from? This problem is hard. I'd love 
there to be an elegant solution based on using the scheduler, but I 
really don't know what it is.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > 
> > > The system stays running because there's something to do. The system
> > > won't suspend until all the processors hit the kernel idle loop and
> > > the next_timer_interrupt_critical() returns nothing.
> > 
> > At which point an application in a busy loop cripples you.
> 
> Maybe you could deal with the misbehaving untrusted apps in the userspace
> by sending kill -STOP to them when the screen blanks? Then continue
> when some event wakes up the system again.

And if that's the application that's listening to the network socket 
that you want to get a wakeup event from? This problem is hard. I'd love 
there to be an elegant solution based on using the scheduler, but I 
really don't know what it is.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > 
> > > The system stays running because there's something to do. The system
> > > won't suspend until all the processors hit the kernel idle loop and
> > > the next_timer_interrupt_critical() returns nothing.
> > 
> > At which point an application in a busy loop cripples you.
> 
> Maybe you could deal with the misbehaving untrusted apps in the userspace
> by sending kill -STOP to them when the screen blanks? Then continue
> when some event wakes up the system again.

Couldn't you just use priorities (nice), or cgroups to deal with that?
I'm sure there is a way to limit an apps runtime, so the system does go
idle sometimes.

> > I think we could implement your suggestion more easily by just giving
> > untrusted applications an effectively infinite amount of timer slack,
> > but it still doesn't handle the case where an app behaves excrutiatingly
> > badly.
> 
> Hmm, if you use timer slack then you still need to search through
> the whole timer list instead of a smaller critical timer list.
> Both ways sound doable though.

There are deferrable timers already in Linux.. It seems like it would
just be an extension of that.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > 
> > > The system stays running because there's something to do. The system
> > > won't suspend until all the processors hit the kernel idle loop and
> > > the next_timer_interrupt_critical() returns nothing.
> > 
> > At which point an application in a busy loop cripples you.
> 
> Maybe you could deal with the misbehaving untrusted apps in the userspace
> by sending kill -STOP to them when the screen blanks? Then continue
> when some event wakes up the system again.

Couldn't you just use priorities (nice), or cgroups to deal with that?
I'm sure there is a way to limit an apps runtime, so the system does go
idle sometimes.

> > I think we could implement your suggestion more easily by just giving
> > untrusted applications an effectively infinite amount of timer slack,
> > but it still doesn't handle the case where an app behaves excrutiatingly
> > badly.
> 
> Hmm, if you use timer slack then you still need to search through
> the whole timer list instead of a smaller critical timer list.
> Both ways sound doable though.

There are deferrable timers already in Linux.. It seems like it would
just be an extension of that.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > 
> > > > The system stays running because there's something to do. The system
> > > > won't suspend until all the processors hit the kernel idle loop and
> > > > the next_timer_interrupt_critical() returns nothing.
> > > 
> > > At which point an application in a busy loop cripples you.
> > 
> > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > by sending kill -STOP to them when the screen blanks? Then continue
> > when some event wakes up the system again.
> 
> And if that's the application that's listening to the network socket 
> that you want to get a wakeup event from? This problem is hard. I'd love 
> there to be an elegant solution based on using the scheduler, but I 
> really don't know what it is.

Your system should wake up to an interrupt in that case. Then you have
the trusted apps running that can decide if the untrusted apps should
be continued or not.

The key would be to have the basic apps behave and use the critical
timers as needed. The advantage is that then you can do all the
policy in the userspace and in a custom pm_idle function.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > 
> > > > The system stays running because there's something to do. The system
> > > > won't suspend until all the processors hit the kernel idle loop and
> > > > the next_timer_interrupt_critical() returns nothing.
> > > 
> > > At which point an application in a busy loop cripples you.
> > 
> > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > by sending kill -STOP to them when the screen blanks? Then continue
> > when some event wakes up the system again.
> 
> And if that's the application that's listening to the network socket 
> that you want to get a wakeup event from? This problem is hard. I'd love 
> there to be an elegant solution based on using the scheduler, but I 
> really don't know what it is.

Your system should wake up to an interrupt in that case. Then you have
the trusted apps running that can decide if the untrusted apps should
be continued or not.

The key would be to have the basic apps behave and use the critical
timers as needed. The advantage is that then you can do all the
policy in the userspace and in a custom pm_idle function.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > going to be replaced, because nobody has actually suggested a working 
> > > way to do this better. If we had a concrete implementation proposal for 
> > > that then we'd be in a pretty different position right now.
> > 
> > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > saying is that if this interface only last a short time it might take 6
> > months, if it last for a long time it would take longer. There's no easy
> > way to know that Google is the only user after some amount of time
> > passes.
> 
> If the interface is there for a long time, it's because we haven't come 
> up with anything better. And if we haven't come up with anything better, 
> the interface deserves to be there.

Moreover, the interface is already in use out-of-tree and that usage is
actually _growing_, so we have a growing number of out-of-tree drivers that
aren't megrgeable for this very reason.

I don't see any _realistic_ way of solving this problem other than merging
the opportunistic suspend.  If anyone sees one, and I mean _realistic_ and
_practically_ _feasible_, please tell me.

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > going to be replaced, because nobody has actually suggested a working 
> > > way to do this better. If we had a concrete implementation proposal for 
> > > that then we'd be in a pretty different position right now.
> > 
> > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > saying is that if this interface only last a short time it might take 6
> > months, if it last for a long time it would take longer. There's no easy
> > way to know that Google is the only user after some amount of time
> > passes.
> 
> If the interface is there for a long time, it's because we haven't come 
> up with anything better. And if we haven't come up with anything better, 
> the interface deserves to be there.

Moreover, the interface is already in use out-of-tree and that usage is
actually _growing_, so we have a growing number of out-of-tree drivers that
aren't megrgeable for this very reason.

I don't see any _realistic_ way of solving this problem other than merging
the opportunistic suspend.  If anyone sees one, and I mean _realistic_ and
_practically_ _feasible_, please tell me.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> > On Wed, 12 May 2010, Paul Walmsley wrote:
> > 
> > > Hello,
> > > 
> > > Some general comments on the suspend blockers/wakelock/opportunistic
> > > suspend v6 patch series, posted here:
> > > 
> > >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > > 
> > > The comments below are somewhat telegraphic in the interests of 
> > > readability - more specific comments to follow in later E-mails. I am 
> > > indebted to those of us who discussed these issues at LPC last year and 
> > > ELC this year for several stimulating discussions.
> > > 
> > > There are several general problems with the design of opportunistic
> > > suspend and suspend-blocks.
> > > 
> > > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> > >    such as timers and the scheduler, that indicates when code
> > >    needs to run, and when the system is idle.
> > 
> > Whoa!  That's not my understanding at all.
> > 
> > As I see it, opportunistic suspend doesn't bypass any code that isn't 
> > already bypassed by the existing suspend code.  Users can do
> > 
> > 	echo mem >/sys/power/state
> > 
> > whenever they want, without regard to kernel timers and the scheduler 
> > (other than the fact that the user's thread must be running in order to 
> > carry out the write, of course).
> 
> The difference between echo mem > /sys/power/state and suspend blocks
> is that with suspend blocks the system keeps running.

Care to elaborate?

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> > On Wed, 12 May 2010, Paul Walmsley wrote:
> > 
> > > Hello,
> > > 
> > > Some general comments on the suspend blockers/wakelock/opportunistic
> > > suspend v6 patch series, posted here:
> > > 
> > >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > > 
> > > The comments below are somewhat telegraphic in the interests of 
> > > readability - more specific comments to follow in later E-mails. I am 
> > > indebted to those of us who discussed these issues at LPC last year and 
> > > ELC this year for several stimulating discussions.
> > > 
> > > There are several general problems with the design of opportunistic
> > > suspend and suspend-blocks.
> > > 
> > > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> > >    such as timers and the scheduler, that indicates when code
> > >    needs to run, and when the system is idle.
> > 
> > Whoa!  That's not my understanding at all.
> > 
> > As I see it, opportunistic suspend doesn't bypass any code that isn't 
> > already bypassed by the existing suspend code.  Users can do
> > 
> > 	echo mem >/sys/power/state
> > 
> > whenever they want, without regard to kernel timers and the scheduler 
> > (other than the fact that the user's thread must be running in order to 
> > carry out the write, of course).
> 
> The difference between echo mem > /sys/power/state and suspend blocks
> is that with suspend blocks the system keeps running.

Care to elaborate?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote:
> On Thursday 13 May 2010, Matthew Garrett wrote:
> > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > > going to be replaced, because nobody has actually suggested a working 
> > > > way to do this better. If we had a concrete implementation proposal for 
> > > > that then we'd be in a pretty different position right now.
> > > 
> > > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > > saying is that if this interface only last a short time it might take 6
> > > months, if it last for a long time it would take longer. There's no easy
> > > way to know that Google is the only user after some amount of time
> > > passes.
> > 
> > If the interface is there for a long time, it's because we haven't come 
> > up with anything better. And if we haven't come up with anything better, 
> > the interface deserves to be there.
> 
> Moreover, the interface is already in use out-of-tree and that usage is
> actually _growing_, so we have a growing number of out-of-tree drivers that
> aren't megrgeable for this very reason.

Why can't we merge the drivers? Drivers are just drivers, they don't
need this to get merged. (They need it to work with Android)

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote:
> On Thursday 13 May 2010, Matthew Garrett wrote:
> > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > > going to be replaced, because nobody has actually suggested a working 
> > > > way to do this better. If we had a concrete implementation proposal for 
> > > > that then we'd be in a pretty different position right now.
> > > 
> > > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > > saying is that if this interface only last a short time it might take 6
> > > months, if it last for a long time it would take longer. There's no easy
> > > way to know that Google is the only user after some amount of time
> > > passes.
> > 
> > If the interface is there for a long time, it's because we haven't come 
> > up with anything better. And if we haven't come up with anything better, 
> > the interface deserves to be there.
> 
> Moreover, the interface is already in use out-of-tree and that usage is
> actually _growing_, so we have a growing number of out-of-tree drivers that
> aren't megrgeable for this very reason.

Why can't we merge the drivers? Drivers are just drivers, they don't
need this to get merged. (They need it to work with Android)

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> > And if that's the application that's listening to the network socket 
> > that you want to get a wakeup event from? This problem is hard. I'd love 
> > there to be an elegant solution based on using the scheduler, but I 
> > really don't know what it is.
> 
> Your system should wake up to an interrupt in that case. Then you have
> the trusted apps running that can decide if the untrusted apps should
> be continued or not.

What race-free mechanism do you use to ensure that? It's very easy to 
handwave these problems away. It's very difficult to actually write an 
implementation that works.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> > And if that's the application that's listening to the network socket 
> > that you want to get a wakeup event from? This problem is hard. I'd love 
> > there to be an elegant solution based on using the scheduler, but I 
> > really don't know what it is.
> 
> Your system should wake up to an interrupt in that case. Then you have
> the trusted apps running that can decide if the untrusted apps should
> be continued or not.

What race-free mechanism do you use to ensure that? It's very easy to 
handwave these problems away. It's very difficult to actually write an 
implementation that works.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > 
> > > > The system stays running because there's something to do. The system
> > > > won't suspend until all the processors hit the kernel idle loop and
> > > > the next_timer_interrupt_critical() returns nothing.
> > > 
> > > At which point an application in a busy loop cripples you.
> > 
> > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > by sending kill -STOP to them when the screen blanks? Then continue
> > when some event wakes up the system again.
> 
> And if that's the application that's listening to the network socket 
> that you want to get a wakeup event from? This problem is hard. I'd love 
> there to be an elegant solution based on using the scheduler, but I 
> really don't know what it is.

I agree and I don't understand the problem that people have with the
opportunistic suspend feature.

It solves a practical issue that _at_ _the_ _moment_ cannot be solved
differently, while there's a growing number of out-of-tree drivers depending
on this framework.  We need those drivers in and because we don't have any
viable alternative at hand, we have no good reason to reject it.

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > 
> > > > The system stays running because there's something to do. The system
> > > > won't suspend until all the processors hit the kernel idle loop and
> > > > the next_timer_interrupt_critical() returns nothing.
> > > 
> > > At which point an application in a busy loop cripples you.
> > 
> > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > by sending kill -STOP to them when the screen blanks? Then continue
> > when some event wakes up the system again.
> 
> And if that's the application that's listening to the network socket 
> that you want to get a wakeup event from? This problem is hard. I'd love 
> there to be an elegant solution based on using the scheduler, but I 
> really don't know what it is.

I agree and I don't understand the problem that people have with the
opportunistic suspend feature.

It solves a practical issue that _at_ _the_ _moment_ cannot be solved
differently, while there's a growing number of out-of-tree drivers depending
on this framework.  We need those drivers in and because we don't have any
viable alternative at hand, we have no good reason to reject it.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> On Thursday 13 May 2010, Matthew Garrett wrote:
> > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > > 
> > > > > The system stays running because there's something to do. The system
> > > > > won't suspend until all the processors hit the kernel idle loop and
> > > > > the next_timer_interrupt_critical() returns nothing.
> > > > 
> > > > At which point an application in a busy loop cripples you.
> > > 
> > > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > > by sending kill -STOP to them when the screen blanks? Then continue
> > > when some event wakes up the system again.
> > 
> > And if that's the application that's listening to the network socket 
> > that you want to get a wakeup event from? This problem is hard. I'd love 
> > there to be an elegant solution based on using the scheduler, but I 
> > really don't know what it is.
> 
> I agree and I don't understand the problem that people have with the
> opportunistic suspend feature.

It seems to be picking quite a few comments for one.
 
> It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> differently, while there's a growing number of out-of-tree drivers depending
> on this framework.  We need those drivers in and because we don't have any
> viable alternative at hand, we have no good reason to reject it.

Nothing is preventing merging the drivers can be merged without
these calls.

Regards,

Tony

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

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> On Thursday 13 May 2010, Matthew Garrett wrote:
> > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > > 
> > > > > The system stays running because there's something to do. The system
> > > > > won't suspend until all the processors hit the kernel idle loop and
> > > > > the next_timer_interrupt_critical() returns nothing.
> > > > 
> > > > At which point an application in a busy loop cripples you.
> > > 
> > > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > > by sending kill -STOP to them when the screen blanks? Then continue
> > > when some event wakes up the system again.
> > 
> > And if that's the application that's listening to the network socket 
> > that you want to get a wakeup event from? This problem is hard. I'd love 
> > there to be an elegant solution based on using the scheduler, but I 
> > really don't know what it is.
> 
> I agree and I don't understand the problem that people have with the
> opportunistic suspend feature.

It seems to be picking quite a few comments for one.
 
> It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> differently, while there's a growing number of out-of-tree drivers depending
> on this framework.  We need those drivers in and because we don't have any
> viable alternative at hand, we have no good reason to reject it.

Nothing is preventing merging the drivers can be merged without
these calls.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Daniel Walker wrote:
> On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote:
> > On Thursday 13 May 2010, Matthew Garrett wrote:
> > > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > > > going to be replaced, because nobody has actually suggested a working 
> > > > > way to do this better. If we had a concrete implementation proposal for 
> > > > > that then we'd be in a pretty different position right now.
> > > > 
> > > > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > > > saying is that if this interface only last a short time it might take 6
> > > > months, if it last for a long time it would take longer. There's no easy
> > > > way to know that Google is the only user after some amount of time
> > > > passes.
> > > 
> > > If the interface is there for a long time, it's because we haven't come 
> > > up with anything better. And if we haven't come up with anything better, 
> > > the interface deserves to be there.
> > 
> > Moreover, the interface is already in use out-of-tree and that usage is
> > actually _growing_, so we have a growing number of out-of-tree drivers that
> > aren't megrgeable for this very reason.
> 
> Why can't we merge the drivers? Drivers are just drivers, they don't
> need this to get merged. (They need it to work with Android)

Because someone would have to remove suspend blockers (or rather wakelocks)
from the drivers, test that they work correctly without suspend blockers and
submit the modified versions.  Going forward, every party responsible for such
a driver would have to maintain an out-of-tree version with suspend blockers
(or wakelocks) anyway, so the incentive to do that is zero.

Practically, as long as the opportunistic suspend is out of tree, there will be
a _growing_ number of out-of-tree drivers out there, which is not acceptable
in the long run.

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Daniel Walker wrote:
> On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote:
> > On Thursday 13 May 2010, Matthew Garrett wrote:
> > > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> > > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > > > > See feature-removal-schedule.txt. So far we have no indication that it's 
> > > > > going to be replaced, because nobody has actually suggested a working 
> > > > > way to do this better. If we had a concrete implementation proposal for 
> > > > > that then we'd be in a pretty different position right now.
> > > > 
> > > > Ok, feature-removal-schedule.txt applies to everything tho. What your
> > > > saying is that if this interface only last a short time it might take 6
> > > > months, if it last for a long time it would take longer. There's no easy
> > > > way to know that Google is the only user after some amount of time
> > > > passes.
> > > 
> > > If the interface is there for a long time, it's because we haven't come 
> > > up with anything better. And if we haven't come up with anything better, 
> > > the interface deserves to be there.
> > 
> > Moreover, the interface is already in use out-of-tree and that usage is
> > actually _growing_, so we have a growing number of out-of-tree drivers that
> > aren't megrgeable for this very reason.
> 
> Why can't we merge the drivers? Drivers are just drivers, they don't
> need this to get merged. (They need it to work with Android)

Because someone would have to remove suspend blockers (or rather wakelocks)
from the drivers, test that they work correctly without suspend blockers and
submit the modified versions.  Going forward, every party responsible for such
a driver would have to maintain an out-of-tree version with suspend blockers
(or wakelocks) anyway, so the incentive to do that is zero.

Practically, as long as the opportunistic suspend is out of tree, there will be
a _growing_ number of out-of-tree drivers out there, which is not acceptable
in the long run.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100513 14:08]:
> On Thursday 13 May 2010, Tony Lindgren wrote:
> > 
> > The difference between echo mem > /sys/power/state and suspend blocks
> > is that with suspend blocks the system keeps running.
> 
> Care to elaborate?

The suspend blocks affects the runtime behaviour of the system by
categorizing apps into good and bad apps in a weird way.

Tony

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

[Tony Lindgren]

* Rafael J. Wysocki <rjw@sisk.pl> [100513 14:08]:
> On Thursday 13 May 2010, Tony Lindgren wrote:
> > 
> > The difference between echo mem > /sys/power/state and suspend blocks
> > is that with suspend blocks the system keeps running.
> 
> Care to elaborate?

The suspend blocks affects the runtime behaviour of the system by
categorizing apps into good and bad apps in a weird way.

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:

> Because someone would have to remove suspend blockers (or rather wakelocks)
> from the drivers, test that they work correctly without suspend blockers and
> submit the modified versions.  Going forward, every party responsible for such
> a driver would have to maintain an out-of-tree version with suspend blockers
> (or wakelocks) anyway, so the incentive to do that is zero.

They should work without wakelock since wakelock are optional .. I mean
there's nothing in suspend blockers I've seen that indicates it's
required for some drivers to work. So it's just a matter of patching out
the wakelocks, with no need to re-test anything.

You get the driver mainlined, then maintain a small patch to add
wakelocks. Not hard at all , with lots of incentive to do so since you
don't have to maintain such a large block of code out of tree.

> Practically, as long as the opportunistic suspend is out of tree, there will be
> a _growing_ number of out-of-tree drivers out there, which is not acceptable
> in the long run.

I don't see why your saying that. These driver should work with out all
of this, which means they can get mainlined right now.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:

> Because someone would have to remove suspend blockers (or rather wakelocks)
> from the drivers, test that they work correctly without suspend blockers and
> submit the modified versions.  Going forward, every party responsible for such
> a driver would have to maintain an out-of-tree version with suspend blockers
> (or wakelocks) anyway, so the incentive to do that is zero.

They should work without wakelock since wakelock are optional .. I mean
there's nothing in suspend blockers I've seen that indicates it's
required for some drivers to work. So it's just a matter of patching out
the wakelocks, with no need to re-test anything.

You get the driver mainlined, then maintain a small patch to add
wakelocks. Not hard at all , with lots of incentive to do so since you
don't have to maintain such a large block of code out of tree.

> Practically, as long as the opportunistic suspend is out of tree, there will be
> a _growing_ number of out-of-tree drivers out there, which is not acceptable
> in the long run.

I don't see why your saying that. These driver should work with out all
of this, which means they can get mainlined right now.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 14:16]:
> On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> > > And if that's the application that's listening to the network socket 
> > > that you want to get a wakeup event from? This problem is hard. I'd love 
> > > there to be an elegant solution based on using the scheduler, but I 
> > > really don't know what it is.
> > 
> > Your system should wake up to an interrupt in that case. Then you have
> > the trusted apps running that can decide if the untrusted apps should
> > be continued or not.
> 
> What race-free mechanism do you use to ensure that? It's very easy to 
> handwave these problems away. It's very difficult to actually write an 
> implementation that works.

Can you describe where do you see the race now?

Your trusted apps should be have in quite a normal way except the system
suspends if no critical timers are on the list. For the untrusted apps
you assume you can stop them at whatever userspace policy you set.

Regards,

Tony

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

[Tony Lindgren]

* Matthew Garrett <mjg@redhat.com> [100513 14:16]:
> On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@redhat.com> [100513 13:29]:
> > > And if that's the application that's listening to the network socket 
> > > that you want to get a wakeup event from? This problem is hard. I'd love 
> > > there to be an elegant solution based on using the scheduler, but I 
> > > really don't know what it is.
> > 
> > Your system should wake up to an interrupt in that case. Then you have
> > the trusted apps running that can decide if the untrusted apps should
> > be continued or not.
> 
> What race-free mechanism do you use to ensure that? It's very easy to 
> handwave these problems away. It's very difficult to actually write an 
> implementation that works.

Can you describe where do you see the race now?

Your trusted apps should be have in quite a normal way except the system
suspends if no critical timers are on the list. For the untrusted apps
you assume you can stop them at whatever userspace policy you set.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100513 14:28]:
> On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> 
> > Because someone would have to remove suspend blockers (or rather wakelocks)
> > from the drivers, test that they work correctly without suspend blockers and
> > submit the modified versions.  Going forward, every party responsible for such
> > a driver would have to maintain an out-of-tree version with suspend blockers
> > (or wakelocks) anyway, so the incentive to do that is zero.
> 
> They should work without wakelock since wakelock are optional .. I mean
> there's nothing in suspend blockers I've seen that indicates it's
> required for some drivers to work. So it's just a matter of patching out
> the wakelocks, with no need to re-test anything.
> 
> You get the driver mainlined, then maintain a small patch to add
> wakelocks. Not hard at all , with lots of incentive to do so since you
> don't have to maintain such a large block of code out of tree.
> 
> > Practically, as long as the opportunistic suspend is out of tree, there will be
> > a _growing_ number of out-of-tree drivers out there, which is not acceptable
> > in the long run.
> 
> I don't see why your saying that. These driver should work with out all
> of this, which means they can get mainlined right now.

I agree with Daniel here. We should keep merging the drivers separate
from the suspend blocks issues.

Regards,

Tony

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

[Tony Lindgren]

* Daniel Walker <dwalker@fifo99.com> [100513 14:28]:
> On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> 
> > Because someone would have to remove suspend blockers (or rather wakelocks)
> > from the drivers, test that they work correctly without suspend blockers and
> > submit the modified versions.  Going forward, every party responsible for such
> > a driver would have to maintain an out-of-tree version with suspend blockers
> > (or wakelocks) anyway, so the incentive to do that is zero.
> 
> They should work without wakelock since wakelock are optional .. I mean
> there's nothing in suspend blockers I've seen that indicates it's
> required for some drivers to work. So it's just a matter of patching out
> the wakelocks, with no need to re-test anything.
> 
> You get the driver mainlined, then maintain a small patch to add
> wakelocks. Not hard at all , with lots of incentive to do so since you
> don't have to maintain such a large block of code out of tree.
> 
> > Practically, as long as the opportunistic suspend is out of tree, there will be
> > a _growing_ number of out-of-tree drivers out there, which is not acceptable
> > in the long run.
> 
> I don't see why your saying that. These driver should work with out all
> of this, which means they can get mainlined right now.

I agree with Daniel here. We should keep merging the drivers separate
from the suspend blocks issues.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> * Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> > On Wed, 12 May 2010, Paul Walmsley wrote:
> > 
> > > Hello,
> > > 
> > > Some general comments on the suspend blockers/wakelock/opportunistic
> > > suspend v6 patch series, posted here:
> > > 
> > >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > > 
> > > The comments below are somewhat telegraphic in the interests of 
> > > readability - more specific comments to follow in later E-mails. I am 
> > > indebted to those of us who discussed these issues at LPC last year and 
> > > ELC this year for several stimulating discussions.
> > > 
> > > There are several general problems with the design of opportunistic
> > > suspend and suspend-blocks.
> > > 
> > > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> > >    such as timers and the scheduler, that indicates when code
> > >    needs to run, and when the system is idle.
> > 
> > Whoa!  That's not my understanding at all.
> > 
> > As I see it, opportunistic suspend doesn't bypass any code that isn't 
> > already bypassed by the existing suspend code.  Users can do
> > 
> > 	echo mem >/sys/power/state
> > 
> > whenever they want, without regard to kernel timers and the scheduler 
> > (other than the fact that the user's thread must be running in order to 
> > carry out the write, of course).
> 
> The difference between echo mem > /sys/power/state and suspend blocks
> is that with suspend blocks the system keeps running.

Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
talking about opportunistic suspend.  So what's the difference between 
opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
when suspend blockers aren't being used?

> And that's why 
> it should be handled by runtime power management instead.

Runtime PM is not capable of freezing userspace and shutting down CPUs.  
More or less by definition -- if it could then it wouldn't be "runtime" 
any more, since the processor wouldn't be running.

> The suspend blocks seems like a hack to spam filter good and bad
> apps from timer usage point of view. Applications are categorized
> as good or bad depending if they grab a susped blocker or not.

You're referring just to the userspace part of the suspend blocker 
API.  What about the kernel part?

> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

That would be compatible with using suspend blockers.

Alan Stern

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

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> * Alan Stern <stern@rowland.harvard.edu> [100513 07:11]:
> > On Wed, 12 May 2010, Paul Walmsley wrote:
> > 
> > > Hello,
> > > 
> > > Some general comments on the suspend blockers/wakelock/opportunistic
> > > suspend v6 patch series, posted here:
> > > 
> > >     https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > > 
> > > The comments below are somewhat telegraphic in the interests of 
> > > readability - more specific comments to follow in later E-mails. I am 
> > > indebted to those of us who discussed these issues at LPC last year and 
> > > ELC this year for several stimulating discussions.
> > > 
> > > There are several general problems with the design of opportunistic
> > > suspend and suspend-blocks.
> > > 
> > > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> > >    such as timers and the scheduler, that indicates when code
> > >    needs to run, and when the system is idle.
> > 
> > Whoa!  That's not my understanding at all.
> > 
> > As I see it, opportunistic suspend doesn't bypass any code that isn't 
> > already bypassed by the existing suspend code.  Users can do
> > 
> > 	echo mem >/sys/power/state
> > 
> > whenever they want, without regard to kernel timers and the scheduler 
> > (other than the fact that the user's thread must be running in order to 
> > carry out the write, of course).
> 
> The difference between echo mem > /sys/power/state and suspend blocks
> is that with suspend blocks the system keeps running.

Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
talking about opportunistic suspend.  So what's the difference between 
opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
when suspend blockers aren't being used?

> And that's why 
> it should be handled by runtime power management instead.

Runtime PM is not capable of freezing userspace and shutting down CPUs.  
More or less by definition -- if it could then it wouldn't be "runtime" 
any more, since the processor wouldn't be running.

> The suspend blocks seems like a hack to spam filter good and bad
> apps from timer usage point of view. Applications are categorized
> as good or bad depending if they grab a susped blocker or not.

You're referring just to the userspace part of the suspend blocker 
API.  What about the kernel part?

> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

That would be compatible with using suspend blockers.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> Well this is an interesting problem, and once solved will be handy
> for all kind of things. My worry is that if it's integrated in it's
> current form it will be totally out of control all over the place :(
> 
> Still hoping we can come up with some clean way that avoid the patching
> all over the place part.. How about the following, can you please check
> if it would help with your example of guaranteed handling of event:
> 
> 1. In the kernel, we add one more timer queue for critical timers.
>    The current timer queue(s) stay as it is.
> 
> 2. We allow selecting the timer based on some flag, the default
>    behaviour being the current default timer queue.
> 
> 3. Then we add next_timer_interupt_critical() to only query the
>    critical timers along the lines of the current next_timer_interrupt().
> 
> 4. We implement a custom pm_idle that suspends the system based on
>    some logic and checking if next_timer_interrupt_critical() is
>    empty. If the next_timer_interrupt_critical() does not return
>    anything, we assume it's OK to suspend the system.
> 
> Now to me it sounds if your the input layer and userspace handle
> both grab the timers with the critical flags, it should be guaranteed
> that the events get handled before the system is suspended.

Why do you want this to be tied to timers?  Many of the events in 
question are asynchronous with no specific timing relations.

Alan Stern

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

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> Well this is an interesting problem, and once solved will be handy
> for all kind of things. My worry is that if it's integrated in it's
> current form it will be totally out of control all over the place :(
> 
> Still hoping we can come up with some clean way that avoid the patching
> all over the place part.. How about the following, can you please check
> if it would help with your example of guaranteed handling of event:
> 
> 1. In the kernel, we add one more timer queue for critical timers.
>    The current timer queue(s) stay as it is.
> 
> 2. We allow selecting the timer based on some flag, the default
>    behaviour being the current default timer queue.
> 
> 3. Then we add next_timer_interupt_critical() to only query the
>    critical timers along the lines of the current next_timer_interrupt().
> 
> 4. We implement a custom pm_idle that suspends the system based on
>    some logic and checking if next_timer_interrupt_critical() is
>    empty. If the next_timer_interrupt_critical() does not return
>    anything, we assume it's OK to suspend the system.
> 
> Now to me it sounds if your the input layer and userspace handle
> both grab the timers with the critical flags, it should be guaranteed
> that the events get handled before the system is suspended.

Why do you want this to be tied to timers?  Many of the events in 
question are asynchronous with no specific timing relations.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Greg KH]

On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> 
> > Because someone would have to remove suspend blockers (or rather wakelocks)
> > from the drivers, test that they work correctly without suspend blockers and
> > submit the modified versions.  Going forward, every party responsible for such
> > a driver would have to maintain an out-of-tree version with suspend blockers
> > (or wakelocks) anyway, so the incentive to do that is zero.
> 
> They should work without wakelock since wakelock are optional .. I mean
> there's nothing in suspend blockers I've seen that indicates it's
> required for some drivers to work. So it's just a matter of patching out
> the wakelocks, with no need to re-test anything.
> 
> You get the driver mainlined, then maintain a small patch to add
> wakelocks. Not hard at all , with lots of incentive to do so since you
> don't have to maintain such a large block of code out of tree.

Sorry, but it doesn't seem to work that way.  Look at the large number
of out-of-tree android device drivers that remain sitting there because
of the lack of this interface being in the kernel.

Also note that such a driver, without wakelocks, would never get tested,
and so, things start quickly diverging.

thanks,

greg k-h

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

[Greg KH]

On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> 
> > Because someone would have to remove suspend blockers (or rather wakelocks)
> > from the drivers, test that they work correctly without suspend blockers and
> > submit the modified versions.  Going forward, every party responsible for such
> > a driver would have to maintain an out-of-tree version with suspend blockers
> > (or wakelocks) anyway, so the incentive to do that is zero.
> 
> They should work without wakelock since wakelock are optional .. I mean
> there's nothing in suspend blockers I've seen that indicates it's
> required for some drivers to work. So it's just a matter of patching out
> the wakelocks, with no need to re-test anything.
> 
> You get the driver mainlined, then maintain a small patch to add
> wakelocks. Not hard at all , with lots of incentive to do so since you
> don't have to maintain such a large block of code out of tree.

Sorry, but it doesn't seem to work that way.  Look at the large number
of out-of-tree android device drivers that remain sitting there because
of the lack of this interface being in the kernel.

Also note that such a driver, without wakelocks, would never get tested,
and so, things start quickly diverging.

thanks,

greg k-h

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > The difference between echo mem > /sys/power/state and suspend blocks
> > is that with suspend blocks the system keeps running.
> 
> Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
> talking about opportunistic suspend.  So what's the difference between 
> opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
> when suspend blockers aren't being used?

Opportunistic suspend is really trying to do runtime PM, see below.
 
> > And that's why 
> > it should be handled by runtime power management instead.
> 
> Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> More or less by definition -- if it could then it wouldn't be "runtime" 
> any more, since the processor wouldn't be running.

Not true. We are already powering off CPUs and rebooting them for
at least omaps in every idle loop using cpuidle. The memory stays on.
 
> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
> 
> You're referring just to the userspace part of the suspend blocker 
> API.  What about the kernel part?

IMHO some timer flags should be used in the kernel too. Currently
there's no way of knowing which timers are good or bad from suspend
point of view.

Regards,

Tony 

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

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > The difference between echo mem > /sys/power/state and suspend blocks
> > is that with suspend blocks the system keeps running.
> 
> Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
> talking about opportunistic suspend.  So what's the difference between 
> opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
> when suspend blockers aren't being used?

Opportunistic suspend is really trying to do runtime PM, see below.
 
> > And that's why 
> > it should be handled by runtime power management instead.
> 
> Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> More or less by definition -- if it could then it wouldn't be "runtime" 
> any more, since the processor wouldn't be running.

Not true. We are already powering off CPUs and rebooting them for
at least omaps in every idle loop using cpuidle. The memory stays on.
 
> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
> 
> You're referring just to the userspace part of the suspend blocker 
> API.  What about the kernel part?

IMHO some timer flags should be used in the kernel too. Currently
there's no way of knowing which timers are good or bad from suspend
point of view.

Regards,

Tony 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:36]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > Well this is an interesting problem, and once solved will be handy
> > for all kind of things. My worry is that if it's integrated in it's
> > current form it will be totally out of control all over the place :(
> > 
> > Still hoping we can come up with some clean way that avoid the patching
> > all over the place part.. How about the following, can you please check
> > if it would help with your example of guaranteed handling of event:
> > 
> > 1. In the kernel, we add one more timer queue for critical timers.
> >    The current timer queue(s) stay as it is.
> > 
> > 2. We allow selecting the timer based on some flag, the default
> >    behaviour being the current default timer queue.
> > 
> > 3. Then we add next_timer_interupt_critical() to only query the
> >    critical timers along the lines of the current next_timer_interrupt().
> > 
> > 4. We implement a custom pm_idle that suspends the system based on
> >    some logic and checking if next_timer_interrupt_critical() is
> >    empty. If the next_timer_interrupt_critical() does not return
> >    anything, we assume it's OK to suspend the system.
> > 
> > Now to me it sounds if your the input layer and userspace handle
> > both grab the timers with the critical flags, it should be guaranteed
> > that the events get handled before the system is suspended.
> 
> Why do you want this to be tied to timers?  Many of the events in 
> question are asynchronous with no specific timing relations.

To me it seems that the non-timer related events can be dealt
with toggling the opportunistic suspend idle flag in sysfs.
That should depend on the device and use specific policy.

Tony

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

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:36]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > Well this is an interesting problem, and once solved will be handy
> > for all kind of things. My worry is that if it's integrated in it's
> > current form it will be totally out of control all over the place :(
> > 
> > Still hoping we can come up with some clean way that avoid the patching
> > all over the place part.. How about the following, can you please check
> > if it would help with your example of guaranteed handling of event:
> > 
> > 1. In the kernel, we add one more timer queue for critical timers.
> >    The current timer queue(s) stay as it is.
> > 
> > 2. We allow selecting the timer based on some flag, the default
> >    behaviour being the current default timer queue.
> > 
> > 3. Then we add next_timer_interupt_critical() to only query the
> >    critical timers along the lines of the current next_timer_interrupt().
> > 
> > 4. We implement a custom pm_idle that suspends the system based on
> >    some logic and checking if next_timer_interrupt_critical() is
> >    empty. If the next_timer_interrupt_critical() does not return
> >    anything, we assume it's OK to suspend the system.
> > 
> > Now to me it sounds if your the input layer and userspace handle
> > both grab the timers with the critical flags, it should be guaranteed
> > that the events get handled before the system is suspended.
> 
> Why do you want this to be tied to timers?  Many of the events in 
> question are asynchronous with no specific timing relations.

To me it seems that the non-timer related events can be dealt
with toggling the opportunistic suspend idle flag in sysfs.
That should depend on the device and use specific policy.

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Daniel Walker <dwalker@fifo99.com> [100513 14:28]:
> > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> > 
> > > Because someone would have to remove suspend blockers (or rather wakelocks)
> > > from the drivers, test that they work correctly without suspend blockers and
> > > submit the modified versions.  Going forward, every party responsible for such
> > > a driver would have to maintain an out-of-tree version with suspend blockers
> > > (or wakelocks) anyway, so the incentive to do that is zero.
> > 
> > They should work without wakelock since wakelock are optional .. I mean
> > there's nothing in suspend blockers I've seen that indicates it's
> > required for some drivers to work. So it's just a matter of patching out
> > the wakelocks, with no need to re-test anything.
> > 
> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.
> > 
> > > Practically, as long as the opportunistic suspend is out of tree, there will be
> > > a _growing_ number of out-of-tree drivers out there, which is not acceptable
> > > in the long run.
> > 
> > I don't see why your saying that. These driver should work with out all
> > of this, which means they can get mainlined right now.
> 
> I agree with Daniel here. We should keep merging the drivers separate
> from the suspend blocks issues.

Unfortunately, that's completely unrealistic.  Please refer to the Greg's reply
for details.

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Daniel Walker <dwalker@fifo99.com> [100513 14:28]:
> > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> > 
> > > Because someone would have to remove suspend blockers (or rather wakelocks)
> > > from the drivers, test that they work correctly without suspend blockers and
> > > submit the modified versions.  Going forward, every party responsible for such
> > > a driver would have to maintain an out-of-tree version with suspend blockers
> > > (or wakelocks) anyway, so the incentive to do that is zero.
> > 
> > They should work without wakelock since wakelock are optional .. I mean
> > there's nothing in suspend blockers I've seen that indicates it's
> > required for some drivers to work. So it's just a matter of patching out
> > the wakelocks, with no need to re-test anything.
> > 
> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.
> > 
> > > Practically, as long as the opportunistic suspend is out of tree, there will be
> > > a _growing_ number of out-of-tree drivers out there, which is not acceptable
> > > in the long run.
> > 
> > I don't see why your saying that. These driver should work with out all
> > of this, which means they can get mainlined right now.
> 
> I agree with Daniel here. We should keep merging the drivers separate
> from the suspend blocks issues.

Unfortunately, that's completely unrealistic.  Please refer to the Greg's reply
for details.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> > On Thursday 13 May 2010, Matthew Garrett wrote:
> > > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > > > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > > > 
> > > > > > The system stays running because there's something to do. The system
> > > > > > won't suspend until all the processors hit the kernel idle loop and
> > > > > > the next_timer_interrupt_critical() returns nothing.
> > > > > 
> > > > > At which point an application in a busy loop cripples you.
> > > > 
> > > > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > > > by sending kill -STOP to them when the screen blanks? Then continue
> > > > when some event wakes up the system again.
> > > 
> > > And if that's the application that's listening to the network socket 
> > > that you want to get a wakeup event from? This problem is hard. I'd love 
> > > there to be an elegant solution based on using the scheduler, but I 
> > > really don't know what it is.
> > 
> > I agree and I don't understand the problem that people have with the
> > opportunistic suspend feature.
> 
> It seems to be picking quite a few comments for one.
>  
> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> > differently, while there's a growing number of out-of-tree drivers depending
> > on this framework.  We need those drivers in and because we don't have any
> > viable alternative at hand, we have no good reason to reject it.
> 
> Nothing is preventing merging the drivers can be merged without
> these calls.

And yet, there _is_ a growing nuber of drivers that don't get merge because
of that.  That's _reality_.  Are you going to discuss with facts, or what?

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> > On Thursday 13 May 2010, Matthew Garrett wrote:
> > > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > > > * Matthew Garrett <mjg@redhat.com> [100513 13:03]:
> > > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > > > > 
> > > > > > The system stays running because there's something to do. The system
> > > > > > won't suspend until all the processors hit the kernel idle loop and
> > > > > > the next_timer_interrupt_critical() returns nothing.
> > > > > 
> > > > > At which point an application in a busy loop cripples you.
> > > > 
> > > > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > > > by sending kill -STOP to them when the screen blanks? Then continue
> > > > when some event wakes up the system again.
> > > 
> > > And if that's the application that's listening to the network socket 
> > > that you want to get a wakeup event from? This problem is hard. I'd love 
> > > there to be an elegant solution based on using the scheduler, but I 
> > > really don't know what it is.
> > 
> > I agree and I don't understand the problem that people have with the
> > opportunistic suspend feature.
> 
> It seems to be picking quite a few comments for one.
>  
> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> > differently, while there's a growing number of out-of-tree drivers depending
> > on this framework.  We need those drivers in and because we don't have any
> > viable alternative at hand, we have no good reason to reject it.
> 
> Nothing is preventing merging the drivers can be merged without
> these calls.

And yet, there _is_ a growing nuber of drivers that don't get merge because
of that.  That's _reality_.  Are you going to discuss with facts, or what?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:08]:
> > On Thursday 13 May 2010, Tony Lindgren wrote:
> > > 
> > > The difference between echo mem > /sys/power/state and suspend blocks
> > > is that with suspend blocks the system keeps running.
> > 
> > Care to elaborate?
> 
> The suspend blocks affects the runtime behaviour of the system by
> categorizing apps into good and bad apps in a weird way.

I don't see this, can you please explain?

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:08]:
> > On Thursday 13 May 2010, Tony Lindgren wrote:
> > > 
> > > The difference between echo mem > /sys/power/state and suspend blocks
> > > is that with suspend blocks the system keeps running.
> > 
> > Care to elaborate?
> 
> The suspend blocks affects the runtime behaviour of the system by
> categorizing apps into good and bad apps in a weird way.

I don't see this, can you please explain?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> > > And that's why 
> > > it should be handled by runtime power management instead.
> > 
> > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > More or less by definition -- if it could then it wouldn't be "runtime" 
> > any more, since the processor wouldn't be running.
> 
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

Okay, that's a valid point.  But is that approach usable in general 
(i.e., on non-OMAP systems)?

How do you handle situations where the CPU is currently idle but an 
event (such as I/O completion) is expected to occur in the near future?  
You don't want to power-off and reboot then, do you?

Alan Stern

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

[Alan Stern]

On Thu, 13 May 2010, Tony Lindgren wrote:

> > > And that's why 
> > > it should be handled by runtime power management instead.
> > 
> > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > More or less by definition -- if it could then it wouldn't be "runtime" 
> > any more, since the processor wouldn't be running.
> 
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

Okay, that's a valid point.  But is that approach usable in general 
(i.e., on non-OMAP systems)?

How do you handle situations where the CPU is currently idle but an 
event (such as I/O completion) is expected to occur in the near future?  
You don't want to power-off and reboot then, do you?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > The difference between echo mem > /sys/power/state and suspend blocks
> > > is that with suspend blocks the system keeps running.
> > 
> > Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
> > talking about opportunistic suspend.  So what's the difference between 
> > opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
> > when suspend blockers aren't being used?
> 
> Opportunistic suspend is really trying to do runtime PM, see below.

NO, IT IS NOT!  What it does is to detect situations in which it is desirable
to put the _entire_ _system_ to sleep, while runtime PM works on a per-device
basis.

> > > And that's why 
> > > it should be handled by runtime power management instead.
> > 
> > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > More or less by definition -- if it could then it wouldn't be "runtime" 
> > any more, since the processor wouldn't be running.
> 
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

What about user space, though?  Do you freeze it?

> > > The suspend blocks seems like a hack to spam filter good and bad
> > > apps from timer usage point of view. Applications are categorized
> > > as good or bad depending if they grab a susped blocker or not.
> > 
> > You're referring just to the userspace part of the suspend blocker 
> > API.  What about the kernel part?
> 
> IMHO some timer flags should be used in the kernel too. Currently
> there's no way of knowing which timers are good or bad from suspend
> point of view.

How is that answering the Alan's question?

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > The difference between echo mem > /sys/power/state and suspend blocks
> > > is that with suspend blocks the system keeps running.
> > 
> > Irrelevant.  Paul wasn't talking about the suspend blockers; he was 
> > talking about opportunistic suspend.  So what's the difference between 
> > opportunistic suspend and "echo mem >/sys/power/state"?  Especially 
> > when suspend blockers aren't being used?
> 
> Opportunistic suspend is really trying to do runtime PM, see below.

NO, IT IS NOT!  What it does is to detect situations in which it is desirable
to put the _entire_ _system_ to sleep, while runtime PM works on a per-device
basis.

> > > And that's why 
> > > it should be handled by runtime power management instead.
> > 
> > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > More or less by definition -- if it could then it wouldn't be "runtime" 
> > any more, since the processor wouldn't be running.
> 
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

What about user space, though?  Do you freeze it?

> > > The suspend blocks seems like a hack to spam filter good and bad
> > > apps from timer usage point of view. Applications are categorized
> > > as good or bad depending if they grab a susped blocker or not.
> > 
> > You're referring just to the userspace part of the suspend blocker 
> > API.  What about the kernel part?
> 
> IMHO some timer flags should be used in the kernel too. Currently
> there's no way of knowing which timers are good or bad from suspend
> point of view.

How is that answering the Alan's question?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:36]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > Well this is an interesting problem, and once solved will be handy
> > > for all kind of things. My worry is that if it's integrated in it's
> > > current form it will be totally out of control all over the place :(
> > > 
> > > Still hoping we can come up with some clean way that avoid the patching
> > > all over the place part.. How about the following, can you please check
> > > if it would help with your example of guaranteed handling of event:
> > > 
> > > 1. In the kernel, we add one more timer queue for critical timers.
> > >    The current timer queue(s) stay as it is.
> > > 
> > > 2. We allow selecting the timer based on some flag, the default
> > >    behaviour being the current default timer queue.
> > > 
> > > 3. Then we add next_timer_interupt_critical() to only query the
> > >    critical timers along the lines of the current next_timer_interrupt().
> > > 
> > > 4. We implement a custom pm_idle that suspends the system based on
> > >    some logic and checking if next_timer_interrupt_critical() is
> > >    empty. If the next_timer_interrupt_critical() does not return
> > >    anything, we assume it's OK to suspend the system.
> > > 
> > > Now to me it sounds if your the input layer and userspace handle
> > > both grab the timers with the critical flags, it should be guaranteed
> > > that the events get handled before the system is suspended.
> > 
> > Why do you want this to be tied to timers?  Many of the events in 
> > question are asynchronous with no specific timing relations.
> 
> To me it seems that the non-timer related events can be dealt
> with toggling the opportunistic suspend idle flag in sysfs.
> That should depend on the device and use specific policy.

OK, that's all hand waving.  Do you have any patches, please?

Rafael

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

[Rafael J. Wysocki]

On Thursday 13 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:36]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > Well this is an interesting problem, and once solved will be handy
> > > for all kind of things. My worry is that if it's integrated in it's
> > > current form it will be totally out of control all over the place :(
> > > 
> > > Still hoping we can come up with some clean way that avoid the patching
> > > all over the place part.. How about the following, can you please check
> > > if it would help with your example of guaranteed handling of event:
> > > 
> > > 1. In the kernel, we add one more timer queue for critical timers.
> > >    The current timer queue(s) stay as it is.
> > > 
> > > 2. We allow selecting the timer based on some flag, the default
> > >    behaviour being the current default timer queue.
> > > 
> > > 3. Then we add next_timer_interupt_critical() to only query the
> > >    critical timers along the lines of the current next_timer_interrupt().
> > > 
> > > 4. We implement a custom pm_idle that suspends the system based on
> > >    some logic and checking if next_timer_interrupt_critical() is
> > >    empty. If the next_timer_interrupt_critical() does not return
> > >    anything, we assume it's OK to suspend the system.
> > > 
> > > Now to me it sounds if your the input layer and userspace handle
> > > both grab the timers with the critical flags, it should be guaranteed
> > > that the events get handled before the system is suspended.
> > 
> > Why do you want this to be tied to timers?  Many of the events in 
> > question are asynchronous with no specific timing relations.
> 
> To me it seems that the non-timer related events can be dealt
> with toggling the opportunistic suspend idle flag in sysfs.
> That should depend on the device and use specific policy.

OK, that's all hand waving.  Do you have any patches, please?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:56]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > > > And that's why 
> > > > it should be handled by runtime power management instead.
> > > 
> > > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > > More or less by definition -- if it could then it wouldn't be "runtime" 
> > > any more, since the processor wouldn't be running.
> > 
> > Not true. We are already powering off CPUs and rebooting them for
> > at least omaps in every idle loop using cpuidle. The memory stays on.
> 
> Okay, that's a valid point.  But is that approach usable in general 
> (i.e., on non-OMAP systems)?

Yes if your system wakes to interrupts at least. If your system does
not wake to timer events, then you'll get missed timers. So it should
work on PC too with CONFIG_NO_HZ and if RTC was used for the timer
wake event.
 
> How do you handle situations where the CPU is currently idle but an 
> event (such as I/O completion) is expected to occur in the near future?  
> You don't want to power-off and reboot then, do you?

The idle code looks at next_timer_interrupt() value, then if the
next timer event if far enough ahead, the system powers down and
wakes to the timer interrupt. It also wakes to device interrupts.

For the drivers to block hitting off-idle custom idle functions
can be used. Paul Walmsley and Kevin Hilman have some ideas on
having generic latency information available for that. So there
are similar issues to opportunistic suspend + suspend blocks
that should be sorted out in a generic way.

For the drivers to power down, some timeout value seems to work
best.

Regards,

Tony

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

[Tony Lindgren]

* Alan Stern <stern@rowland.harvard.edu> [100513 14:56]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > > > And that's why 
> > > > it should be handled by runtime power management instead.
> > > 
> > > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > > More or less by definition -- if it could then it wouldn't be "runtime" 
> > > any more, since the processor wouldn't be running.
> > 
> > Not true. We are already powering off CPUs and rebooting them for
> > at least omaps in every idle loop using cpuidle. The memory stays on.
> 
> Okay, that's a valid point.  But is that approach usable in general 
> (i.e., on non-OMAP systems)?

Yes if your system wakes to interrupts at least. If your system does
not wake to timer events, then you'll get missed timers. So it should
work on PC too with CONFIG_NO_HZ and if RTC was used for the timer
wake event.
 
> How do you handle situations where the CPU is currently idle but an 
> event (such as I/O completion) is expected to occur in the near future?  
> You don't want to power-off and reboot then, do you?

The idle code looks at next_timer_interrupt() value, then if the
next timer event if far enough ahead, the system powers down and
wakes to the timer interrupt. It also wakes to device interrupts.

For the drivers to block hitting off-idle custom idle functions
can be used. Paul Walmsley and Kevin Hilman have some ideas on
having generic latency information available for that. So there
are similar issues to opportunistic suspend + suspend blocks
that should be sorted out in a generic way.

For the drivers to power down, some timeout value seems to work
best.

Regards,

Tony

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[tytso]

On Thu, May 13, 2010 at 02:25:56PM -0700, Tony Lindgren wrote:
> > I agree and I don't understand the problem that people have with the
> > opportunistic suspend feature.
> 
> It seems to be picking quite a few comments for one.

It's picking up a lot of comments because *someone* seems to be trying
to use a "last post wins" style of argumentation.  One of the things
that is hard for people who aren't regular denizens of LKML is to
understand whose comments can be ignored.....

Seriously, you are posting a lot, but it's not clear you're making any
clear sense...

					- Ted

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

[tytso]

On Thu, May 13, 2010 at 02:25:56PM -0700, Tony Lindgren wrote:
> > I agree and I don't understand the problem that people have with the
> > opportunistic suspend feature.
> 
> It seems to be picking quite a few comments for one.

It's picking up a lot of comments because *someone* seems to be trying
to use a "last post wins" style of argumentation.  One of the things
that is hard for people who aren't regular denizens of LKML is to
understand whose comments can be ignored.....

Seriously, you are posting a lot, but it's not clear you're making any
clear sense...

					- Ted

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 12:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 12:20]:
>> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
>> > The suspend blocks seems like a hack to spam filter good and bad
>> > apps from timer usage point of view. Applications are categorized
>> > as good or bad depending if they grab a susped blocker or not.
>> >
>> > I believe categorizing the apps should be instead done with some
>> > timer flags or cgroups instead.
>>
>> I agree, but we have no mechanism for implementing that in a race-free
>> way. We don't even have a realistical proposal for what that mechanism
>> would look like. Should we refuse bread today for the promise of cake
>> tomorrow?
>
> Well this is an interesting problem, and once solved will be handy
> for all kind of things. My worry is that if it's integrated in it's
> current form it will be totally out of control all over the place :(
>
> Still hoping we can come up with some clean way that avoid the patching
> all over the place part.. How about the following, can you please check
> if it would help with your example of guaranteed handling of event:
>
> 1. In the kernel, we add one more timer queue for critical timers.
>   The current timer queue(s) stay as it is.
>
> 2. We allow selecting the timer based on some flag, the default
>   behaviour being the current default timer queue.
>
> 3. Then we add next_timer_interupt_critical() to only query the
>   critical timers along the lines of the current next_timer_interrupt().
>
> 4. We implement a custom pm_idle that suspends the system based on
>   some logic and checking if next_timer_interrupt_critical() is
>   empty. If the next_timer_interrupt_critical() does not return
>   anything, we assume it's OK to suspend the system.
>

I think trying to solve this at the timer level requires more patching
than using suspend blockers. With suspend blocker you block suspend
until some work has finished, or an event has been consumed. You can
safely use any existing synchronous api.

> Now to me it sounds if your the input layer and userspace handle
> both grab the timers with the critical flags, it should be guaranteed
> that the events get handled before the system is suspended.
>

There are no timers used in this path. However any critical section
used from this path could cause the system to enter idle. Instead of
blocking suspend while there are unprocessed input event you now have
to make sure all code that can block any of the threads involved in
processing those event don't wait on a non critical timer.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 12:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 12:20]:
>> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
>> > The suspend blocks seems like a hack to spam filter good and bad
>> > apps from timer usage point of view. Applications are categorized
>> > as good or bad depending if they grab a susped blocker or not.
>> >
>> > I believe categorizing the apps should be instead done with some
>> > timer flags or cgroups instead.
>>
>> I agree, but we have no mechanism for implementing that in a race-free
>> way. We don't even have a realistical proposal for what that mechanism
>> would look like. Should we refuse bread today for the promise of cake
>> tomorrow?
>
> Well this is an interesting problem, and once solved will be handy
> for all kind of things. My worry is that if it's integrated in it's
> current form it will be totally out of control all over the place :(
>
> Still hoping we can come up with some clean way that avoid the patching
> all over the place part.. How about the following, can you please check
> if it would help with your example of guaranteed handling of event:
>
> 1. In the kernel, we add one more timer queue for critical timers.
>   The current timer queue(s) stay as it is.
>
> 2. We allow selecting the timer based on some flag, the default
>   behaviour being the current default timer queue.
>
> 3. Then we add next_timer_interupt_critical() to only query the
>   critical timers along the lines of the current next_timer_interrupt().
>
> 4. We implement a custom pm_idle that suspends the system based on
>   some logic and checking if next_timer_interrupt_critical() is
>   empty. If the next_timer_interrupt_critical() does not return
>   anything, we assume it's OK to suspend the system.
>

I think trying to solve this at the timer level requires more patching
than using suspend blockers. With suspend blocker you block suspend
until some work has finished, or an event has been consumed. You can
safely use any existing synchronous api.

> Now to me it sounds if your the input layer and userspace handle
> both grab the timers with the critical flags, it should be guaranteed
> that the events get handled before the system is suspended.
>

There are no timers used in this path. However any critical section
used from this path could cause the system to enter idle. Instead of
blocking suspend while there are unprocessed input event you now have
to make sure all code that can block any of the threads involved in
processing those event don't wait on a non critical timer.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:

> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.

> Sorry, but it doesn't seem to work that way.  Look at the large number
> of out-of-tree android device drivers that remain sitting there because
> of the lack of this interface being in the kernel.

Is that really the issue?  The ones I've looked at have mostly suffered
from being built on 2.6.29 and needing refreshes for current kernel APIs
or from general code quality issues - I don't recall ever looking at one
and thinking that the wakelocks were the one issue.

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

Chances are that if the driver is useful people will start using it in
non-Android systems anyway.  As people have already observed wakelocks
needn't have any practical effect on the running system so if the
drivers are broken without wakelocks they'd be broken anyway.  

If this really is a big concern with getting drivers into mainline then
surely we could just add some noop wakelock functions for the drivers to
call?  It's not particularly pretty but it'd deal with the driver merge
side of things.

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

[Mark Brown]

On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:

> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.

> Sorry, but it doesn't seem to work that way.  Look at the large number
> of out-of-tree android device drivers that remain sitting there because
> of the lack of this interface being in the kernel.

Is that really the issue?  The ones I've looked at have mostly suffered
from being built on 2.6.29 and needing refreshes for current kernel APIs
or from general code quality issues - I don't recall ever looking at one
and thinking that the wakelocks were the one issue.

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

Chances are that if the driver is useful people will start using it in
non-Android systems anyway.  As people have already observed wakelocks
needn't have any practical effect on the running system so if the
drivers are broken without wakelocks they'd be broken anyway.  

If this really is a big concern with getting drivers into mainline then
surely we could just add some noop wakelock functions for the drivers to
call?  It's not particularly pretty but it'd deal with the driver merge
side of things.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Friday 14 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:56]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > > > And that's why 
> > > > > it should be handled by runtime power management instead.
> > > > 
> > > > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > > > More or less by definition -- if it could then it wouldn't be "runtime" 
> > > > any more, since the processor wouldn't be running.
> > > 
> > > Not true. We are already powering off CPUs and rebooting them for
> > > at least omaps in every idle loop using cpuidle. The memory stays on.
> > 
> > Okay, that's a valid point.  But is that approach usable in general 
> > (i.e., on non-OMAP systems)?
> 
> Yes if your system wakes to interrupts at least. If your system does
> not wake to timer events, then you'll get missed timers. So it should
> work on PC too with CONFIG_NO_HZ and if RTC was used for the timer
> wake event.
>  
> > How do you handle situations where the CPU is currently idle but an 
> > event (such as I/O completion) is expected to occur in the near future?  
> > You don't want to power-off and reboot then, do you?
> 
> The idle code looks at next_timer_interrupt() value, then if the
> next timer event if far enough ahead, the system powers down and
> wakes to the timer interrupt. It also wakes to device interrupts.

For the record, waking to interrupts doesn't work on quite some systems
(like ACPI-based PCs for one example).

Rafael

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

[Rafael J. Wysocki]

On Friday 14 May 2010, Tony Lindgren wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:56]:
> > On Thu, 13 May 2010, Tony Lindgren wrote:
> > 
> > > > > And that's why 
> > > > > it should be handled by runtime power management instead.
> > > > 
> > > > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > > > More or less by definition -- if it could then it wouldn't be "runtime" 
> > > > any more, since the processor wouldn't be running.
> > > 
> > > Not true. We are already powering off CPUs and rebooting them for
> > > at least omaps in every idle loop using cpuidle. The memory stays on.
> > 
> > Okay, that's a valid point.  But is that approach usable in general 
> > (i.e., on non-OMAP systems)?
> 
> Yes if your system wakes to interrupts at least. If your system does
> not wake to timer events, then you'll get missed timers. So it should
> work on PC too with CONFIG_NO_HZ and if RTC was used for the timer
> wake event.
>  
> > How do you handle situations where the CPU is currently idle but an 
> > event (such as I/O completion) is expected to occur in the near future?  
> > You don't want to power-off and reboot then, do you?
> 
> The idle code looks at next_timer_interrupt() value, then if the
> next timer event if far enough ahead, the system powers down and
> wakes to the timer interrupt. It also wakes to device interrupts.

For the record, waking to interrupts doesn't work on quite some systems
(like ACPI-based PCs for one example).

Rafael

RE: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: Thursday, May 13, 2010 4:47 PM

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

Do wakelock enabled drivers require a wakelock aware user space to function properly?  If the driver is added you want to make sure the benefit is there and testable for all userspaces.

Early Android service managers did take/release userspace locks to ensure the handoff worked.

Getting all these drivers is positive.  Getting to some constraint mechanism is positive.  It does need to exist end to end to make a difference at the battery.

Regards,
Richard W.

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

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: Thursday, May 13, 2010 4:47 PM

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

Do wakelock enabled drivers require a wakelock aware user space to function properly?  If the driver is added you want to make sure the benefit is there and testable for all userspaces.

Early Android service managers did take/release userspace locks to ensure the handoff worked.

Getting all these drivers is positive.  Getting to some constraint mechanism is positive.  It does need to exist end to end to make a difference at the battery.

Regards,
Richard W.

RE: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: Thursday, May 13, 2010 4:47 PM

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

Do wakelock enabled drivers require a wakelock aware user space to function properly?  If the driver is added you want to make sure the benefit is there and testable for all userspaces.

Early Android service managers did take/release userspace locks to ensure the handoff worked.

Getting all these drivers is positive.  Getting to some constraint mechanism is positive.  It does need to exist end to end to make a difference at the battery.

Regards,
Richard W.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Greg KH]

On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote:
> On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> 
> > > You get the driver mainlined, then maintain a small patch to add
> > > wakelocks. Not hard at all , with lots of incentive to do so since you
> > > don't have to maintain such a large block of code out of tree.
> 
> > Sorry, but it doesn't seem to work that way.  Look at the large number
> > of out-of-tree android device drivers that remain sitting there because
> > of the lack of this interface being in the kernel.
> 
> Is that really the issue?  The ones I've looked at have mostly suffered
> from being built on 2.6.29 and needing refreshes for current kernel APIs
> or from general code quality issues - I don't recall ever looking at one
> and thinking that the wakelocks were the one issue.

Yes, it is an issue.  See the mess that we have had in trying to get
some of the original G1 drivers merged in the staging tree for proof of
this.

> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Chances are that if the driver is useful people will start using it in
> non-Android systems anyway.

No, not usually.  Do you really think that someone else is going to use
the G1 camera driver for anything else?  :)

> As people have already observed wakelocks needn't have any practical
> effect on the running system so if the drivers are broken without
> wakelocks they'd be broken anyway.  
> 
> If this really is a big concern with getting drivers into mainline then
> surely we could just add some noop wakelock functions for the drivers to
> call?  It's not particularly pretty but it'd deal with the driver merge
> side of things.

I fail to see why getting the real functionality of the wakelocks into
the kernel is a problem.  Especially as they fit a real need, and work
well for that.

thanks,

greg k-h

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

[Greg KH]

On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote:
> On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> 
> > > You get the driver mainlined, then maintain a small patch to add
> > > wakelocks. Not hard at all , with lots of incentive to do so since you
> > > don't have to maintain such a large block of code out of tree.
> 
> > Sorry, but it doesn't seem to work that way.  Look at the large number
> > of out-of-tree android device drivers that remain sitting there because
> > of the lack of this interface being in the kernel.
> 
> Is that really the issue?  The ones I've looked at have mostly suffered
> from being built on 2.6.29 and needing refreshes for current kernel APIs
> or from general code quality issues - I don't recall ever looking at one
> and thinking that the wakelocks were the one issue.

Yes, it is an issue.  See the mess that we have had in trying to get
some of the original G1 drivers merged in the staging tree for proof of
this.

> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Chances are that if the driver is useful people will start using it in
> non-Android systems anyway.

No, not usually.  Do you really think that someone else is going to use
the G1 camera driver for anything else?  :)

> As people have already observed wakelocks needn't have any practical
> effect on the running system so if the drivers are broken without
> wakelocks they'd be broken anyway.  
> 
> If this really is a big concern with getting drivers into mainline then
> surely we could just add some noop wakelock functions for the drivers to
> call?  It's not particularly pretty but it'd deal with the driver merge
> side of things.

I fail to see why getting the real functionality of the wakelocks into
the kernel is a problem.  Especially as they fit a real need, and work
well for that.

thanks,

greg k-h

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Greg KH]

On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
> 
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Thursday, May 13, 2010 4:47 PM
> 
> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Do wakelock enabled drivers require a wakelock aware user space to
> function properly?

Not that I can tell, but others might know more.

> If the driver is added you want to make sure the benefit is there and
> testable for all userspaces.

Agreed.

thanks,

greg k-h

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

[Greg KH]

On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
> 
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Thursday, May 13, 2010 4:47 PM
> 
> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Do wakelock enabled drivers require a wakelock aware user space to
> function properly?

Not that I can tell, but others might know more.

> If the driver is added you want to make sure the benefit is there and
> testable for all userspaces.

Agreed.

thanks,

greg k-h

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Friday 14 May 2010, Mark Brown wrote:
> On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> 
> > > You get the driver mainlined, then maintain a small patch to add
> > > wakelocks. Not hard at all , with lots of incentive to do so since you
> > > don't have to maintain such a large block of code out of tree.
> 
> > Sorry, but it doesn't seem to work that way.  Look at the large number
> > of out-of-tree android device drivers that remain sitting there because
> > of the lack of this interface being in the kernel.
> 
> Is that really the issue?  The ones I've looked at have mostly suffered
> from being built on 2.6.29 and needing refreshes for current kernel APIs
> or from general code quality issues - I don't recall ever looking at one
> and thinking that the wakelocks were the one issue.
> 
> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Chances are that if the driver is useful people will start using it in
> non-Android systems anyway.

You're missing the point IMO.  Even if they are only used on Android, there
still is a problem if they don't go into the mainline, because that leads to
code divergence that's growing over time and will ultimately create an entire
ecosystem that's independent of the mainline.

We've been successful in avoiding that for quite some time and I don't think
we should allow that to happen right now because of the opportunistic suspend
feature.

I'm not a big fan of suspend blockers myself, but let's face it, _currently_
there's no alternative and we need to stop the trend, the sooner the better.

> As people have already observed wakelocks
> needn't have any practical effect on the running system so if the
> drivers are broken without wakelocks they'd be broken anyway.  

You need to prove the reverse, ie. that a driver working correctly with
wakelocks will also work correctly without them, which is not a given.

> If this really is a big concern with getting drivers into mainline then
> surely we could just add some noop wakelock functions for the drivers to
> call?

Well, I don't see a big difference between that and adding the feature
depending on a .config option.  Really.

> It's not particularly pretty but it'd deal with the driver merge
> side of things.

Again, I don't see why you hate that feature so much.  What is there to worry
about?

Rafael

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

[Rafael J. Wysocki]

On Friday 14 May 2010, Mark Brown wrote:
> On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
> > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> 
> > > You get the driver mainlined, then maintain a small patch to add
> > > wakelocks. Not hard at all , with lots of incentive to do so since you
> > > don't have to maintain such a large block of code out of tree.
> 
> > Sorry, but it doesn't seem to work that way.  Look at the large number
> > of out-of-tree android device drivers that remain sitting there because
> > of the lack of this interface being in the kernel.
> 
> Is that really the issue?  The ones I've looked at have mostly suffered
> from being built on 2.6.29 and needing refreshes for current kernel APIs
> or from general code quality issues - I don't recall ever looking at one
> and thinking that the wakelocks were the one issue.
> 
> > Also note that such a driver, without wakelocks, would never get tested,
> > and so, things start quickly diverging.
> 
> Chances are that if the driver is useful people will start using it in
> non-Android systems anyway.

You're missing the point IMO.  Even if they are only used on Android, there
still is a problem if they don't go into the mainline, because that leads to
code divergence that's growing over time and will ultimately create an entire
ecosystem that's independent of the mainline.

We've been successful in avoiding that for quite some time and I don't think
we should allow that to happen right now because of the opportunistic suspend
feature.

I'm not a big fan of suspend blockers myself, but let's face it, _currently_
there's no alternative and we need to stop the trend, the sooner the better.

> As people have already observed wakelocks
> needn't have any practical effect on the running system so if the
> drivers are broken without wakelocks they'd be broken anyway.  

You need to prove the reverse, ie. that a driver working correctly with
wakelocks will also work correctly without them, which is not a given.

> If this really is a big concern with getting drivers into mainline then
> surely we could just add some noop wakelock functions for the drivers to
> call?

Well, I don't see a big difference between that and adding the feature
depending on a .config option.  Really.

> It's not particularly pretty but it'd deal with the driver merge
> side of things.

Again, I don't see why you hate that feature so much.  What is there to worry
about?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.
>

Some of our drivers may not work correctly with forced suspend, but if
you don't use suspend at all, the wakelocks have no effect and all the
drivers will work correctly.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.
>
> thanks,
>
> greg k-h
>



-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.
>

Some of our drivers may not work correctly with forced suspend, but if
you don't use suspend at all, the wakelocks have no effect and all the
drivers will work correctly.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.
>
> thanks,
>
> greg k-h
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.
>

Some of our drivers may not work correctly with forced suspend, but if
you don't use suspend at all, the wakelocks have no effect and all the
drivers will work correctly.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.
>
> thanks,
>
> greg k-h
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.

Drivers with correct wakelock usage will play nice with opportunistic suspend.

If you're not using opportunistic suspend, you probably don't need
wakelocks at all, and the driver (unless it's broken) should work just
fine for you.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.

Definitely.  The fact that say the dsp audio driver or serial driver
on MSM use wakelocks to play nice with opportunistic suspend should
have no impact on, say, Debian-on-G1 which is not using that feature.
Debian would still be able to play audio or write to the serial port.

With wakelock support in the kernel, I'm able to maintain drivers that
(provided they meet the normal style, correctness, etc requirements)
that both can be submitted to mainline (yay!) and can ship on
production hardware as-is (yay!).  Porting other linux based
environments to hardware like G1, N1, etc becomes that much easier
too, which hopefully makes various folks happy.

This helps get us ever closer to being able to build a
production-ready kernel for various android devices "out of the box"
from the mainline tree and gets me ever closer to not being in the
business of maintaining a bunch of SoC-specific
android-something-2.6.# trees, which seriously is not a business I
particularly want to be in.

Brian

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

[Brian Swetland]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.

Drivers with correct wakelock usage will play nice with opportunistic suspend.

If you're not using opportunistic suspend, you probably don't need
wakelocks at all, and the driver (unless it's broken) should work just
fine for you.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.

Definitely.  The fact that say the dsp audio driver or serial driver
on MSM use wakelocks to play nice with opportunistic suspend should
have no impact on, say, Debian-on-G1 which is not using that feature.
Debian would still be able to play audio or write to the serial port.

With wakelock support in the kernel, I'm able to maintain drivers that
(provided they meet the normal style, correctness, etc requirements)
that both can be submitted to mainline (yay!) and can ship on
production hardware as-is (yay!).  Porting other linux based
environments to hardware like G1, N1, etc becomes that much easier
too, which hopefully makes various folks happy.

This helps get us ever closer to being able to build a
production-ready kernel for various android devices "out of the box"
from the mainline tree and gets me ever closer to not being in the
business of maintaining a bunch of SoC-specific
android-something-2.6.# trees, which seriously is not a business I
particularly want to be in.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
>>
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Greg KH
>> > Sent: Thursday, May 13, 2010 4:47 PM
>>
>> > Also note that such a driver, without wakelocks, would never get tested,
>> > and so, things start quickly diverging.
>>
>> Do wakelock enabled drivers require a wakelock aware user space to
>> function properly?
>
> Not that I can tell, but others might know more.

Drivers with correct wakelock usage will play nice with opportunistic suspend.

If you're not using opportunistic suspend, you probably don't need
wakelocks at all, and the driver (unless it's broken) should work just
fine for you.

>> If the driver is added you want to make sure the benefit is there and
>> testable for all userspaces.
>
> Agreed.

Definitely.  The fact that say the dsp audio driver or serial driver
on MSM use wakelocks to play nice with opportunistic suspend should
have no impact on, say, Debian-on-G1 which is not using that feature.
Debian would still be able to play audio or write to the serial port.

With wakelock support in the kernel, I'm able to maintain drivers that
(provided they meet the normal style, correctness, etc requirements)
that both can be submitted to mainline (yay!) and can ship on
production hardware as-is (yay!).  Porting other linux based
environments to hardware like G1, N1, etc becomes that much easier
too, which hopefully makes various folks happy.

This helps get us ever closer to being able to build a
production-ready kernel for various android devices "out of the box"
from the mainline tree and gets me ever closer to not being in the
business of maintaining a bunch of SoC-specific
android-something-2.6.# trees, which seriously is not a business I
particularly want to be in.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Fri, May 14, 2010 at 12:46:33AM +0200, Rafael J. Wysocki wrote:
> On Friday 14 May 2010, Mark Brown wrote:

> > Is that really the issue?  The ones I've looked at have mostly suffered
> > from being built on 2.6.29 and needing refreshes for current kernel APIs
> > or from general code quality issues - I don't recall ever looking at one
> > and thinking that the wakelocks were the one issue.

...

> > Chances are that if the driver is useful people will start using it in
> > non-Android systems anyway.

> You're missing the point IMO.  Even if they are only used on Android, there
> still is a problem if they don't go into the mainline, because that leads to
> code divergence that's growing over time and will ultimately create an entire
> ecosystem that's independent of the mainline.

See my first paragraph there.  My point here is that we appear to have
the standard vendor BSP ecosystem problem here rather than a wakelock
problem.

It's fairly common in the embedded space to get a whole bunch of work
done which doesn't make its way into mainline due to a SoC vendor having
produced a BSP for their SoC which is based around a particular kernel
version which never gets updated.  This means users with that SoC can't
boot anything newer until someone does the work of mainlining support
for the system, meaning that development on systems using that SoC gets
stuck on an old kernel which mainline drifts away from.  Users find it
hard to contribute back since they can't run current code easily and
often have to jump through serious hoops to backport drivers from newer
kernels.  If the SoC is successful enough then you do get something of
an ecosystem around the BSP, though eventually that usually results in
the community doing the mainline merge.

> We've been successful in avoiding that for quite some time and I don't think
> we should allow that to happen right now because of the opportunistic suspend
> feature.

This is still a work in progress in the embedded space (where wakelocks
are primarily relevant).  Many of the major vendors are working in the
right direction here, but it's far from universal and it's not something
that it's easy for vendors to change overnight.

> I'm not a big fan of suspend blockers myself, but let's face it, _currently_
> there's no alternative and we need to stop the trend, the sooner the better.

I don't think this is a major part of the trend - like I say, the fact
that people have been working with an old kernel version is generally
a much more substantial issue than the wakelocks in the code I've seen.

> > As people have already observed wakelocks
> > needn't have any practical effect on the running system so if the
> > drivers are broken without wakelocks they'd be broken anyway.  

> You need to prove the reverse, ie. that a driver working correctly with
> wakelocks will also work correctly without them, which is not a given.

If they can be compiled out then the updates really ought to be trivial.
If not I really need to go back and reexamine what's going on here to
make sure I understand what drivers are supposed to do, I have to
confess that I haven't looked too closely at the driver side API yet.

> > It's not particularly pretty but it'd deal with the driver merge
> > side of things.

> Again, I don't see why you hate that feature so much.  What is there to worry
> about?

As I have said previously I'm not actively opposed to merging wakelocks
at this point.  My major concern has been addressed, I now agree with
most of what the PM guys are saying - it's not the nicest thing ever but
it works for now.

The issue was that when I originally noticed the patch series was being
considered for mainline again was that one effect of using it in a
mobile phone with the standard Linux embedded audio subsystem would be
to break use cases such as audio on voice calls, which isn't really
desirable, and that there was no roadmap for how to fix that or any
other subsystems with similar issues.  This didn't seem like it would
have been a good situation given that the major user is expected to be
Android, which is mainly for mobile phones.

Since we seemed to all agree that no other subsystems were affected,
meaning nothing general was required, I've now implemented support in
the subsystem for ignoring suspends for some audio paths (this should
appear In the next merge window).  This should mesh well with wakelocks.

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

[Mark Brown]

On Fri, May 14, 2010 at 12:46:33AM +0200, Rafael J. Wysocki wrote:
> On Friday 14 May 2010, Mark Brown wrote:

> > Is that really the issue?  The ones I've looked at have mostly suffered
> > from being built on 2.6.29 and needing refreshes for current kernel APIs
> > or from general code quality issues - I don't recall ever looking at one
> > and thinking that the wakelocks were the one issue.

...

> > Chances are that if the driver is useful people will start using it in
> > non-Android systems anyway.

> You're missing the point IMO.  Even if they are only used on Android, there
> still is a problem if they don't go into the mainline, because that leads to
> code divergence that's growing over time and will ultimately create an entire
> ecosystem that's independent of the mainline.

See my first paragraph there.  My point here is that we appear to have
the standard vendor BSP ecosystem problem here rather than a wakelock
problem.

It's fairly common in the embedded space to get a whole bunch of work
done which doesn't make its way into mainline due to a SoC vendor having
produced a BSP for their SoC which is based around a particular kernel
version which never gets updated.  This means users with that SoC can't
boot anything newer until someone does the work of mainlining support
for the system, meaning that development on systems using that SoC gets
stuck on an old kernel which mainline drifts away from.  Users find it
hard to contribute back since they can't run current code easily and
often have to jump through serious hoops to backport drivers from newer
kernels.  If the SoC is successful enough then you do get something of
an ecosystem around the BSP, though eventually that usually results in
the community doing the mainline merge.

> We've been successful in avoiding that for quite some time and I don't think
> we should allow that to happen right now because of the opportunistic suspend
> feature.

This is still a work in progress in the embedded space (where wakelocks
are primarily relevant).  Many of the major vendors are working in the
right direction here, but it's far from universal and it's not something
that it's easy for vendors to change overnight.

> I'm not a big fan of suspend blockers myself, but let's face it, _currently_
> there's no alternative and we need to stop the trend, the sooner the better.

I don't think this is a major part of the trend - like I say, the fact
that people have been working with an old kernel version is generally
a much more substantial issue than the wakelocks in the code I've seen.

> > As people have already observed wakelocks
> > needn't have any practical effect on the running system so if the
> > drivers are broken without wakelocks they'd be broken anyway.  

> You need to prove the reverse, ie. that a driver working correctly with
> wakelocks will also work correctly without them, which is not a given.

If they can be compiled out then the updates really ought to be trivial.
If not I really need to go back and reexamine what's going on here to
make sure I understand what drivers are supposed to do, I have to
confess that I haven't looked too closely at the driver side API yet.

> > It's not particularly pretty but it'd deal with the driver merge
> > side of things.

> Again, I don't see why you hate that feature so much.  What is there to worry
> about?

As I have said previously I'm not actively opposed to merging wakelocks
at this point.  My major concern has been addressed, I now agree with
most of what the PM guys are saying - it's not the nicest thing ever but
it works for now.

The issue was that when I originally noticed the patch series was being
considered for mainline again was that one effect of using it in a
mobile phone with the standard Linux embedded audio subsystem would be
to break use cases such as audio on voice calls, which isn't really
desirable, and that there was no roadmap for how to fix that or any
other subsystems with similar issues.  This didn't seem like it would
have been a good situation given that the major user is expected to be
Android, which is mainly for mobile phones.

Since we seemed to all agree that no other subsystems were affected,
meaning nothing general was required, I've now implemented support in
the subsystem for ignoring suspends for some audio paths (this should
appear In the next merge window).  This should mesh well with wakelocks.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Thu, May 13, 2010 at 4:36 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
>> I'm not a big fan of suspend blockers myself, but let's face it, _currently_
>> there's no alternative and we need to stop the trend, the sooner the better.
>
> I don't think this is a major part of the trend - like I say, the fact
> that people have been working with an old kernel version is generally
> a much more substantial issue than the wakelocks in the code I've seen.

Current published trees are based on .32 (used for the coming-soon
froyo release that's been in late QA for a while now) and forward
development is moving to .34 post final (or in the case of tegra2,
tracking .34-rc series as it happens).  We've been actively snapping
up to track mainline since we started doing this around 2.6.16.  We'd
*love* to be able to get more stuff sanely upstream instead of
maintaining branches and rebasing every other mainline release or so.

> The issue was that when I originally noticed the patch series was being
> considered for mainline again was that one effect of using it in a
> mobile phone with the standard Linux embedded audio subsystem would be
> to break use cases such as audio on voice calls, which isn't really
> desirable, and that there was no roadmap for how to fix that or any
> other subsystems with similar issues.  This didn't seem like it would
> have been a good situation given that the major user is expected to be
> Android, which is mainly for mobile phones.

I'd love to have a separate discussion on using standard linux
embedded audio for mobile devices -- one of my goals for 2010 is to
try to migrate from our "one off" approach on MSM to making use of
ALSA and standard interfaces.  I have a lot of questions about handing
encoded data (mp3/aac/etc) that will be processed by the DSP, how to
approach routing control, and how to best interact with the
user/kernel interface, etc.

Brian

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

[Brian Swetland]

On Thu, May 13, 2010 at 4:36 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
>> I'm not a big fan of suspend blockers myself, but let's face it, _currently_
>> there's no alternative and we need to stop the trend, the sooner the better.
>
> I don't think this is a major part of the trend - like I say, the fact
> that people have been working with an old kernel version is generally
> a much more substantial issue than the wakelocks in the code I've seen.

Current published trees are based on .32 (used for the coming-soon
froyo release that's been in late QA for a while now) and forward
development is moving to .34 post final (or in the case of tegra2,
tracking .34-rc series as it happens).  We've been actively snapping
up to track mainline since we started doing this around 2.6.16.  We'd
*love* to be able to get more stuff sanely upstream instead of
maintaining branches and rebasing every other mainline release or so.

> The issue was that when I originally noticed the patch series was being
> considered for mainline again was that one effect of using it in a
> mobile phone with the standard Linux embedded audio subsystem would be
> to break use cases such as audio on voice calls, which isn't really
> desirable, and that there was no roadmap for how to fix that or any
> other subsystems with similar issues.  This didn't seem like it would
> have been a good situation given that the major user is expected to be
> Android, which is mainly for mobile phones.

I'd love to have a separate discussion on using standard linux
embedded audio for mobile devices -- one of my goals for 2010 is to
try to migrate from our "one off" approach on MSM to making use of
ALSA and standard interfaces.  I have a lot of questions about handing
encoded data (mp3/aac/etc) that will be processed by the DSP, how to
approach routing control, and how to best interact with the
user/kernel interface, etc.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Thu, May 13, 2010 at 4:36 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
>> I'm not a big fan of suspend blockers myself, but let's face it, _currently_
>> there's no alternative and we need to stop the trend, the sooner the better.
>
> I don't think this is a major part of the trend - like I say, the fact
> that people have been working with an old kernel version is generally
> a much more substantial issue than the wakelocks in the code I've seen.

Current published trees are based on .32 (used for the coming-soon
froyo release that's been in late QA for a while now) and forward
development is moving to .34 post final (or in the case of tegra2,
tracking .34-rc series as it happens).  We've been actively snapping
up to track mainline since we started doing this around 2.6.16.  We'd
*love* to be able to get more stuff sanely upstream instead of
maintaining branches and rebasing every other mainline release or so.

> The issue was that when I originally noticed the patch series was being
> considered for mainline again was that one effect of using it in a
> mobile phone with the standard Linux embedded audio subsystem would be
> to break use cases such as audio on voice calls, which isn't really
> desirable, and that there was no roadmap for how to fix that or any
> other subsystems with similar issues.  This didn't seem like it would
> have been a good situation given that the major user is expected to be
> Android, which is mainly for mobile phones.

I'd love to have a separate discussion on using standard linux
embedded audio for mobile devices -- one of my goals for 2010 is to
try to migrate from our "one off" approach on MSM to making use of
ALSA and standard interfaces.  I have a lot of questions about handing
encoded data (mp3/aac/etc) that will be processed by the DSP, how to
approach routing control, and how to best interact with the
user/kernel interface, etc.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Thu, May 13, 2010 at 03:45:03PM -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote:
> > On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:

> > Is that really the issue?  The ones I've looked at have mostly suffered
> > from being built on 2.6.29 and needing refreshes for current kernel APIs
> > or from general code quality issues - I don't recall ever looking at one
> > and thinking that the wakelocks were the one issue.

> Yes, it is an issue.  See the mess that we have had in trying to get
> some of the original G1 drivers merged in the staging tree for proof of
> this.

Ah, that's surprising - I had thought most of the issues there were due
to the substantial MSM architecture core code which most of the G1 stuff
depended on (things like the DSP interface and so on) and the general
need for staging-style updates which churned against the non-mainline
versions rather than the wakelocks.  It's true that the wakelocks
weren't helping, though.
 
Most of the cases I've seen have been off-CPU drivers that were either
working to outdated APIs or having to jump through hoops because they
really wanted to use new kernel features rather than CPU things.

> > Chances are that if the driver is useful people will start using it in
> > non-Android systems anyway.

> No, not usually.  Do you really think that someone else is going to use
> the G1 camera driver for anything else?  :)

Not if it's genuinely G1 specific, although presumably most of that
driver is actually chip drivers for the various components of a camera
subsystem which may well appear in other systems (not that I have the
slightest bit of familiarity with how camera hardware is organised).

> > If this really is a big concern with getting drivers into mainline then
> > surely we could just add some noop wakelock functions for the drivers to
> > call?  It's not particularly pretty but it'd deal with the driver merge
> > side of things.

> I fail to see why getting the real functionality of the wakelocks into
> the kernel is a problem.  Especially as they fit a real need, and work
> well for that.

Well, like I've said I personally don't object to merging them now that
the audio use case has been sorted.  I suggested this because it would
allow something to be put in place to facilitate driver merging which
would avoid the core and userspace issues that people are still raising
with the implementation and let people get on with at least the driver
side.

If wakelocks don't make the next merge window and there is a problem
with drivers then it'd be nice to get the stubs in so that the APIs are
present in subsystem trees for drivers to merge.

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

[Mark Brown]

On Thu, May 13, 2010 at 03:45:03PM -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote:
> > On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:

> > Is that really the issue?  The ones I've looked at have mostly suffered
> > from being built on 2.6.29 and needing refreshes for current kernel APIs
> > or from general code quality issues - I don't recall ever looking at one
> > and thinking that the wakelocks were the one issue.

> Yes, it is an issue.  See the mess that we have had in trying to get
> some of the original G1 drivers merged in the staging tree for proof of
> this.

Ah, that's surprising - I had thought most of the issues there were due
to the substantial MSM architecture core code which most of the G1 stuff
depended on (things like the DSP interface and so on) and the general
need for staging-style updates which churned against the non-mainline
versions rather than the wakelocks.  It's true that the wakelocks
weren't helping, though.
 
Most of the cases I've seen have been off-CPU drivers that were either
working to outdated APIs or having to jump through hoops because they
really wanted to use new kernel features rather than CPU things.

> > Chances are that if the driver is useful people will start using it in
> > non-Android systems anyway.

> No, not usually.  Do you really think that someone else is going to use
> the G1 camera driver for anything else?  :)

Not if it's genuinely G1 specific, although presumably most of that
driver is actually chip drivers for the various components of a camera
subsystem which may well appear in other systems (not that I have the
slightest bit of familiarity with how camera hardware is organised).

> > If this really is a big concern with getting drivers into mainline then
> > surely we could just add some noop wakelock functions for the drivers to
> > call?  It's not particularly pretty but it'd deal with the driver merge
> > side of things.

> I fail to see why getting the real functionality of the wakelocks into
> the kernel is a problem.  Especially as they fit a real need, and work
> well for that.

Well, like I've said I personally don't object to merging them now that
the audio use case has been sorted.  I suggested this because it would
allow something to be put in place to facilitate driver merging which
would avoid the core and userspace issues that people are still raising
with the implementation and let people get on with at least the driver
side.

If wakelocks don't make the next merge window and there is a problem
with drivers then it'd be nice to get the stubs in so that the APIs are
present in subsystem trees for drivers to merge.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Thu, May 13, 2010 at 04:48:40PM -0700, Brian Swetland wrote:
> On Thu, May 13, 2010 at 4:36 PM, Mark Brown

> Current published trees are based on .32 (used for the coming-soon
> froyo release that's been in late QA for a while now) and forward
> development is moving to .34 post final (or in the case of tegra2,
> tracking .34-rc series as it happens).  We've been actively snapping
> up to track mainline since we started doing this around 2.6.16.  We'd

Yeah, I had noticed the development stuff was more up to date - it'll be
good once it gets out of QA and into general use since system
integrators do seem to pick up your new releases fairly quickly.

> *love* to be able to get more stuff sanely upstream instead of
> maintaining branches and rebasing every other mainline release or so.

Having greatly cut down the number of out of tree drivers I'm carrying I
can only say that it's great when it happens :)

> I'd love to have a separate discussion on using standard linux
> embedded audio for mobile devices -- one of my goals for 2010 is to
> try to migrate from our "one off" approach on MSM to making use of

Probably best to do that, this thread is already quite big enough
without going off on a tangent.  FWIW we can usually be found in
#alsa-soc on freenode as well as on the lists.  A couple of pointers
which might help your research, though:

> ALSA and standard interfaces.  I have a lot of questions about handing
> encoded data (mp3/aac/etc) that will be processed by the DSP, how to

This usually doesn't go through ALSA at all (the ALSA APIs can't cope
with variable bitrate data), the data currently goes via DSP specific
APIs and gets injected into the ALSA domain in much the same way as data
from the baseband.

> approach routing control, and how to best interact with the
> user/kernel interface, etc.

Routing control for embedded systems is done by exposing the routing
control to userspace via ALSA controls which can be set by apps - using
a GUI to configure the routes interactively is a massive usability win
in development.  Abstraction for generic user-visible apps is intended
to be handled by a layer on top of that:

	http://www.slimlogic.co.uk/?p=40

which is currently in development but I believe is expected to come to
fruition this year (Liam is driving this one).

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

[Mark Brown]

On Thu, May 13, 2010 at 04:48:40PM -0700, Brian Swetland wrote:
> On Thu, May 13, 2010 at 4:36 PM, Mark Brown

> Current published trees are based on .32 (used for the coming-soon
> froyo release that's been in late QA for a while now) and forward
> development is moving to .34 post final (or in the case of tegra2,
> tracking .34-rc series as it happens).  We've been actively snapping
> up to track mainline since we started doing this around 2.6.16.  We'd

Yeah, I had noticed the development stuff was more up to date - it'll be
good once it gets out of QA and into general use since system
integrators do seem to pick up your new releases fairly quickly.

> *love* to be able to get more stuff sanely upstream instead of
> maintaining branches and rebasing every other mainline release or so.

Having greatly cut down the number of out of tree drivers I'm carrying I
can only say that it's great when it happens :)

> I'd love to have a separate discussion on using standard linux
> embedded audio for mobile devices -- one of my goals for 2010 is to
> try to migrate from our "one off" approach on MSM to making use of

Probably best to do that, this thread is already quite big enough
without going off on a tangent.  FWIW we can usually be found in
#alsa-soc on freenode as well as on the lists.  A couple of pointers
which might help your research, though:

> ALSA and standard interfaces.  I have a lot of questions about handing
> encoded data (mp3/aac/etc) that will be processed by the DSP, how to

This usually doesn't go through ALSA at all (the ALSA APIs can't cope
with variable bitrate data), the data currently goes via DSP specific
APIs and gets injected into the ALSA domain in much the same way as data
from the baseband.

> approach routing control, and how to best interact with the
> user/kernel interface, etc.

Routing control for embedded systems is done by exposing the routing
control to userspace via ALSA controls which can be set by apps - using
a GUI to configure the routes interactively is a massive usability win
in development.  Abstraction for generic user-visible apps is intended
to be handled by a layer on top of that:

	http://www.slimlogic.co.uk/?p=40

which is currently in development but I believe is expected to come to
fruition this year (Liam is driving this one).

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Magnus Damm]

On Fri, May 14, 2010 at 6:47 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
>> On Thu, 13 May 2010, Tony Lindgren wrote:
>>
>> > The difference between echo mem > /sys/power/state and suspend blocks
>> > is that with suspend blocks the system keeps running.
>>
>> Irrelevant.  Paul wasn't talking about the suspend blockers; he was
>> talking about opportunistic suspend.  So what's the difference between
>> opportunistic suspend and "echo mem >/sys/power/state"?  Especially
>> when suspend blockers aren't being used?
>
> Opportunistic suspend is really trying to do runtime PM, see below.
>
>> > And that's why
>> > it should be handled by runtime power management instead.
>>
>> Runtime PM is not capable of freezing userspace and shutting down CPUs.
>> More or less by definition -- if it could then it wouldn't be "runtime"
>> any more, since the processor wouldn't be running.
>
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

I agree with you Tony. I thought shutting down CPUs for power
managment purposes could be done without freezing user space. At least
that's what we do today with SH-Mobile.

I don't dislike the idea of freezing a misbehaing user space app, but
I wonder if hardware platforms really need this. I think hardware
requirements and software requirements should be kept separated.

There seem to be some confusion regarding what Runtime PM can and can
not do. For SH-Mobile we use Runtime PM to manage the clocks and power
supply to on-chip I/O devices, and from CPU idle context we check the
state of the Runtime PM devices and decide what level of CPU deep
sleep we can enter. You can call this system CPU deep sleep if you'd
like depending on the dependencies are layed out on your hardware
platform.

For CPU deep sleep we more or less always stop the clock so we need to
put the memory in self-refresh to avoid loosing memory contents. In
some cases the deep sleep means that the power to the CPU core will be
cut, so a more advanced context save/restore path needs to be used.

Still not sure how the system wide suspend is different from Runtime
PM and CPUidle from the hardware perspective...

/ magnus

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

[Magnus Damm]

On Fri, May 14, 2010 at 6:47 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Alan Stern <stern@rowland.harvard.edu> [100513 14:32]:
>> On Thu, 13 May 2010, Tony Lindgren wrote:
>>
>> > The difference between echo mem > /sys/power/state and suspend blocks
>> > is that with suspend blocks the system keeps running.
>>
>> Irrelevant.  Paul wasn't talking about the suspend blockers; he was
>> talking about opportunistic suspend.  So what's the difference between
>> opportunistic suspend and "echo mem >/sys/power/state"?  Especially
>> when suspend blockers aren't being used?
>
> Opportunistic suspend is really trying to do runtime PM, see below.
>
>> > And that's why
>> > it should be handled by runtime power management instead.
>>
>> Runtime PM is not capable of freezing userspace and shutting down CPUs.
>> More or less by definition -- if it could then it wouldn't be "runtime"
>> any more, since the processor wouldn't be running.
>
> Not true. We are already powering off CPUs and rebooting them for
> at least omaps in every idle loop using cpuidle. The memory stays on.

I agree with you Tony. I thought shutting down CPUs for power
managment purposes could be done without freezing user space. At least
that's what we do today with SH-Mobile.

I don't dislike the idea of freezing a misbehaing user space app, but
I wonder if hardware platforms really need this. I think hardware
requirements and software requirements should be kept separated.

There seem to be some confusion regarding what Runtime PM can and can
not do. For SH-Mobile we use Runtime PM to manage the clocks and power
supply to on-chip I/O devices, and from CPU idle context we check the
state of the Runtime PM devices and decide what level of CPU deep
sleep we can enter. You can call this system CPU deep sleep if you'd
like depending on the dependencies are layed out on your hardware
platform.

For CPU deep sleep we more or less always stop the clock so we need to
put the memory in self-refresh to avoid loosing memory contents. In
some cases the deep sleep means that the power to the CPU core will be
cut, so a more advanced context save/restore path needs to be used.

Still not sure how the system wide suspend is different from Runtime
PM and CPUidle from the hardware perspective...

/ magnus

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
>
>> The system stays running because there's something to do. The system
>> won't suspend until all the processors hit the kernel idle loop and
>> the next_timer_interrupt_critical() returns nothing.
>
> At which point an application in a busy loop cripples you. I think we 
> could implement your suggestion more easily by just giving untrusted 
> applications an effectively infinite amount of timer slack, 
>
> but it still doesn't handle the case where an app behaves
> excrutiatingly badly.

Is design for exruciatingly bad apps a design requirement?

If so, opportunistic suspend + suspend blockers fails as well.  An app
could easily hold a suspend blocker during its entire execution
crippling PM.

Using opportunistic suspend may possibly allow you contain bad
apps/drivers, but at the cost of having to patch already working and
trusted apps and known-working kernel code with suspend blockers.

IMO, rather than accepting a solution that allows bad apps to run
wild, it would be much better to _continue_ focus on tools for finding
and containing bad apps.  This approach has the added bonus of solving
problems on *every* linux-based system, not just Android.

Kevin

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
>
>> The system stays running because there's something to do. The system
>> won't suspend until all the processors hit the kernel idle loop and
>> the next_timer_interrupt_critical() returns nothing.
>
> At which point an application in a busy loop cripples you. I think we 
> could implement your suggestion more easily by just giving untrusted 
> applications an effectively infinite amount of timer slack, 
>
> but it still doesn't handle the case where an app behaves
> excrutiatingly badly.

Is design for exruciatingly bad apps a design requirement?

If so, opportunistic suspend + suspend blockers fails as well.  An app
could easily hold a suspend blocker during its entire execution
crippling PM.

Using opportunistic suspend may possibly allow you contain bad
apps/drivers, but at the cost of having to patch already working and
trusted apps and known-working kernel code with suspend blockers.

IMO, rather than accepting a solution that allows bad apps to run
wild, it would be much better to _continue_ focus on tools for finding
and containing bad apps.  This approach has the added bonus of solving
problems on *every* linux-based system, not just Android.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Magnus Damm <magnus.damm@gmail.com> writes:

> Still not sure how the system wide suspend is different from Runtime
> PM and CPUidle from the hardware perspective...

At least on OMAP and other embedded SoCs I'm familiar with, there is
no difference from the hardware perspecitve.

However, I understand that on ACPI-based systems, there are low-power
that are only reachable via system-wide suspsend since ACPI does not
provide the kernel with fine-grained control to hit those states
during idle.

That being said, I don't think this should be an issue since
opportunistic suspend is currently targetted primarily at embedded HW
which has much more fine-grained power control than traditional
ACPI-based systems.

To me the only real difference between system-wide suspend and runtime
PM + CPUidle is the freezing of userspace.

As has been discussed elsewhere in this discussion, any alternative
solution must address the freezing/idling of userspace.  

Kevin

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

[Kevin Hilman]

Magnus Damm <magnus.damm@gmail.com> writes:

> Still not sure how the system wide suspend is different from Runtime
> PM and CPUidle from the hardware perspective...

At least on OMAP and other embedded SoCs I'm familiar with, there is
no difference from the hardware perspecitve.

However, I understand that on ACPI-based systems, there are low-power
that are only reachable via system-wide suspsend since ACPI does not
provide the kernel with fine-grained control to hit those states
during idle.

That being said, I don't think this should be an issue since
opportunistic suspend is currently targetted primarily at embedded HW
which has much more fine-grained power control than traditional
ACPI-based systems.

To me the only real difference between system-wide suspend and runtime
PM + CPUidle is the freezing of userspace.

As has been discussed elsewhere in this discussion, any alternative
solution must address the freezing/idling of userspace.  

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> > 
> > > Because someone would have to remove suspend blockers (or rather wakelocks)
> > > from the drivers, test that they work correctly without suspend blockers and
> > > submit the modified versions.  Going forward, every party responsible for such
> > > a driver would have to maintain an out-of-tree version with suspend blockers
> > > (or wakelocks) anyway, so the incentive to do that is zero.
> > 
> > They should work without wakelock since wakelock are optional .. I mean
> > there's nothing in suspend blockers I've seen that indicates it's
> > required for some drivers to work. So it's just a matter of patching out
> > the wakelocks, with no need to re-test anything.
> > 
> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.
> 
> Sorry, but it doesn't seem to work that way.  Look at the large number
> of out-of-tree android device drivers that remain sitting there because
> of the lack of this interface being in the kernel.

I don't think that's due to this interface tho. During your CELF
presentation you noted several bits of code that could go in right now
but haven't (and still haven't as far as I've seen). I'm actively
pushing code related to Android (with wakelocks removed).. Putting a
wakelock contingency on everything to me doesn't make much sense.

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

That's not totally true. For example the MMC driver had wakelocks (I
think, or for sure mmc core does), and the MMC driver has been tested
for G1 and works fine so far without them. I have code that is queued
for my tree that will enable MMC on G1. I can merge Nexus one support
through my tree also which would allow all the drivers for that device
to eventually be used.

With that device support in mainline then those drivers become nice
things to have with or with out wakelocks. You don't need wakelocks to
run Debian or anything else except Android.

Daniel

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

[Daniel Walker]

On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote:
> On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
> > 
> > > Because someone would have to remove suspend blockers (or rather wakelocks)
> > > from the drivers, test that they work correctly without suspend blockers and
> > > submit the modified versions.  Going forward, every party responsible for such
> > > a driver would have to maintain an out-of-tree version with suspend blockers
> > > (or wakelocks) anyway, so the incentive to do that is zero.
> > 
> > They should work without wakelock since wakelock are optional .. I mean
> > there's nothing in suspend blockers I've seen that indicates it's
> > required for some drivers to work. So it's just a matter of patching out
> > the wakelocks, with no need to re-test anything.
> > 
> > You get the driver mainlined, then maintain a small patch to add
> > wakelocks. Not hard at all , with lots of incentive to do so since you
> > don't have to maintain such a large block of code out of tree.
> 
> Sorry, but it doesn't seem to work that way.  Look at the large number
> of out-of-tree android device drivers that remain sitting there because
> of the lack of this interface being in the kernel.

I don't think that's due to this interface tho. During your CELF
presentation you noted several bits of code that could go in right now
but haven't (and still haven't as far as I've seen). I'm actively
pushing code related to Android (with wakelocks removed).. Putting a
wakelock contingency on everything to me doesn't make much sense.

> Also note that such a driver, without wakelocks, would never get tested,
> and so, things start quickly diverging.

That's not totally true. For example the MMC driver had wakelocks (I
think, or for sure mmc core does), and the MMC driver has been tested
for G1 and works fine so far without them. I have code that is queued
for my tree that will enable MMC on G1. I can merge Nexus one support
through my tree also which would allow all the drivers for that device
to eventually be used.

With that device support in mainline then those drivers become nice
things to have with or with out wakelocks. You don't need wakelocks to
run Debian or anything else except Android.

Daniel

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

[Paul Walmsley]

Hello,

Please forgive the delay in commenting - I am just now catching up on 
these huge E-mail threads;

On Mon, 3 May 2010, Alan Stern wrote:

> So for example, runtime PM cannot be used to put the system into an S3 
> sleep state.

This is not quite true.  Runtime PM, *in conjunction with CPUIdle,* can 
put many current embedded Linux systems into not just S3, but actually S5.

This is done right now on OMAP in mainline Linux[1].  (S5 is called "C6" 
in that codebase, since the CPUIdle governor is used - this is a 
misnomer.)

This approach allows the system to wake up, or stay running, as requested 
by the timer subsystem, or the scheduler.  No suspend-block-like API is 
needed.

Several consumer-market Linux devices have already shipped using this 
mechanism.

> The simplest example is that suspend blockers can be used to control 
> whether or not the CPU shuts down, whereas runtime PM can't.

Runtime PM still needs to be combined with some sort of governor to 
control not only CPU power states, but also system power states.  CPUIdle 
works pretty well as a system power governor for a single-CPU system, but 
is admittedly something of a hack[2].

Going forward, some sort of basic, system-wide governor is a cleaner 
design[3].  But since the "opportunistic suspend" governor proposed in 
patch 1 ignores timer expiries and the scheduler runqueue, and then hacks 
around that decision by inserting suspend-block calls into code that would 
otherwise work normally, it's not a good approach.


- Paul



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

3. ibid.

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

[Paul Walmsley]

Hello,

On Mon, 3 May 2010, Mark Brown wrote:

> I fully agree with this.  We do need to ensure that a runtime PM based
> system can suspend the CPU core and RAM as well as system suspend can
> but that seems doable.

It is already possible on OMAP-based systems running mainline Linux[1].

Consumer-market Linux devices that do this have been available since at 
least 2007[2].

Intel is pursing a similar approach with Moorestown[3], since "echo mem > 
/sys/power/state" is much more inflexible than an idle-loop-based system 
"suspend."  

Going forward, ACPI-style centralized power management is dead.  Like 
"echo mem > /sys/power/state", ACPI PM is too inflexible for most 
use-cases, and so wastes power because the system must be kept in a 
higher-power state than necessary.  Even Intel is abandoning ACPI[4].


- Paul


1. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri May 14 
   10:22:05 PDT 2010: 
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025530.html

2. http://en.wikipedia.org/wiki/Nokia_N800

3. German Monroy's presentation at ELC 2010, "Wake-ups Effect on Idle 
   Power for Intel's Moorestown MID and Smartphone Platform":
   http://elinux.org/images/0/07/Effect_of_wakeups_on_Moorestown_power.pdf

4. Jacob Pan's presentation at ELC 2010, "Porting the Linux Kernel to x86 
   MID Platforms": http://elinux.org/images/e/ee/Jacob-Pan-x86MID-elc2010.pdf

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

[Paul Walmsley]

Hi,

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

> However, the real question is whether or not the opportunistic suspend 
> feature is worth adding to the kernel as such and I think it is.
> 
> To me, it doesn't duplicate the runtime PM framework which is aimed at 
> the power management of individual devices rather than the system as a 
> whole.

Runtime PM is also aimed at system power management as a whole. The 
difference is that it approaches the problem from the bottom up (i.e., the 
activity level of the actual hardware devices) rather than from the top 
down (i.e., "echo mem > /sys/power/state").

In bottom-up approaches, like runtime PM, system-level power management 
becomes a very small fraction of the total power management problem.  It 
is only possible to power down that small fraction once all devices, and 
the clock and power domains/islands that contain those devices, become 
idle.  ("Devices" here is used in a hardware sense, and thus includes the 
CPU.)

A bottom-up approach like runtime PM allows parts of the system can be 
powered off when they are not in use.  This is important on systems that 
have more levels of power management hierarchy than just "device" and 
"system," as is the case on modern SoCs like Renesas SH-Mobile, Intel 
Moorestown[1], and TI OMAP[2].  These chips group devices into sets of 
multiple power domains/islands, which can be controlled independently.

Once the devices, including the CPU, are idle, the system idle loop can be 
entered to determine what power level the system should be programmed to 
enter.  At this point, system-level power management only controls a small 
fraction, maybe 1% or 2%, of the chipset that is not associated with any 
devices; along with any board-level resources that the chipset depends on 
to function that are power-controllable, such as the system high-frequency 
clock oscillator[3].

No heavyweight process of iterating through the device tree to suspend 
them is needed at this point, as with a top-down power management approach 
like Android opportunistic suspend, since the system already knows that 
the devices are idle.

Of course, to determine what system-level power state to enter, there 
needs to be some sort of governor to handle these system-level power 
decisions.  On mainline Linux OMAP, we use the CPUIdle governor to do 
this[4].  This is not the cleanest possible choice[5], but works pretty 
well in the absence of a system-level governor.

The Linux OMAP CPUIdle code considers the next timer expiration and any PM 
constraints[6].  Based on the required wakeup latency and constraints, the 
PM code[7][8] programs the power-controllable parts of the system to enter 
one of several power states.  The CPU then enters WFI (wait-for-interrupt, 
like x86 HLT), and the SoC power management controller implements the 
system power transition, now that all on-chip devices are idle.

All of this is already implemented in mainline Linux code[9].  Devices 
based on this code have already shipped from multiple 
vendors[10][11][12][13]. These devices have small batteries and long 
use-times, which attests to the performance of this approach.

Since this approach does not "echo mem > /sys/power/state", it honors the 
existing Linux timer and scheduler subsystems, and so this is all possible 
without systemic modification of the kernel code tree or device drivers, 
in contrast to the current Android proposal under consideration.



- Paul


1. Jacob Pan's presentation at ELC 2010, "Porting the Linux Kernel to x86 
   MID Platforms": 
   http://elinux.org/images/e/ee/Jacob-Pan-x86MID-elc2010.pdf

2. OMAP35x Technical Reference Manual Rev. F, Figure 4-16 "Device Power 
   Domains": http://www.ti.com/litv/pdf/spruf98f

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

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

6. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/omap-pm.h;h=3ee41d7114929d771cadbb9f02191fd16c5b5abe;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e

7. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/pm24xx.c;h=374299ea7aded92999b5e54439e43f017806ce4d;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e

8. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/pm34xx.c;h=ea0000bc5358e196df58e88da3f54dd71f0a4706;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e

9. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/arm/mach-omap2;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e

10. http://en.wikipedia.org/wiki/Palm_Pre

11. http://en.wikipedia.org/wiki/N800

12. http://en.wikipedia.org/wiki/N810

13. http://en.wikipedia.org/wiki/N900

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 0/8] Suspend block api (version 6)

[Paul Walmsley]

Hello,

On Mon, 3 May 2010, Matthew Garrett wrote:

> I agree that the runtime scenario is a far more appealing one from an 
> aesthetic standpoint, but so far we don't have a very compelling 
> argument for dealing with the starting and stopping of userspace.

The problem of how to start and stop (some) userspace is not specifically 
system power management-related, nor top-down, /sys/power/state-suspend 
related.  PM is just one potential user.

It's hard to see how the Android opportunistic suspend approach would be 
useful for the other use-cases (e.g., checkpoint/restart).  On the other 
hand, it's easier to see how something like freezer cgroups could be 
useful for system power management and checkpoint/restart.

And the Android opportunistic suspend patches have design problems - they 
definitely do not come for free, as noted in [1][2][3] (among others' 
comments).


- Paul


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

2. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:13:50 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18657

3. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:27:56 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18658

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

[Paul Walmsley]

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


Hello,

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

> No, suspend blockers are mostly used to ensure wakeup events are not
> ignored, and to ensure tasks triggered by these wakeup events
> complete.

Standard Linux systems don't need these, because the scheduler just keeps 
the system running as long as there is work to be done.

Suspend-blocks are only needed because patch 1's opportunistic suspend 
governor tries to suspend the system even when the scheduler indicates 
that there is work to be done.  That decision requires all kinds of hacks 
throughout the codebase [1][2].


- Paul


1. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:27:56 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18658

2. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:13:50 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18657


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

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

[Matthew Garrett]

On Fri, May 14, 2010 at 02:20:43PM -0600, Paul Walmsley wrote:
> Hello,
> 
> On Mon, 3 May 2010, Matthew Garrett wrote:
> 
> > I agree that the runtime scenario is a far more appealing one from an 
> > aesthetic standpoint, but so far we don't have a very compelling 
> > argument for dealing with the starting and stopping of userspace.
> 
> The problem of how to start and stop (some) userspace is not specifically 
> system power management-related, nor top-down, /sys/power/state-suspend 
> related.  PM is just one potential user.
>
> It's hard to see how the Android opportunistic suspend approach would be 
> useful for the other use-cases (e.g., checkpoint/restart).  On the other 
> hand, it's easier to see how something like freezer cgroups could be 
> useful for system power management and checkpoint/restart.

And difficult to see how to implement something using freezer cgroups 
that actually works in this case. Look, I don't want to sound like I 
have a one-track mind or anything, but all of these arguments would be 
significantly more compelling if someone would actually provide a 
concrete implementation proposal that deals with the set of use-cases 
that Google's implementation does and which doesn't make anyone cry. 
Otherwise the immeasurably most likely outcome is that this code gets 
merged and we get to live with it.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Paul Walmsley]

Hello,

On Tue, 4 May 2010, Matthew Garrett wrote:

> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
> 
> > Please forgive the ignorance of ACPI (in embedded, we thankfully live
> > in magical world without ACPI) but doesn't that already happen with
> > CPUidle and C-states?  I think of CPUidle as basically runtime PM for
> > the CPU.  IOW, runtime PM manages the devices, CPUidle manages the CPU
> > (via C-states), resulting in dynaimc PM for the entire system.  What
> > am I missing?
> 
> ACPI doesn't provide any functionality for cutting power to most devices 
> other than shifting into full system suspend.

ACPI may not, but the vast majority of ACPI systems are paired with PCI 
buses, or buses that emulate PCI buses; and PCI devices can implement 
device power control through the PCI Power Management capability. On my 
2-year old ThinkPad, 13 of the 24 devices do, according to lspci.

Many Linux device drivers already use PCI D-states to support a 
rudimentary form of runtime PM:

[paul@twilight current]$ fgrep -r pci_set_power_state drivers/ | cut -d: 
-f1 | sort -u
drivers/ata/ata_piix.c
drivers/ata/libata-core.c
drivers/ata/pata_macio.c
drivers/block/cciss.c
drivers/char/agp/amd64-agp.c
drivers/char/agp/amd-k7-agp.c
drivers/char/agp/ati-agp.c
drivers/char/agp/nvidia-agp.c
drivers/char/agp/sis-agp.c
drivers/char/agp/via-agp.c
drivers/firewire/ohci.c
drivers/gpio/bt8xxgpio.c
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/nouveau/nouveau_drv.c
drivers/gpu/drm/radeon/radeon_device.c
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
drivers/i2c/busses/i2c-i801.c
drivers/ide/delkin_cb.c
drivers/ide/sc1200.c
drivers/ide/setup-pci.c
drivers/ieee1394/ohci1394.c
drivers/media/video/bt8xx/bttv-driver.c
drivers/media/video/cx88/cx88-mpeg.c
drivers/media/video/cx88/cx88-video.c
drivers/media/video/saa7134/saa7134-core.c
drivers/memstick/host/jmb38x_ms.c
drivers/message/fusion/mptbase.c
drivers/misc/cb710/core.c
drivers/misc/tifm_7xx1.c
drivers/mmc/host/sdhci-pci.c
drivers/mmc/host/via-sdmmc.c
drivers/net/3c59x.c
drivers/net/8139cp.c
drivers/net/8139too.c
drivers/net/amd8111e.c
drivers/net/atl1c/atl1c_main.c
drivers/net/atl1e/atl1e_main.c
drivers/net/atlx/atl1.c
drivers/net/atlx/atl2.c
drivers/net/benet/be_main.c
drivers/net/e1000/e1000_main.c
drivers/net/e1000e/netdev.c
drivers/net/e100.c
drivers/net/forcedeth.c
drivers/net/igb/igb_main.c
drivers/net/irda/vlsi_ir.c
drivers/net/ixgbe/ixgbe_main.c
drivers/net/jme.c
drivers/net/ksz884x.c
drivers/net/myri10ge/myri10ge.c
drivers/net/ne2k-pci.c
drivers/net/netxen/netxen_nic_main.c
drivers/net/pci-skeleton.c
drivers/net/pcnet32.c
drivers/net/qlcnic/qlcnic_main.c
drivers/net/qlge/qlge_main.c
drivers/net/r8169.c
drivers/net/sc92031.c
drivers/net/sfc/efx.c
drivers/net/sis900.c
drivers/net/skge.c
drivers/net/sky2.c
drivers/net/smsc9420.c
drivers/net/starfire.c
drivers/net/tc35815.c
drivers/net/tg3.c
drivers/net/tulip/dmfe.c
drivers/net/tulip/tulip_core.c
drivers/net/tulip/uli526x.c
drivers/net/typhoon.c
drivers/net/via-rhine.c
drivers/net/via-velocity.c
drivers/net/vmxnet3/vmxnet3_drv.c
drivers/net/wireless/adm8211.c
drivers/net/wireless/airo.c
drivers/net/wireless/ath/ath9k/pci.c
drivers/net/wireless/hostap/hostap_pci.c
drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2200.c
drivers/net/wireless/iwlwifi/iwl-core.c
drivers/net/wireless/orinoco/orinoco_pci.h
drivers/net/wireless/p54/p54pci.c
drivers/net/wireless/prism54/islpci_hotplug.c
drivers/net/wireless/rt2x00/rt2x00pci.c
drivers/net/wireless/rtl818x/rtl8180_dev.c
drivers/parport/parport_serial.c
drivers/pci/pci-acpi.c
drivers/pci/pci.c
drivers/pci/pci-driver.c
drivers/pcmcia/yenta_socket.c
drivers/scsi/3w-9xxx.c
drivers/scsi/3w-sas.c
drivers/scsi/aic7xxx/aic79xx_osm_pci.c
drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
drivers/scsi/aic7xxx/aic7xxx_pci.c
drivers/scsi/hpsa.c
drivers/scsi/lpfc/lpfc_init.c
drivers/scsi/megaraid/megaraid_sas.c
drivers/scsi/mpt2sas/mpt2sas_scsih.c
drivers/scsi/nsp32.c
drivers/scsi/pm8001/pm8001_init.c
drivers/scsi/pmcraid.c
drivers/serial/8250_pci.c
drivers/serial/serial_txx9.c
drivers/spi/dw_spi_pci.c
drivers/ssb/pcihost_wrapper.c
drivers/staging/crystalhd/crystalhd_lnx.c
drivers/staging/rt2860/pci_main_dev.c
drivers/staging/rtl8187se/r8180_core.c
drivers/staging/rtl8192e/r8192_pm.c
drivers/staging/sm7xx/smtcfb.c
drivers/staging/vt6655/device_main.c
drivers/usb/gadget/langwell_udc.c
drivers/video/arkfb.c
drivers/video/aty/aty128fb.c
drivers/video/aty/atyfb_base.c
drivers/video/aty/radeon_pm.c
drivers/video/i810/i810_main.c
drivers/video/nvidia/nvidia.c
drivers/video/s3fb.c
drivers/video/savage/savagefb_driver.c
drivers/video/vt8623fb.c
drivers/virtio/virtio_pci.c


- Paul

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

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

> On Thursday 13 May 2010, Tony Lindgren wrote:
>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:

[...]

>>  
>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>> > differently, while there's a growing number of out-of-tree drivers depending
>> > on this framework.  We need those drivers in and because we don't have any
>> > viable alternative at hand, we have no good reason to reject it.
>> 
>> Nothing is preventing merging the drivers can be merged without
>> these calls.
>
> And yet, there _is_ a growing nuber of drivers that don't get merge because
> of that.  That's _reality_.  Are you going to discuss with facts, or what?

It may be reality, but IMO, "preventing other drivers" isn't a good
*technical* argument for merging a feature.  It feels like these "for
the 'good' of the community" arguments are being used to trump the
technical arguments.  Maybe we need to keep the separate.

Distros (especially embedded ones) have long had out of tree features
that create barriers to getting other drivers upstream.  While it
might be nice to see all those features upstream, no one has argued
that they should get merged simply because they create a barrier.  Each
feature should be merged on its own technical merit.

Kevin

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

[Kevin Hilman]

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

> On Thursday 13 May 2010, Tony Lindgren wrote:
>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:

[...]

>>  
>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>> > differently, while there's a growing number of out-of-tree drivers depending
>> > on this framework.  We need those drivers in and because we don't have any
>> > viable alternative at hand, we have no good reason to reject it.
>> 
>> Nothing is preventing merging the drivers can be merged without
>> these calls.
>
> And yet, there _is_ a growing nuber of drivers that don't get merge because
> of that.  That's _reality_.  Are you going to discuss with facts, or what?

It may be reality, but IMO, "preventing other drivers" isn't a good
*technical* argument for merging a feature.  It feels like these "for
the 'good' of the community" arguments are being used to trump the
technical arguments.  Maybe we need to keep the separate.

Distros (especially embedded ones) have long had out of tree features
that create barriers to getting other drivers upstream.  While it
might be nice to see all those features upstream, no one has argued
that they should get merged simply because they create a barrier.  Each
feature should be merged on its own technical merit.

Kevin

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

[Paul Walmsley]

Hello,

On Tue, 4 May 2010, Alan Stern wrote:

> Another thing that Kevin is missing: There is more to the system than
> the devices and the CPU.  For example: RAM, an embedded controller (on
> modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
> for the CPU and the devices won't power-down these things, but system
> PM will.

No.  A dynamic PM-based kernel can, and in the case of the mainline Linux 
code running on OMAP, does, power down RAM[1] and the power supply[2].

Since the CPU is already powered off when it is time for this to happen, 
so this is done under autonomous hardware control.  We currently use 
CPUIdle[3] to choose whether to program the SoC hardware to enable this 
autonomous power control before it goes off, depending on the required 
wakeup latency for timers and PM constraints.


- Paul


1. (technically, put the RAM into self-refresh mode): 
   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/sleep34xx.S/sleep34xx.S;h=d522cd70bf53485d0a3af2453845777e3a89edd7;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e#l204

2. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/sleep34xx.S/sleep34xx.S;h=d522cd70bf53485d0a3af2453845777e3a89edd7;hb=4fc4c3ce0dc1096cbd0daa3fe8f6905cbec2b87e#l204

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Friday 14 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Thursday 13 May 2010, Tony Lindgren wrote:
> >> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> 
> [...]
> 
> >>  
> >> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >> > differently, while there's a growing number of out-of-tree drivers depending
> >> > on this framework.  We need those drivers in and because we don't have any
> >> > viable alternative at hand, we have no good reason to reject it.
> >> 
> >> Nothing is preventing merging the drivers can be merged without
> >> these calls.
> >
> > And yet, there _is_ a growing nuber of drivers that don't get merge because
> > of that.  That's _reality_.  Are you going to discuss with facts, or what?
> 
> It may be reality, but IMO, "preventing other drivers" isn't a good
> *technical* argument for merging a feature.  It feels like these "for
> the 'good' of the community" arguments are being used to trump the
> technical arguments.  Maybe we need to keep the separate.
> 
> Distros (especially embedded ones) have long had out of tree features
> that create barriers to getting other drivers upstream.  While it
> might be nice to see all those features upstream, no one has argued
> that they should get merged simply because they create a barrier.  Each
> feature should be merged on its own technical merit.

Well, this is very much like the selinux vs apparmour (& friends) issue.
One can argue we need only one of them, but in fact we're not worse off having
both in.

The feature is not technically unacceptable to me and since having it in
would potentially make it easier to merge quite a few drivers, I regard that as
a good enough argument for.  YMMV.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Friday 14 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Thursday 13 May 2010, Tony Lindgren wrote:
> >> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> 
> [...]
> 
> >>  
> >> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >> > differently, while there's a growing number of out-of-tree drivers depending
> >> > on this framework.  We need those drivers in and because we don't have any
> >> > viable alternative at hand, we have no good reason to reject it.
> >> 
> >> Nothing is preventing merging the drivers can be merged without
> >> these calls.
> >
> > And yet, there _is_ a growing nuber of drivers that don't get merge because
> > of that.  That's _reality_.  Are you going to discuss with facts, or what?
> 
> It may be reality, but IMO, "preventing other drivers" isn't a good
> *technical* argument for merging a feature.  It feels like these "for
> the 'good' of the community" arguments are being used to trump the
> technical arguments.  Maybe we need to keep the separate.
> 
> Distros (especially embedded ones) have long had out of tree features
> that create barriers to getting other drivers upstream.  While it
> might be nice to see all those features upstream, no one has argued
> that they should get merged simply because they create a barrier.  Each
> feature should be merged on its own technical merit.

Well, this is very much like the selinux vs apparmour (& friends) issue.
One can argue we need only one of them, but in fact we're not worse off having
both in.

The feature is not technically unacceptable to me and since having it in
would potentially make it easier to merge quite a few drivers, I regard that as
a good enough argument for.  YMMV.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
>> On Thursday 13 May 2010, Tony Lindgren wrote:
>>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
>
> [...]
>
>>>  
>>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>>> > differently, while there's a growing number of out-of-tree drivers depending
>>> > on this framework.  We need those drivers in and because we don't have any
>>> > viable alternative at hand, we have no good reason to reject it.
>>> 
>>> Nothing is preventing merging the drivers can be merged without
>>> these calls.
>>
>> And yet, there _is_ a growing nuber of drivers that don't get merge because
>> of that.  That's _reality_.  Are you going to discuss with facts, or what?
>
> It may be reality, but IMO, "preventing other drivers" isn't a good
> *technical* argument for merging a feature.  It feels like these "for
> the 'good' of the community" arguments are being used to trump the
> technical arguments.  Maybe we need to keep the separate.

To continue along the "for the good of the community" path...

If it truly is the lack of a suspend blocker API that is preventing
the merge of these out of tree drivers, I second Mark's proposal[1] to
merge a noop version of the API while the technical issues continue to
be discussed.  Then we would see how many drivers get submitted and
merged.

Personally, I suspect that lack of this feature is not the real
obstacle to getting these out-of-tree drivers upstream.  Having this
API upstream will not change the product schedules and corporate
cultures that have prevented code from making its way upstream.

Kevin

[1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025501.html

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

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
>> On Thursday 13 May 2010, Tony Lindgren wrote:
>>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
>
> [...]
>
>>>  
>>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>>> > differently, while there's a growing number of out-of-tree drivers depending
>>> > on this framework.  We need those drivers in and because we don't have any
>>> > viable alternative at hand, we have no good reason to reject it.
>>> 
>>> Nothing is preventing merging the drivers can be merged without
>>> these calls.
>>
>> And yet, there _is_ a growing nuber of drivers that don't get merge because
>> of that.  That's _reality_.  Are you going to discuss with facts, or what?
>
> It may be reality, but IMO, "preventing other drivers" isn't a good
> *technical* argument for merging a feature.  It feels like these "for
> the 'good' of the community" arguments are being used to trump the
> technical arguments.  Maybe we need to keep the separate.

To continue along the "for the good of the community" path...

If it truly is the lack of a suspend blocker API that is preventing
the merge of these out of tree drivers, I second Mark's proposal[1] to
merge a noop version of the API while the technical issues continue to
be discussed.  Then we would see how many drivers get submitted and
merged.

Personally, I suspect that lack of this feature is not the real
obstacle to getting these out-of-tree drivers upstream.  Having this
API upstream will not change the product schedules and corporate
cultures that have prevented code from making its way upstream.

Kevin

[1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025501.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Friday 14 May 2010, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >
> >> On Thursday 13 May 2010, Tony Lindgren wrote:
> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> >
> > [...]
> >
> >>>  
> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >>> > differently, while there's a growing number of out-of-tree drivers depending
> >>> > on this framework.  We need those drivers in and because we don't have any
> >>> > viable alternative at hand, we have no good reason to reject it.
> >>> 
> >>> Nothing is preventing merging the drivers can be merged without
> >>> these calls.
> >>
> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
> >
> > It may be reality, but IMO, "preventing other drivers" isn't a good
> > *technical* argument for merging a feature.  It feels like these "for
> > the 'good' of the community" arguments are being used to trump the
> > technical arguments.  Maybe we need to keep the separate.
> 
> To continue along the "for the good of the community" path...
> 
> If it truly is the lack of a suspend blocker API that is preventing
> the merge of these out of tree drivers, I second Mark's proposal[1] to
> merge a noop version of the API while the technical issues continue to
> be discussed.

I'm against that, sorry.

> Then we would see how many drivers get submitted and merged.
>
> Personally, I suspect that lack of this feature is not the real
> obstacle to getting these out-of-tree drivers upstream.  Having this
> API upstream will not change the product schedules and corporate
> cultures that have prevented code from making its way upstream.

But apparently it is considered as a suitable excuse.

Rafael

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

[Rafael J. Wysocki]

On Friday 14 May 2010, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >
> >> On Thursday 13 May 2010, Tony Lindgren wrote:
> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> >
> > [...]
> >
> >>>  
> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >>> > differently, while there's a growing number of out-of-tree drivers depending
> >>> > on this framework.  We need those drivers in and because we don't have any
> >>> > viable alternative at hand, we have no good reason to reject it.
> >>> 
> >>> Nothing is preventing merging the drivers can be merged without
> >>> these calls.
> >>
> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
> >
> > It may be reality, but IMO, "preventing other drivers" isn't a good
> > *technical* argument for merging a feature.  It feels like these "for
> > the 'good' of the community" arguments are being used to trump the
> > technical arguments.  Maybe we need to keep the separate.
> 
> To continue along the "for the good of the community" path...
> 
> If it truly is the lack of a suspend blocker API that is preventing
> the merge of these out of tree drivers, I second Mark's proposal[1] to
> merge a noop version of the API while the technical issues continue to
> be discussed.

I'm against that, sorry.

> Then we would see how many drivers get submitted and merged.
>
> Personally, I suspect that lack of this feature is not the real
> obstacle to getting these out-of-tree drivers upstream.  Having this
> API upstream will not change the product schedules and corporate
> cultures that have prevented code from making its way upstream.

But apparently it is considered as a suitable excuse.

Rafael

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

[Arve Hjønnevåg]

On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hello,
>
> On Mon, 3 May 2010, Arve Hjønnevåg wrote:
>
>> No, suspend blockers are mostly used to ensure wakeup events are not
>> ignored, and to ensure tasks triggered by these wakeup events
>> complete.
>
> Standard Linux systems don't need these,

If you don't want to lose wakeup events they do. Standard Linux
systems support suspend, but since they usually don't have a lot of
wakeup events you don't run into a lot of problems.

> because the scheduler just keeps
> the system running as long as there is work to be done.
>

That is only true if you never use suspend.

> Suspend-blocks are only needed because patch 1's opportunistic suspend
> governor tries to suspend the system even when the scheduler indicates
> that there is work to be done.  That decision requires all kinds of hacks
> throughout the codebase [1][2].
>
>
> - Paul
>
>
> 1. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
>   May 2010 00:27:56 -0600:
>   http://permalink.gmane.org/gmane.linux.power-management.general/18658
>
> 2. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
>   May 2010 00:13:50 -0600:
>   http://permalink.gmane.org/gmane.linux.power-management.general/18657
>
>


-- 
Arve Hjønnevåg

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Fri, May 14, 2010 at 02:20:43PM -0600, Paul Walmsley wrote:
>> Hello,
>> 
>> On Mon, 3 May 2010, Matthew Garrett wrote:
>> 
>> > I agree that the runtime scenario is a far more appealing one from an 
>> > aesthetic standpoint, but so far we don't have a very compelling 
>> > argument for dealing with the starting and stopping of userspace.
>> 
>> The problem of how to start and stop (some) userspace is not specifically 
>> system power management-related, nor top-down, /sys/power/state-suspend 
>> related.  PM is just one potential user.
>>
>> It's hard to see how the Android opportunistic suspend approach would be 
>> useful for the other use-cases (e.g., checkpoint/restart).  On the other 
>> hand, it's easier to see how something like freezer cgroups could be 
>> useful for system power management and checkpoint/restart.
>
> And difficult to see how to implement something using freezer cgroups 
> that actually works in this case. Look, I don't want to sound like I 
> have a one-track mind or anything, but all of these arguments would be 
> significantly more compelling if someone would actually provide a 
> concrete implementation proposal that deals with the set of use-cases 
> that Google's implementation does and which doesn't make anyone cry. 

That might be possible if this "set of use-cases" was available
someplace.  At least I haven't seen it, and would expect it to be in
the docs included with patch 1.

Another likely reason that that there hasn't been an alternate
proposal (at least from some of us that are raising concerns) is
because we already have a working solution to dynamic, system-wide PM
that is 1) already in mainline and 2) shipping on consumer devices
with very strict power budgets (as already pointed out in detail by
Paul[2].)

Yes, "excruciatingly bad" apps can kill PM on these systems since
anyone can write apps, but the same is true on an opporunistic-suspend
based system since any app could hold a suspend blocker whenever it
wants.

Kevin

[1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025415.html
[2] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025532.html

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

[Arve Hjønnevåg]

On Fri, May 14, 2010 at 3:32 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Matthew Garrett <mjg@redhat.com> writes:
>
>> On Fri, May 14, 2010 at 02:20:43PM -0600, Paul Walmsley wrote:
>>> Hello,
>>>
>>> On Mon, 3 May 2010, Matthew Garrett wrote:
>>>
>>> > I agree that the runtime scenario is a far more appealing one from an
>>> > aesthetic standpoint, but so far we don't have a very compelling
>>> > argument for dealing with the starting and stopping of userspace.
>>>
>>> The problem of how to start and stop (some) userspace is not specifically
>>> system power management-related, nor top-down, /sys/power/state-suspend
>>> related.  PM is just one potential user.
>>>
>>> It's hard to see how the Android opportunistic suspend approach would be
>>> useful for the other use-cases (e.g., checkpoint/restart).  On the other
>>> hand, it's easier to see how something like freezer cgroups could be
>>> useful for system power management and checkpoint/restart.
>>
>> And difficult to see how to implement something using freezer cgroups
>> that actually works in this case. Look, I don't want to sound like I
>> have a one-track mind or anything, but all of these arguments would be
>> significantly more compelling if someone would actually provide a
>> concrete implementation proposal that deals with the set of use-cases
>> that Google's implementation does and which doesn't make anyone cry.
>
> That might be possible if this "set of use-cases" was available
> someplace.  At least I haven't seen it, and would expect it to be in
> the docs included with patch 1.
>
> Another likely reason that that there hasn't been an alternate
> proposal (at least from some of us that are raising concerns) is
> because we already have a working solution to dynamic, system-wide PM
> that is 1) already in mainline and 2) shipping on consumer devices
> with very strict power budgets (as already pointed out in detail by
> Paul[2].)
>
> Yes, "excruciatingly bad" apps can kill PM on these systems since
> anyone can write apps, but the same is true on an opporunistic-suspend
> based system since any app could hold a suspend blocker whenever it
> wants.
>

No, apps need permission to block suspend.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

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

> On Friday 14 May 2010, Kevin Hilman wrote:
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>> 
>> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> >
>> >> On Thursday 13 May 2010, Tony Lindgren wrote:
>> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
>> >
>> > [...]
>> >
>> >>>  
>> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>> >>> > differently, while there's a growing number of out-of-tree drivers depending
>> >>> > on this framework.  We need those drivers in and because we don't have any
>> >>> > viable alternative at hand, we have no good reason to reject it.
>> >>> 
>> >>> Nothing is preventing merging the drivers can be merged without
>> >>> these calls.
>> >>
>> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
>> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
>> >
>> > It may be reality, but IMO, "preventing other drivers" isn't a good
>> > *technical* argument for merging a feature.  It feels like these "for
>> > the 'good' of the community" arguments are being used to trump the
>> > technical arguments.  Maybe we need to keep the separate.
>> 
>> To continue along the "for the good of the community" path...
>> 
>> If it truly is the lack of a suspend blocker API that is preventing
>> the merge of these out of tree drivers, I second Mark's proposal[1] to
>> merge a noop version of the API while the technical issues continue to
>> be discussed.
>
> I'm against that, sorry.

OK, I'll bite... Why?

>> Then we would see how many drivers get submitted and merged.
>>
>> Personally, I suspect that lack of this feature is not the real
>> obstacle to getting these out-of-tree drivers upstream.  Having this
>> API upstream will not change the product schedules and corporate
>> cultures that have prevented code from making its way upstream.
>
> But apparently it is considered as a suitable excuse.

No, it is not a _technical_ excuse.  Just a healthy, experience-based
dose of skepticism.

It was expressed because I find the arguments above for merging
because it prevents out-of-tree drivers from merging quite
unconvincing.  This is not just about opportunistic suspend + suspend
blockers specifically but comes from several years experience in the
embedded Linux world.

Kevin

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

[Kevin Hilman]

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

> On Friday 14 May 2010, Kevin Hilman wrote:
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>> 
>> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> >
>> >> On Thursday 13 May 2010, Tony Lindgren wrote:
>> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
>> >
>> > [...]
>> >
>> >>>  
>> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
>> >>> > differently, while there's a growing number of out-of-tree drivers depending
>> >>> > on this framework.  We need those drivers in and because we don't have any
>> >>> > viable alternative at hand, we have no good reason to reject it.
>> >>> 
>> >>> Nothing is preventing merging the drivers can be merged without
>> >>> these calls.
>> >>
>> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
>> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
>> >
>> > It may be reality, but IMO, "preventing other drivers" isn't a good
>> > *technical* argument for merging a feature.  It feels like these "for
>> > the 'good' of the community" arguments are being used to trump the
>> > technical arguments.  Maybe we need to keep the separate.
>> 
>> To continue along the "for the good of the community" path...
>> 
>> If it truly is the lack of a suspend blocker API that is preventing
>> the merge of these out of tree drivers, I second Mark's proposal[1] to
>> merge a noop version of the API while the technical issues continue to
>> be discussed.
>
> I'm against that, sorry.

OK, I'll bite... Why?

>> Then we would see how many drivers get submitted and merged.
>>
>> Personally, I suspect that lack of this feature is not the real
>> obstacle to getting these out-of-tree drivers upstream.  Having this
>> API upstream will not change the product schedules and corporate
>> cultures that have prevented code from making its way upstream.
>
> But apparently it is considered as a suitable excuse.

No, it is not a _technical_ excuse.  Just a healthy, experience-based
dose of skepticism.

It was expressed because I find the arguments above for merging
because it prevents out-of-tree drivers from merging quite
unconvincing.  This is not just about opportunistic suspend + suspend
blockers specifically but comes from several years experience in the
embedded Linux world.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>>> Personally, I suspect that lack of this feature is not the real
>>> obstacle to getting these out-of-tree drivers upstream.  Having this
>>> API upstream will not change the product schedules and corporate
>>> cultures that have prevented code from making its way upstream.
>>
>> But apparently it is considered as a suitable excuse.
>
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.
>
> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

It provides useful functionality -- you apparently disagree, but the
wakelock/suspendblock model is in use, shipping, and solving problems
for quite a lot of android devices that have been shipping for a while
now.  We actively go to lowest power state in idle (on omap, msm,
etc), and use drivers that aggressively declock and depower modules
(similar to runtime pm), but we have found that using the
opportunistic suspend model combined with wakelocks allows us to
attain even lower average power consumption in always-connected,
actively-syncing devices.

It has been claimed that because Android userspace makes use of this
functionality a number of silicon vendors who want to submit code
upstream are inconvenienced by having to maintain "android" and
"mainline" versions of their drivers.  I can't speak for them, since
nobody has identified the particular inconvenienced vendors to me, nor
have they spoken with me directly, but personally I do find that
having to maintain two different versions of drivers (one version for
upstream, one for shipping products) is inconvenient.

Brian

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

[Brian Swetland]

On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>>> Personally, I suspect that lack of this feature is not the real
>>> obstacle to getting these out-of-tree drivers upstream.  Having this
>>> API upstream will not change the product schedules and corporate
>>> cultures that have prevented code from making its way upstream.
>>
>> But apparently it is considered as a suitable excuse.
>
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.
>
> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

It provides useful functionality -- you apparently disagree, but the
wakelock/suspendblock model is in use, shipping, and solving problems
for quite a lot of android devices that have been shipping for a while
now.  We actively go to lowest power state in idle (on omap, msm,
etc), and use drivers that aggressively declock and depower modules
(similar to runtime pm), but we have found that using the
opportunistic suspend model combined with wakelocks allows us to
attain even lower average power consumption in always-connected,
actively-syncing devices.

It has been claimed that because Android userspace makes use of this
functionality a number of silicon vendors who want to submit code
upstream are inconvenienced by having to maintain "android" and
"mainline" versions of their drivers.  I can't speak for them, since
nobody has identified the particular inconvenienced vendors to me, nor
have they spoken with me directly, but personally I do find that
having to maintain two different versions of drivers (one version for
upstream, one for shipping products) is inconvenient.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>>> Personally, I suspect that lack of this feature is not the real
>>> obstacle to getting these out-of-tree drivers upstream.  Having this
>>> API upstream will not change the product schedules and corporate
>>> cultures that have prevented code from making its way upstream.
>>
>> But apparently it is considered as a suitable excuse.
>
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.
>
> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

It provides useful functionality -- you apparently disagree, but the
wakelock/suspendblock model is in use, shipping, and solving problems
for quite a lot of android devices that have been shipping for a while
now.  We actively go to lowest power state in idle (on omap, msm,
etc), and use drivers that aggressively declock and depower modules
(similar to runtime pm), but we have found that using the
opportunistic suspend model combined with wakelocks allows us to
attain even lower average power consumption in always-connected,
actively-syncing devices.

It has been claimed that because Android userspace makes use of this
functionality a number of silicon vendors who want to submit code
upstream are inconvenienced by having to maintain "android" and
"mainline" versions of their drivers.  I can't speak for them, since
nobody has identified the particular inconvenienced vendors to me, nor
have they spoken with me directly, but personally I do find that
having to maintain two different versions of drivers (one version for
upstream, one for shipping products) is inconvenient.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[tytso]

On Fri, May 14, 2010 at 03:32:58PM -0700, Kevin Hilman wrote:
> Another likely reason that that there hasn't been an alternate
> proposal (at least from some of us that are raising concerns) is
> because we already have a working solution to dynamic, system-wide PM
> that is 1) already in mainline and 2) shipping on consumer devices
> with very strict power budgets (as already pointed out in detail by
> Paul[2].)

The examples cited where the things like the Palm Pre, and the Nokia
N770/800/810 series.  #1, what works on one embedded
chipset/architecture might not work on another, and #2, the battery
lifetime on the N770 and N800 (both of which I have) is **appalling**
**bad**.

I really don't understand why people are so opposed to merging code
that works well for a very large set of devices and products.  Just
because *you* don't need it is not a sufficiently good reason to argue
for it not be merged.  If you don't want to use it, then don't CONFIG
it in.

						- Ted

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

[Alan Stern]

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

> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Hello,
> >
> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
> >
> >> No, suspend blockers are mostly used to ensure wakeup events are not
> >> ignored, and to ensure tasks triggered by these wakeup events
> >> complete.
> >
> > Standard Linux systems don't need these,
> 
> If you don't want to lose wakeup events they do. Standard Linux
> systems support suspend, but since they usually don't have a lot of
> wakeup events you don't run into a lot of problems.

The primary client for opportunistic suspend and suspend blockers
appears to be embedded systems.  These systems are typically capable of
powering the CPU down and up again with low latency, and they typically
have very aggressive runtime PM support capable of powering down each
device when it's not in active use.  Given this ability, it does seem
that opportunistic suspend and suspend blockers might be unnecessary.

I'd like to explore this avenue a little farther.  In particular, what 
is the issue involving loss of wakeup events?  Can you describe this in 
more detail?

> > because the scheduler just keeps
> > the system running as long as there is work to be done.
> >
> 
> That is only true if you never use suspend.

Why would you want to use system suspend if runtime PM can do
everything you need?

Sure, I can see that an ACPI-based system needs something more.  But 
that's not the real issue here.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Fri, 14 May 2010, Rafael J. Wysocki wrote:

> > > How do you handle situations where the CPU is currently idle but an 
> > > event (such as I/O completion) is expected to occur in the near future?  
> > > You don't want to power-off and reboot then, do you?
> > 
> > The idle code looks at next_timer_interrupt() value, then if the
> > next timer event if far enough ahead, the system powers down and
> > wakes to the timer interrupt. It also wakes to device interrupts.
> 
> For the record, waking to interrupts doesn't work on quite some systems
> (like ACPI-based PCs for one example).

Ironically, it appears that ACPI-based PCs are in a position to benefit 
more from opportunistic suspend and suspend blockers than are embedded 
systems -- and yet they are being proposed for use on cell phones 
rather than on desktops.

Alan Stern

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

[Alan Stern]

On Fri, 14 May 2010, Rafael J. Wysocki wrote:

> > > How do you handle situations where the CPU is currently idle but an 
> > > event (such as I/O completion) is expected to occur in the near future?  
> > > You don't want to power-off and reboot then, do you?
> > 
> > The idle code looks at next_timer_interrupt() value, then if the
> > next timer event if far enough ahead, the system powers down and
> > wakes to the timer interrupt. It also wakes to device interrupts.
> 
> For the record, waking to interrupts doesn't work on quite some systems
> (like ACPI-based PCs for one example).

Ironically, it appears that ACPI-based PCs are in a position to benefit 
more from opportunistic suspend and suspend blockers than are embedded 
systems -- and yet they are being proposed for use on cell phones 
rather than on desktops.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Fri, 14 May 2010, Magnus Damm wrote:

> I agree with you Tony. I thought shutting down CPUs for power
> managment purposes could be done without freezing user space. At least
> that's what we do today with SH-Mobile.

If you can shut down and restart CPUs in the time periods between 
transitions into and out of the idle loop, then yes -- userspace 
doesn't need to be suspended.  After all, if the idle loop is running 
then no user threads are runnable.  (Not necessarily true on SMP 
systems, but you know what I mean.)

> Still not sure how the system wide suspend is different from Runtime
> PM and CPUidle from the hardware perspective...

For embedded systems, apparently the difference is minimal.  For other
systems, like ACPI-based PCs, there is a big difference: Powering down
devices and CPUs still leaves large parts of the system running.

In addition, these larger systems generally don't have aggressive 
runtime PM support, so a significant fraction (maybe more than 50%) of 
devices won't be powered down when they are idle -- whereas system 
suspend powers virtually everything down.

Alan Stern

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

[Alan Stern]

On Fri, 14 May 2010, Magnus Damm wrote:

> I agree with you Tony. I thought shutting down CPUs for power
> managment purposes could be done without freezing user space. At least
> that's what we do today with SH-Mobile.

If you can shut down and restart CPUs in the time periods between 
transitions into and out of the idle loop, then yes -- userspace 
doesn't need to be suspended.  After all, if the idle loop is running 
then no user threads are runnable.  (Not necessarily true on SMP 
systems, but you know what I mean.)

> Still not sure how the system wide suspend is different from Runtime
> PM and CPUidle from the hardware perspective...

For embedded systems, apparently the difference is minimal.  For other
systems, like ACPI-based PCs, there is a big difference: Powering down
devices and CPUs still leaves large parts of the system running.

In addition, these larger systems generally don't have aggressive 
runtime PM support, so a significant fraction (maybe more than 50%) of 
devices won't be powered down when they are idle -- whereas system 
suspend powers virtually everything down.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Fri, 14 May 2010, Brian Swetland wrote:

> It provides useful functionality -- you apparently disagree, but the
> wakelock/suspendblock model is in use, shipping, and solving problems
> for quite a lot of android devices that have been shipping for a while
> now.  We actively go to lowest power state in idle (on omap, msm,
> etc), and use drivers that aggressively declock and depower modules
> (similar to runtime pm), but we have found that using the
> opportunistic suspend model combined with wakelocks allows us to
> attain even lower average power consumption in always-connected,
> actively-syncing devices.

Can you explain this in more detail?  Are you saying that some devices
go on generating interrupts and causing timers to be scheduled, even 
though what they're doing isn't important enough to prevent the system 
from powering down?

Alan Stern

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

[Alan Stern]

On Fri, 14 May 2010, Brian Swetland wrote:

> It provides useful functionality -- you apparently disagree, but the
> wakelock/suspendblock model is in use, shipping, and solving problems
> for quite a lot of android devices that have been shipping for a while
> now.  We actively go to lowest power state in idle (on omap, msm,
> etc), and use drivers that aggressively declock and depower modules
> (similar to runtime pm), but we have found that using the
> opportunistic suspend model combined with wakelocks allows us to
> attain even lower average power consumption in always-connected,
> actively-syncing devices.

Can you explain this in more detail?  Are you saying that some devices
go on generating interrupts and causing timers to be scheduled, even 
though what they're doing isn't important enough to prevent the system 
from powering down?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Fri, May 14, 2010 at 7:58 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Brian Swetland wrote:
>
>> It provides useful functionality -- you apparently disagree, but the
>> wakelock/suspendblock model is in use, shipping, and solving problems
>> for quite a lot of android devices that have been shipping for a while
>> now.  We actively go to lowest power state in idle (on omap, msm,
>> etc), and use drivers that aggressively declock and depower modules
>> (similar to runtime pm), but we have found that using the
>> opportunistic suspend model combined with wakelocks allows us to
>> attain even lower average power consumption in always-connected,
>> actively-syncing devices.
>
> Can you explain this in more detail?  Are you saying that some devices
> go on generating interrupts and causing timers to be scheduled, even
> though what they're doing isn't important enough to prevent the system
> from powering down?

In tickless mode, the time until next timer is a signed int, so the
longest the kernel will ever sleep is ~2 seconds at a go.  In
practice, userspace entities often have polling behavior that can
trigger more often than that, and I've observed some kernel periodic
timers (haven't cataloged them recently) that happen more often than
once a second.

When we go to full suspend, we know that only specific wakeup sources
(keyboard gpios, baseband voice/ip events, rtc alarms, etc) are going
to wake us up.

Brian

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

[Brian Swetland]

On Fri, May 14, 2010 at 7:58 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Brian Swetland wrote:
>
>> It provides useful functionality -- you apparently disagree, but the
>> wakelock/suspendblock model is in use, shipping, and solving problems
>> for quite a lot of android devices that have been shipping for a while
>> now.  We actively go to lowest power state in idle (on omap, msm,
>> etc), and use drivers that aggressively declock and depower modules
>> (similar to runtime pm), but we have found that using the
>> opportunistic suspend model combined with wakelocks allows us to
>> attain even lower average power consumption in always-connected,
>> actively-syncing devices.
>
> Can you explain this in more detail?  Are you saying that some devices
> go on generating interrupts and causing timers to be scheduled, even
> though what they're doing isn't important enough to prevent the system
> from powering down?

In tickless mode, the time until next timer is a signed int, so the
longest the kernel will ever sleep is ~2 seconds at a go.  In
practice, userspace entities often have polling behavior that can
trigger more often than that, and I've observed some kernel periodic
timers (haven't cataloged them recently) that happen more often than
once a second.

When we go to full suspend, we know that only specific wakeup sources
(keyboard gpios, baseband voice/ip events, rtc alarms, etc) are going
to wake us up.

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

[Arve Hjønnevåg]

On Fri, May 14, 2010 at 7:25 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>
>> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > Hello,
>> >
>> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> No, suspend blockers are mostly used to ensure wakeup events are not
>> >> ignored, and to ensure tasks triggered by these wakeup events
>> >> complete.
>> >
>> > Standard Linux systems don't need these,
>>
>> If you don't want to lose wakeup events they do. Standard Linux
>> systems support suspend, but since they usually don't have a lot of
>> wakeup events you don't run into a lot of problems.
>
> The primary client for opportunistic suspend and suspend blockers
> appears to be embedded systems.  These systems are typically capable of
> powering the CPU down and up again with low latency, and they typically
> have very aggressive runtime PM support capable of powering down each
> device when it's not in active use.  Given this ability, it does seem
> that opportunistic suspend and suspend blockers might be unnecessary.
>

With the current kernel and user-space code we run, we get
significantly better battery life on the msm plaform using suspend
compared to entering the same power state from idle. On some devices
it takes only five wakeup events per second to cut the best case
battery life in half.

> I'd like to explore this avenue a little farther.  In particular, what
> is the issue involving loss of wakeup events?  Can you describe this in
> more detail?
>

On the desktop systems I have used I only wake the up the system by
pressing a button/key or with an rtc alarm. Losing a button or key
wakeup event is not usually a problem on a desktop since the user will
press it again. Losing an alarm however could be a problem and this
can be avoided by using opportunistic suspend and suspend blockers.

>> > because the scheduler just keeps
>> > the system running as long as there is work to be done.
>> >
>>
>> That is only true if you never use suspend.
>
> Why would you want to use system suspend if runtime PM can do
> everything you need?
>
Because it stops threads that wakeup every second to check if they
have work to do (this includes standard kernel threads), and it
prevents bad apps that never go idle from completely destroying our
battery life.

> Sure, I can see that an ACPI-based system needs something more.  But
> that's not the real issue here.
>

The system we started with entered a much lower power state from
suspend than idle so we needed wakelocks to get more than 24 hours
battery life. We kept wakelocks when we moved to the msm platform
since it reduces our power consumption.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

On Fri, May 14, 2010 at 7:35 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Rafael J. Wysocki wrote:
>
>> > > How do you handle situations where the CPU is currently idle but an
>> > > event (such as I/O completion) is expected to occur in the near future?
>> > > You don't want to power-off and reboot then, do you?
>> >
>> > The idle code looks at next_timer_interrupt() value, then if the
>> > next timer event if far enough ahead, the system powers down and
>> > wakes to the timer interrupt. It also wakes to device interrupts.
>>
>> For the record, waking to interrupts doesn't work on quite some systems
>> (like ACPI-based PCs for one example).
>
> Ironically, it appears that ACPI-based PCs are in a position to benefit
> more from opportunistic suspend and suspend blockers than are embedded
> systems -- and yet they are being proposed for use on cell phones
> rather than on desktops.
>

I would also use it on a desktop.

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Fri, May 14, 2010 at 7:35 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Rafael J. Wysocki wrote:
>
>> > > How do you handle situations where the CPU is currently idle but an
>> > > event (such as I/O completion) is expected to occur in the near future?
>> > > You don't want to power-off and reboot then, do you?
>> >
>> > The idle code looks at next_timer_interrupt() value, then if the
>> > next timer event if far enough ahead, the system powers down and
>> > wakes to the timer interrupt. It also wakes to device interrupts.
>>
>> For the record, waking to interrupts doesn't work on quite some systems
>> (like ACPI-based PCs for one example).
>
> Ironically, it appears that ACPI-based PCs are in a position to benefit
> more from opportunistic suspend and suspend blockers than are embedded
> systems -- and yet they are being proposed for use on cell phones
> rather than on desktops.
>

I would also use it on a desktop.

-- 
Arve Hjønnevåg

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

[Rafael J. Wysocki]

On Saturday 15 May 2010, Arve Hjønnevåg wrote:
> On Fri, May 14, 2010 at 3:32 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
> > Matthew Garrett <mjg@redhat.com> writes:
> >
> >> On Fri, May 14, 2010 at 02:20:43PM -0600, Paul Walmsley wrote:
> >>> Hello,
> >>>
> >>> On Mon, 3 May 2010, Matthew Garrett wrote:
> >>>
> >>> > I agree that the runtime scenario is a far more appealing one from an
> >>> > aesthetic standpoint, but so far we don't have a very compelling
> >>> > argument for dealing with the starting and stopping of userspace.
> >>>
> >>> The problem of how to start and stop (some) userspace is not specifically
> >>> system power management-related, nor top-down, /sys/power/state-suspend
> >>> related.  PM is just one potential user.
> >>>
> >>> It's hard to see how the Android opportunistic suspend approach would be
> >>> useful for the other use-cases (e.g., checkpoint/restart).  On the other
> >>> hand, it's easier to see how something like freezer cgroups could be
> >>> useful for system power management and checkpoint/restart.
> >>
> >> And difficult to see how to implement something using freezer cgroups
> >> that actually works in this case. Look, I don't want to sound like I
> >> have a one-track mind or anything, but all of these arguments would be
> >> significantly more compelling if someone would actually provide a
> >> concrete implementation proposal that deals with the set of use-cases
> >> that Google's implementation does and which doesn't make anyone cry.
> >
> > That might be possible if this "set of use-cases" was available
> > someplace.  At least I haven't seen it, and would expect it to be in
> > the docs included with patch 1.
> >
> > Another likely reason that that there hasn't been an alternate
> > proposal (at least from some of us that are raising concerns) is
> > because we already have a working solution to dynamic, system-wide PM
> > that is 1) already in mainline and 2) shipping on consumer devices
> > with very strict power budgets (as already pointed out in detail by
> > Paul[2].)
> >
> > Yes, "excruciatingly bad" apps can kill PM on these systems since
> > anyone can write apps, but the same is true on an opporunistic-suspend
> > based system since any app could hold a suspend blocker whenever it
> > wants.
> >
> 
> No, apps need permission to block suspend.

Are you referring to the fact the permissions of the special device file or
something different?

Rafael

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

[Rafael J. Wysocki]

On Saturday 15 May 2010, tytso@mit.edu wrote:
> On Fri, May 14, 2010 at 03:32:58PM -0700, Kevin Hilman wrote:
> > Another likely reason that that there hasn't been an alternate
> > proposal (at least from some of us that are raising concerns) is
> > because we already have a working solution to dynamic, system-wide PM
> > that is 1) already in mainline and 2) shipping on consumer devices
> > with very strict power budgets (as already pointed out in detail by
> > Paul[2].)
> 
> The examples cited where the things like the Palm Pre, and the Nokia
> N770/800/810 series.  #1, what works on one embedded
> chipset/architecture might not work on another, and #2, the battery
> lifetime on the N770 and N800 (both of which I have) is **appalling**
> **bad**.
> 
> I really don't understand why people are so opposed to merging code
> that works well for a very large set of devices and products.  Just
> because *you* don't need it is not a sufficiently good reason to argue
> for it not be merged.  If you don't want to use it, then don't CONFIG
> it in.

Violently agreed.

And really, the only semi-technical argument against the opportunistic suspend
feature I've seen so far in this thread is that it _may_ _be_ possible to
achieve the same goal in a different way.  If I don't see anything more serious
than that, I will take the patchset and push it to Linus (patches [1-6/8] from
version 7 to be precise, as soon as the changelogs are improved as
requested).

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 14:16]:
> > What race-free mechanism do you use to ensure that? It's very easy to 
> > handwave these problems away. It's very difficult to actually write an 
> > implementation that works.
> 
> Can you describe where do you see the race now?

1) Trusted app decides to suspend
2) Network packet that would otherwise wake the system is received
3) Trusted app sends SIGSTOP to untrusted userspace
4) Network packet sits waiting for stopped userspace to process it

Unless the trusted userspace gets woken up on every event that would 
potentially cause a wakeup, you're racy. And the alternative involves an 
extra userspace wakeup for every network packet - which is expensive.

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

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

[Matthew Garrett]

On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@redhat.com> [100513 14:16]:
> > What race-free mechanism do you use to ensure that? It's very easy to 
> > handwave these problems away. It's very difficult to actually write an 
> > implementation that works.
> 
> Can you describe where do you see the race now?

1) Trusted app decides to suspend
2) Network packet that would otherwise wake the system is received
3) Trusted app sends SIGSTOP to untrusted userspace
4) Network packet sits waiting for stopped userspace to process it

Unless the trusted userspace gets woken up on every event that would 
potentially cause a wakeup, you're racy. And the alternative involves an 
extra userspace wakeup for every network packet - which is expensive.

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

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

[Brian Swetland]

On Sat, May 15, 2010 at 12:47 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >
>> > Yes, "excruciatingly bad" apps can kill PM on these systems since
>> > anyone can write apps, but the same is true on an opporunistic-suspend
>> > based system since any app could hold a suspend blocker whenever it
>> > wants.
>>
>> No, apps need permission to block suspend.
>
> Are you referring to the fact the permissions of the special device file or
> something different?

The special device file will have filesystem permissions that limit
access to system services.

Arbitrary userspace apps do not have direct access to the device --
they use a service (provided by binder rpc), and the app must declare
its intent (and the user accept this on install) in order to use that
service. The service keeps track of usage stats so if a user
experiences poor battery life they can look at the battery usage thing
and see which apps are keeping the device awake, etc.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Saturday 15 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Friday 14 May 2010, Kevin Hilman wrote:
> >> Kevin Hilman <khilman@deeprootsystems.com> writes:
> >> 
> >> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >> >
> >> >> On Thursday 13 May 2010, Tony Lindgren wrote:
> >> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> >> >
> >> > [...]
> >> >
> >> >>>  
> >> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >> >>> > differently, while there's a growing number of out-of-tree drivers depending
> >> >>> > on this framework.  We need those drivers in and because we don't have any
> >> >>> > viable alternative at hand, we have no good reason to reject it.
> >> >>> 
> >> >>> Nothing is preventing merging the drivers can be merged without
> >> >>> these calls.
> >> >>
> >> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
> >> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
> >> >
> >> > It may be reality, but IMO, "preventing other drivers" isn't a good
> >> > *technical* argument for merging a feature.  It feels like these "for
> >> > the 'good' of the community" arguments are being used to trump the
> >> > technical arguments.  Maybe we need to keep the separate.
> >> 
> >> To continue along the "for the good of the community" path...
> >> 
> >> If it truly is the lack of a suspend blocker API that is preventing
> >> the merge of these out of tree drivers, I second Mark's proposal[1] to
> >> merge a noop version of the API while the technical issues continue to
> >> be discussed.
> >
> > I'm against that, sorry.
> 
> OK, I'll bite... Why?

Because in that case the real feature will always be opposed as "unnecessary"
and never merged.  I very much prefer to decide whether to merge it or reject
it right now.

> >> Then we would see how many drivers get submitted and merged.
> >>
> >> Personally, I suspect that lack of this feature is not the real
> >> obstacle to getting these out-of-tree drivers upstream.  Having this
> >> API upstream will not change the product schedules and corporate
> >> cultures that have prevented code from making its way upstream.
> >
> > But apparently it is considered as a suitable excuse.
> 
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.

I didn't mean that, actually.  What I wanted to say is that people use the
lack of "wakelocks" in the mainline as an excuse not to push their drivers
upstream (which is kind of understandable, because there's a zero benefit to
them from mainlining their code, as they will have to maintain a separate
"Android" version of it anyway).

Sorry for the confusion.

> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

In this particular case, the lack of the mainline's support for opportunistic
suspend (in the form of "wakelocks" to be precise) has been given as a main
obstacle against merging of several drivers at least.

So, let's not just easily generalize, please.

And this is not the only reason to push the opportunistic suspend feature
upstream IMO.

First, I think it is a legitimate approach to power management, whether you
like it or not.  I haven't seen anyone seriously arguing against that yet.

Second, (as said above) there is a number of drivers _already_ depending
on it and that number is only going to grow given the popularity of Android.
They are not mainlined in part because their authors don't see a benefit from
doing so (usually the benefit is that you don't have to maintain your code out
of the tree, because the mainline does it for you to some extent, so if you
need to maintain a separate version yourself, the benefit is zero).

Next, the only thing the Arve's patches do is to give people an _option_ to use
opportunistic suspend if they need it or want it.  It's not mandatory and not
even enabled by default, so I don't really see what the problem is.  Quite on
the contrary, I'd like people to be able to use the mainline on Android systems
without major modifications, because potentially that can increase our tester
base (and developer base too in consequence) and including opportunistic
suspend in the mainline would be a step in that direction.

Finally, it appears to address some issues that at the moment we don't
seriously know how to address in a different way.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Saturday 15 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Friday 14 May 2010, Kevin Hilman wrote:
> >> Kevin Hilman <khilman@deeprootsystems.com> writes:
> >> 
> >> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >> >
> >> >> On Thursday 13 May 2010, Tony Lindgren wrote:
> >> >>> * Rafael J. Wysocki <rjw@sisk.pl> [100513 14:16]:
> >> >
> >> > [...]
> >> >
> >> >>>  
> >> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >> >>> > differently, while there's a growing number of out-of-tree drivers depending
> >> >>> > on this framework.  We need those drivers in and because we don't have any
> >> >>> > viable alternative at hand, we have no good reason to reject it.
> >> >>> 
> >> >>> Nothing is preventing merging the drivers can be merged without
> >> >>> these calls.
> >> >>
> >> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
> >> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
> >> >
> >> > It may be reality, but IMO, "preventing other drivers" isn't a good
> >> > *technical* argument for merging a feature.  It feels like these "for
> >> > the 'good' of the community" arguments are being used to trump the
> >> > technical arguments.  Maybe we need to keep the separate.
> >> 
> >> To continue along the "for the good of the community" path...
> >> 
> >> If it truly is the lack of a suspend blocker API that is preventing
> >> the merge of these out of tree drivers, I second Mark's proposal[1] to
> >> merge a noop version of the API while the technical issues continue to
> >> be discussed.
> >
> > I'm against that, sorry.
> 
> OK, I'll bite... Why?

Because in that case the real feature will always be opposed as "unnecessary"
and never merged.  I very much prefer to decide whether to merge it or reject
it right now.

> >> Then we would see how many drivers get submitted and merged.
> >>
> >> Personally, I suspect that lack of this feature is not the real
> >> obstacle to getting these out-of-tree drivers upstream.  Having this
> >> API upstream will not change the product schedules and corporate
> >> cultures that have prevented code from making its way upstream.
> >
> > But apparently it is considered as a suitable excuse.
> 
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.

I didn't mean that, actually.  What I wanted to say is that people use the
lack of "wakelocks" in the mainline as an excuse not to push their drivers
upstream (which is kind of understandable, because there's a zero benefit to
them from mainlining their code, as they will have to maintain a separate
"Android" version of it anyway).

Sorry for the confusion.

> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

In this particular case, the lack of the mainline's support for opportunistic
suspend (in the form of "wakelocks" to be precise) has been given as a main
obstacle against merging of several drivers at least.

So, let's not just easily generalize, please.

And this is not the only reason to push the opportunistic suspend feature
upstream IMO.

First, I think it is a legitimate approach to power management, whether you
like it or not.  I haven't seen anyone seriously arguing against that yet.

Second, (as said above) there is a number of drivers _already_ depending
on it and that number is only going to grow given the popularity of Android.
They are not mainlined in part because their authors don't see a benefit from
doing so (usually the benefit is that you don't have to maintain your code out
of the tree, because the mainline does it for you to some extent, so if you
need to maintain a separate version yourself, the benefit is zero).

Next, the only thing the Arve's patches do is to give people an _option_ to use
opportunistic suspend if they need it or want it.  It's not mandatory and not
even enabled by default, so I don't really see what the problem is.  Quite on
the contrary, I'd like people to be able to use the mainline on Android systems
without major modifications, because potentially that can increase our tester
base (and developer base too in consequence) and including opportunistic
suspend in the mainline would be a step in that direction.

Finally, it appears to address some issues that at the moment we don't
seriously know how to address in a different way.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

On Fri, 14 May 2010, Brian Swetland wrote:

> In tickless mode, the time until next timer is a signed int, so the
> longest the kernel will ever sleep is ~2 seconds at a go.  In
> practice, userspace entities often have polling behavior that can
> trigger more often than that, and I've observed some kernel periodic
> timers (haven't cataloged them recently) that happen more often than
> once a second.

Paul and Kevin, how does the OMAP implementation handle these 
difficulties?

Also, how does it handle the issue of ill-behaved apps?

Alan Stern

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

[Alan Stern]

On Fri, 14 May 2010, Brian Swetland wrote:

> In tickless mode, the time until next timer is a signed int, so the
> longest the kernel will ever sleep is ~2 seconds at a go.  In
> practice, userspace entities often have polling behavior that can
> trigger more often than that, and I've observed some kernel periodic
> timers (haven't cataloged them recently) that happen more often than
> once a second.

Paul and Kevin, how does the OMAP implementation handle these 
difficulties?

Also, how does it handle the issue of ill-behaved apps?

Alan Stern

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

[Alan Stern]

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

> > I'd like to explore this avenue a little farther.  In particular, what
> > is the issue involving loss of wakeup events?  Can you describe this in
> > more detail?
> >
> 
> On the desktop systems I have used I only wake the up the system by
> pressing a button/key or with an rtc alarm. Losing a button or key
> wakeup event is not usually a problem on a desktop since the user will
> press it again. Losing an alarm however could be a problem and this
> can be avoided by using opportunistic suspend and suspend blockers.

How can runtime PM combined with CPUidle cause an alarm to be lost?

> > Why would you want to use system suspend if runtime PM can do
> > everything you need?
> >
> Because it stops threads that wakeup every second to check if they
> have work to do (this includes standard kernel threads), and it
> prevents bad apps that never go idle from completely destroying our
> battery life.

Ah, the ill-behaved apps problem.  I think everybody agrees that they 
are hard to deal with.

The kernel-threads problem might better be addressed by fixing those
threads than by adding a new API.

> > Sure, I can see that an ACPI-based system needs something more.  But
> > that's not the real issue here.
> >
> 
> The system we started with entered a much lower power state from
> suspend than idle so we needed wakelocks to get more than 24 hours
> battery life. We kept wakelocks when we moved to the msm platform
> since it reduces our power consumption.

Is it generally true among embedded systems nowadays that idle is 
capable of reaching essentially the same power states as suspend?

Alan Stern

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

[Rafael J. Wysocki]

On Saturday 15 May 2010, Brian Swetland wrote:
> On Sat, May 15, 2010 at 12:47 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >
> >> > Yes, "excruciatingly bad" apps can kill PM on these systems since
> >> > anyone can write apps, but the same is true on an opporunistic-suspend
> >> > based system since any app could hold a suspend blocker whenever it
> >> > wants.
> >>
> >> No, apps need permission to block suspend.
> >
> > Are you referring to the fact the permissions of the special device file or
> > something different?
> 
> The special device file will have filesystem permissions that limit
> access to system services.
> 
> Arbitrary userspace apps do not have direct access to the device --
> they use a service (provided by binder rpc), and the app must declare
> its intent (and the user accept this on install) in order to use that
> service.

On Android, right?

> The service keeps track of usage stats so if a user
> experiences poor battery life they can look at the battery usage thing
> and see which apps are keeping the device awake, etc.

That sounds like it should go into a doc or at least into the changelog of
patch [2/8] IMnsHO.

The thing you said about timers in one of the previous messages should be
documented too, BTW, because it's one of the motivation factors for this
work.

In general, I think the motivation is not explained sufficienty in the patches'
changelogs and that's one of the reasons why people have so many doubts about
the feature's usefulness.

Thanks,
Rafael

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

[Brian Swetland]

On Sat, May 15, 2010 at 4:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday 15 May 2010, Brian Swetland wrote:
>> The special device file will have filesystem permissions that limit
>> access to system services.
>>
>> Arbitrary userspace apps do not have direct access to the device --
>> they use a service (provided by binder rpc), and the app must declare
>> its intent (and the user accept this on install) in order to use that
>> service.
>
> On Android, right?

Yup -- other userspace environments may choose different ways to
grant/deny access.  At the bottom we gate it by having a group that
processes which may access the device are part of (with the device
node being 0660, etc).

>> The service keeps track of usage stats so if a user
>> experiences poor battery life they can look at the battery usage thing
>> and see which apps are keeping the device awake, etc.
>
> That sounds like it should go into a doc or at least into the changelog of
> patch [2/8] IMnsHO.
>
> The thing you said about timers in one of the previous messages should be
> documented too, BTW, because it's one of the motivation factors for this
> work.
>
> In general, I think the motivation is not explained sufficienty in the patches'
> changelogs and that's one of the reasons why people have so many doubts about
> the feature's usefulness.

Seems reasonable -- I know Arve's working on making these a bit more
verbose for you.

Brian

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

[Mark Brown]

On Sat, 2010-05-15 at 21:52 +0200, Rafael J. Wysocki wrote:
> On Saturday 15 May 2010, tytso@mit.edu wrote:

> > The examples cited where the things like the Palm Pre, and the Nokia
> > N770/800/810 series.  #1, what works on one embedded
> > chipset/architecture might not work on another, and #2, the battery

Pretty much all of the architectures going after this sort of market
seem to be taking very similar design decisions here. The high degree of
integration on the SoCs kind of forces it since you're always going to
end up with at least some things on the CPU sitting around idle so
something needs to be done to drive their runtime power cost down.
However, this does all require software support and the level of
implementation of that you see does vary.

> > lifetime on the N770 and N800 (both of which I have) is **appalling**
> > **bad**.

Hrm. I've got those devices as well and I don't recall the battery life
being particularly awful when they weren't actively being used which is
the interesting case there. It's been a while but ISTR they compared
well enough with the smartphones of their generation. YMMV, of course.

I guess the other direction to look at this from is that Android devices
seem to have battery lifetimes that are comparable to other smartphones,
including Linux based ones, rather than remarkably better than them.
There's a reasonable number out there that I've seen, using a range of
approaches including both pure runtime PM and also normal suspends
initiated from userspace with varying degrees of control over the
customisation end users can do on their system.

Wakelocks aren't totally going out on a limb in their use of suspend,
general systems in this area aren't actually relying purely on runtime
PM yet. Where wakelocks do stand out from the other solutions I have
seen is that they push the management of the decision to suspend into
the kernel.

I think it's probably most accurate to say that the thing that what
wakelocks are designed to deliver is to make the system more forgiving
of power inefficient application code (providing it doesn't just request
permission to burn the battery, of course). I can't think of any actual
implementations I have seen which do anything special to deal with them.
The argument there would I guess be that the impact on battery life
provides a fairly strong incentive to the application developers to not
do silly things. There's a fairly clear tradeoff there, and neither
approach is going to be universally right.

> And really, the only semi-technical argument against the opportunistic suspend
> feature I've seen so far in this thread is that it _may_ _be_ possible to
> achieve the same goal in a different way.  If I don't see anything more serious
> than that, I will take the patchset and push it to Linus (patches [1-6/8] from
> version 7 to be precise, as soon as the changelogs are improved as
> requested).

Well, the other concerns that *might* be considered technical are the
requirement for driver modifications to take wakelocks (personally I'm
fairly OK with that - it's not especially pretty but they seem trivial
enough so meh) and the userspace ABI that's being created to manage
suspend blocking (which I've not even looked at).

Like I say, I don't personally object to merging the code at this point - I
mostly wanted to provide a broader view on the approaches people are using
here.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Sat, 2010-05-15 at 22:14 +0200, Rafael J. Wysocki wrote:
> On Saturday 15 May 2010, Kevin Hilman wrote:
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > > On Friday 14 May 2010, Kevin Hilman wrote:

> > >> If it truly is the lack of a suspend blocker API that is preventing
> > >> the merge of these out of tree drivers, I second Mark's proposal[1] to
> > >> merge a noop version of the API while the technical issues continue to
> > >> be discussed.

> > > I'm against that, sorry.

> > OK, I'll bite... Why?

> Because in that case the real feature will always be opposed as "unnecessary"
> and never merged.  I very much prefer to decide whether to merge it or reject
> it right now.

FWIW (as the person who made the suggestion) I do think that it is
something one might call expedient rather than actually good.

> > It was expressed because I find the arguments above for merging
> > because it prevents out-of-tree drivers from merging quite
> > unconvincing.  This is not just about opportunistic suspend + suspend
> > blockers specifically but comes from several years experience in the
> > embedded Linux world.

> In this particular case, the lack of the mainline's support for opportunistic
> suspend (in the form of "wakelocks" to be precise) has been given as a main
> obstacle against merging of several drivers at least.

Where are these objections coming from? The only example I've seen cited
is the G1 stuff, which is a fairly special case for a number of reasons
(including the underlying MSM BSP, which was pretty substantial itself).

> And this is not the only reason to push the opportunistic suspend feature
> upstream IMO.

Agreed, my purpose here is mostly to push back on what sound like
unrealistic expectations about what we're getting.

> Second, (as said above) there is a number of drivers _already_ depending
> on it and that number is only going to grow given the popularity of Android.
> They are not mainlined in part because their authors don't see a benefit from
> doing so (usually the benefit is that you don't have to maintain your code out
> of the tree, because the mainline does it for you to some extent, so if you
> need to maintain a separate version yourself, the benefit is zero).

Wakelocks are going to be a fairly minor part of any decision here -
it'd be pretty surprising if they take much effort to remove from a
driver. What's much more of an issue is that you've got essentially the
same situation as you have with the enterprise Linux distributions, a
fixed kernel version that vendors need to target. The differences that
implies are far more substantial than wakelocks for many areas of the
kernel, especially at the points in the cycle where the fixed kernel has
drifted furthest from the current mainline.

Things aren't quite the same as with the enterprise distributions,
though - the lifecycles for many parts in the consumer space are much,
much shorter than those in the enterprise markets. They can be
sufficiently short to mean that a mainline driver won't show up where
customers need it soon enough. For example, Google is currently
preparing an Android release based on 2.6.32 the merge window for which
was in September last year, over six months ago. This is an extremely
long latency if you're working on something in the region of a twelve
month cycle. The lack of standardisation for register interfaces in the
embedded space means that the generation to generation differences can
easily be sufficiently substantial to make a new driver the only
sensible option.

This isn't to say that the old parts just suddenly vanish, and clearly
there's an advantage from ongoing mainline inclusion, but the tradeoffs
are a bit different to those in other markets.

There's also a less pressure from end users towards mainline inclusion -
even on Linux people in the embedded space are used to having to get
code from multiple vendors working together so the lack of mainline
support isn't the sort of issue it would be with something like server
class hardware. This is changing over time as more and more vendors buy
into mainline but there's a way to go yet. If the part requires changes
outside the driver itself (a new or updated kernel interface, for
example) there's a pressure to just deal with it in the driver in a way
which is going to be unacceptable for mainline, possibly even involving
per-system code modifications in the driver. Sometimes ongoing mainline
development will mean that the driver needs updating anyway in ways that
are much more substantial than ripping out wakelocks would be.

Having wakelocks in does make things easier for drivers using them but
we need to recognise that all sorts of other things that are much harder
to deal with will also come up.

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

[Mark Brown]

On Sat, 2010-05-15 at 22:14 +0200, Rafael J. Wysocki wrote:
> On Saturday 15 May 2010, Kevin Hilman wrote:
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > > On Friday 14 May 2010, Kevin Hilman wrote:

> > >> If it truly is the lack of a suspend blocker API that is preventing
> > >> the merge of these out of tree drivers, I second Mark's proposal[1] to
> > >> merge a noop version of the API while the technical issues continue to
> > >> be discussed.

> > > I'm against that, sorry.

> > OK, I'll bite... Why?

> Because in that case the real feature will always be opposed as "unnecessary"
> and never merged.  I very much prefer to decide whether to merge it or reject
> it right now.

FWIW (as the person who made the suggestion) I do think that it is
something one might call expedient rather than actually good.

> > It was expressed because I find the arguments above for merging
> > because it prevents out-of-tree drivers from merging quite
> > unconvincing.  This is not just about opportunistic suspend + suspend
> > blockers specifically but comes from several years experience in the
> > embedded Linux world.

> In this particular case, the lack of the mainline's support for opportunistic
> suspend (in the form of "wakelocks" to be precise) has been given as a main
> obstacle against merging of several drivers at least.

Where are these objections coming from? The only example I've seen cited
is the G1 stuff, which is a fairly special case for a number of reasons
(including the underlying MSM BSP, which was pretty substantial itself).

> And this is not the only reason to push the opportunistic suspend feature
> upstream IMO.

Agreed, my purpose here is mostly to push back on what sound like
unrealistic expectations about what we're getting.

> Second, (as said above) there is a number of drivers _already_ depending
> on it and that number is only going to grow given the popularity of Android.
> They are not mainlined in part because their authors don't see a benefit from
> doing so (usually the benefit is that you don't have to maintain your code out
> of the tree, because the mainline does it for you to some extent, so if you
> need to maintain a separate version yourself, the benefit is zero).

Wakelocks are going to be a fairly minor part of any decision here -
it'd be pretty surprising if they take much effort to remove from a
driver. What's much more of an issue is that you've got essentially the
same situation as you have with the enterprise Linux distributions, a
fixed kernel version that vendors need to target. The differences that
implies are far more substantial than wakelocks for many areas of the
kernel, especially at the points in the cycle where the fixed kernel has
drifted furthest from the current mainline.

Things aren't quite the same as with the enterprise distributions,
though - the lifecycles for many parts in the consumer space are much,
much shorter than those in the enterprise markets. They can be
sufficiently short to mean that a mainline driver won't show up where
customers need it soon enough. For example, Google is currently
preparing an Android release based on 2.6.32 the merge window for which
was in September last year, over six months ago. This is an extremely
long latency if you're working on something in the region of a twelve
month cycle. The lack of standardisation for register interfaces in the
embedded space means that the generation to generation differences can
easily be sufficiently substantial to make a new driver the only
sensible option.

This isn't to say that the old parts just suddenly vanish, and clearly
there's an advantage from ongoing mainline inclusion, but the tradeoffs
are a bit different to those in other markets.

There's also a less pressure from end users towards mainline inclusion -
even on Linux people in the embedded space are used to having to get
code from multiple vendors working together so the lack of mainline
support isn't the sort of issue it would be with something like server
class hardware. This is changing over time as more and more vendors buy
into mainline but there's a way to go yet. If the part requires changes
outside the driver itself (a new or updated kernel interface, for
example) there's a pressure to just deal with it in the driver in a way
which is going to be unacceptable for mainline, possibly even involving
per-system code modifications in the driver. Sometimes ongoing mainline
development will mean that the driver needs updating anyway in ways that
are much more substantial than ripping out wakelocks would be.

Having wakelocks in does make things easier for drivers using them but
we need to recognise that all sorts of other things that are much harder
to deal with will also come up.

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

[Arve Hjønnevåg]

On Sat, May 15, 2010 at 2:25 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>
>> > I'd like to explore this avenue a little farther.  In particular, what
>> > is the issue involving loss of wakeup events?  Can you describe this in
>> > more detail?
>> >
>>
>> On the desktop systems I have used I only wake the up the system by
>> pressing a button/key or with an rtc alarm. Losing a button or key
>> wakeup event is not usually a problem on a desktop since the user will
>> press it again. Losing an alarm however could be a problem and this
>> can be avoided by using opportunistic suspend and suspend blockers.
>
> How can runtime PM combined with CPUidle cause an alarm to be lost?
>
It doesn't. My desktop systems only gets to a low power state (<3W)
from suspend.

>> > Why would you want to use system suspend if runtime PM can do
>> > everything you need?
>> >
>> Because it stops threads that wakeup every second to check if they
>> have work to do (this includes standard kernel threads), and it
>> prevents bad apps that never go idle from completely destroying our
>> battery life.
>
> Ah, the ill-behaved apps problem.  I think everybody agrees that they
> are hard to deal with.
>
> The kernel-threads problem might better be addressed by fixing those
> threads than by adding a new API.
>
>> > Sure, I can see that an ACPI-based system needs something more.  But
>> > that's not the real issue here.
>> >
>>
>> The system we started with entered a much lower power state from
>> suspend than idle so we needed wakelocks to get more than 24 hours
>> battery life. We kept wakelocks when we moved to the msm platform
>> since it reduces our power consumption.
>
> Is it generally true among embedded systems nowadays that idle is
> capable of reaching essentially the same power states as suspend?

Embedded system in general, no, but all the recent SOCs I've seen that
target phones do.

-- 
Arve Hjønnevåg

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

[Magnus Damm]

On Sat, May 15, 2010 at 8:15 AM,  <tytso@mit.edu> wrote:
> On Fri, May 14, 2010 at 03:32:58PM -0700, Kevin Hilman wrote:
>> Another likely reason that that there hasn't been an alternate
>> proposal (at least from some of us that are raising concerns) is
>> because we already have a working solution to dynamic, system-wide PM
>> that is 1) already in mainline and 2) shipping on consumer devices
>> with very strict power budgets (as already pointed out in detail by
>> Paul[2].)
>
> The examples cited where the things like the Palm Pre, and the Nokia
> N770/800/810 series.  #1, what works on one embedded
> chipset/architecture might not work on another, and #2, the battery
> lifetime on the N770 and N800 (both of which I have) is **appalling**
> **bad**.

Really? My experience is sort of the opposite.

My 3 year old Maemo-based Nokia N800 survived about a week idle. My
half-year old HTC HT-03A with Android 1.6 survives a day or three, but
not much more. Fortunately the japanese cellphone provider Docomo
bundled it with two batteries, haha. =)

The Nexus One only came with one battery, but from my perspective it's
as good as N800 or maybe even better.

In the end, I don't think it's a question of Maemo vs Android here or
wakelock vs Runtime PM. I'm sure both would do just fine with enough
optimizations.

/ magnus

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Fri, 14 May 2010, Brian Swetland wrote:
>
>> In tickless mode, the time until next timer is a signed int, so the
>> longest the kernel will ever sleep is ~2 seconds at a go.  In
>> practice, userspace entities often have polling behavior that can
>> trigger more often than that, and I've observed some kernel periodic
>> timers (haven't cataloged them recently) that happen more often than
>> once a second.
>
> Paul and Kevin, how does the OMAP implementation handle these 
> difficulties?

just a minor clarification... these aren't OMAP-specific issues, but
generic issues to all power-sensitive kernel users.

The ~2 second limit was fixed by Jon Hunter (TI) and is in mainline
since 2.6.32[1].

For other timers, there has been active work (mostly by Intel folks)
on deferrable timers, coalescing timers, timer slack etc. that has
greatly reduced the kernel timer impact on wakeups.

> Also, how does it handle the issue of ill-behaved apps?

For userspace, apps that have polling behavior or are ill-behaved must
be found and fixed.  Thanks to tools like powertop, this is a farily
easy task.

But really, I don't consider the "ill-behaved app" problem to be a
real-world problem.  Both in maemo/meego and Android, if someone
writes an app that kills battery life, it will get reported as a bug,
or get bad ratings etc.  On these kinds of devices, there is a *stong*
developer incentive to not write battery sucking apps.

Kevin


[1]
commit 97813f2fe77804a4464564c75ba8d8826377feea
Author: Jon Hunter <jon-hunter@ti.com>
Date:   Tue Aug 18 12:45:11 2009 -0500

    nohz: Allow 32-bit machines to sleep for more than 2.15 seconds
    
    In the dynamic tick code, "max_delta_ns" (member of the
    "clock_event_device" structure) represents the maximum sleep time
    that can occur between timer events in nanoseconds.
    
    The variable, "max_delta_ns", is defined as an unsigned long
    which is a 32-bit integer for 32-bit machines and a 64-bit
    integer for 64-bit machines (if -m64 option is used for gcc).
    The value of max_delta_ns is set by calling the function
    "clockevent_delta2ns()" which returns a maximum value of LONG_MAX.
    For a 32-bit machine LONG_MAX is equal to 0x7fffffff and in
    nanoseconds this equates to ~2.15 seconds. Hence, the maximum
    sleep time for a 32-bit machine is ~2.15 seconds, where as for
    a 64-bit machine it will be many years.
    
    This patch changes the type of max_delta_ns to be "u64" instead of
    "unsigned long" so that this variable is a 64-bit type for both 32-bit
    and 64-bit machines. It also changes the maximum value returned by
    clockevent_delta2ns() to KTIME_MAX.  Hence this allows a 32-bit
    machine to sleep for longer than ~2.15 seconds. Please note that this
    patch also changes "min_delta_ns" to be "u64" too and although this is
    unnecessary, it makes the patch simpler as it avoids to fixup all
    callers of clockevent_delta2ns().
    
    [ tglx: changed "unsigned long long" to u64 as we use this data type
        through out the time code ]
    
    Signed-off-by: Jon Hunter <jon-hunter@ti.com>
    Cc: John Stultz <johnstul@us.ibm.com>
    LKML-Reference: <1250617512-23567-3-git-send-email-jon-hunter@ti.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

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

[Kevin Hilman]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Fri, 14 May 2010, Brian Swetland wrote:
>
>> In tickless mode, the time until next timer is a signed int, so the
>> longest the kernel will ever sleep is ~2 seconds at a go.  In
>> practice, userspace entities often have polling behavior that can
>> trigger more often than that, and I've observed some kernel periodic
>> timers (haven't cataloged them recently) that happen more often than
>> once a second.
>
> Paul and Kevin, how does the OMAP implementation handle these 
> difficulties?

just a minor clarification... these aren't OMAP-specific issues, but
generic issues to all power-sensitive kernel users.

The ~2 second limit was fixed by Jon Hunter (TI) and is in mainline
since 2.6.32[1].

For other timers, there has been active work (mostly by Intel folks)
on deferrable timers, coalescing timers, timer slack etc. that has
greatly reduced the kernel timer impact on wakeups.

> Also, how does it handle the issue of ill-behaved apps?

For userspace, apps that have polling behavior or are ill-behaved must
be found and fixed.  Thanks to tools like powertop, this is a farily
easy task.

But really, I don't consider the "ill-behaved app" problem to be a
real-world problem.  Both in maemo/meego and Android, if someone
writes an app that kills battery life, it will get reported as a bug,
or get bad ratings etc.  On these kinds of devices, there is a *stong*
developer incentive to not write battery sucking apps.

Kevin


[1]
commit 97813f2fe77804a4464564c75ba8d8826377feea
Author: Jon Hunter <jon-hunter@ti.com>
Date:   Tue Aug 18 12:45:11 2009 -0500

    nohz: Allow 32-bit machines to sleep for more than 2.15 seconds
    
    In the dynamic tick code, "max_delta_ns" (member of the
    "clock_event_device" structure) represents the maximum sleep time
    that can occur between timer events in nanoseconds.
    
    The variable, "max_delta_ns", is defined as an unsigned long
    which is a 32-bit integer for 32-bit machines and a 64-bit
    integer for 64-bit machines (if -m64 option is used for gcc).
    The value of max_delta_ns is set by calling the function
    "clockevent_delta2ns()" which returns a maximum value of LONG_MAX.
    For a 32-bit machine LONG_MAX is equal to 0x7fffffff and in
    nanoseconds this equates to ~2.15 seconds. Hence, the maximum
    sleep time for a 32-bit machine is ~2.15 seconds, where as for
    a 64-bit machine it will be many years.
    
    This patch changes the type of max_delta_ns to be "u64" instead of
    "unsigned long" so that this variable is a 64-bit type for both 32-bit
    and 64-bit machines. It also changes the maximum value returned by
    clockevent_delta2ns() to KTIME_MAX.  Hence this allows a 32-bit
    machine to sleep for longer than ~2.15 seconds. Please note that this
    patch also changes "min_delta_ns" to be "u64" too and although this is
    unnecessary, it makes the patch simpler as it avoids to fixup all
    callers of clockevent_delta2ns().
    
    [ tglx: changed "unsigned long long" to u64 as we use this data type
        through out the time code ]
    
    Signed-off-by: Jon Hunter <jon-hunter@ti.com>
    Cc: John Stultz <johnstul@us.ibm.com>
    LKML-Reference: <1250617512-23567-3-git-send-email-jon-hunter@ti.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

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

[Kevin Hilman]

tytso@mit.edu writes:

> On Fri, May 14, 2010 at 03:32:58PM -0700, Kevin Hilman wrote:
>> Another likely reason that that there hasn't been an alternate
>> proposal (at least from some of us that are raising concerns) is
>> because we already have a working solution to dynamic, system-wide PM
>> that is 1) already in mainline and 2) shipping on consumer devices
>> with very strict power budgets (as already pointed out in detail by
>> Paul[2].)
>
> The examples cited where the things like the Palm Pre, and the Nokia
> N770/800/810 series.  #1, what works on one embedded
> chipset/architecture might not work on another, 

In my experience with embedded SoCs they are all remarkably similar in
power management capabilities and control.

> and #2, the battery lifetime on the N770 and N800 (both of which I have)
> is **appalling** **bad**.

Appalling bad compared to what?  

What's probably more interesting in terms of rough comparisons is
comparing similar devices with and without opportunistic suspend.  The
Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
OMAP3) and roughly the same kernel (2.6.2[89], although both are
heavily patched from mainline.)

The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)

I don't know of any more objective comparison of the two, but as a
user of both devices I can say that the active usage is basically the
same (around a day) and the idle use is similar as well, even though
the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
own usage suggests the n900 is a bit better in idle time, but I have
not done any measuring or objective tests.  I'm guessing the
difference is probably because the Droid does not use the deepest
off-mode power states either in idle or suspend (IIRC) where the n900
does.  I suspect that if both were using off-mode and had the same
battery, these differences would go away.

While this is not really a scientific comparison, it at least gives a
rough idea.  If using opportunistic suspend was adding noticably
better battery life, I think this would be a different discussion.

> I really don't understand why people are so opposed to merging code
> that works well for a very large set of devices and products.  Just
> because *you* don't need it is not a sufficiently good reason to argue
> for it not be merged.  If you don't want to use it, then don't CONFIG
> it in.

At least for OMAP, I don't consider "config it out" a viable option.

We would like one kernel (in particular one PM core) to be usable for
a broad range of devices: maemo/meego, Android, webOS, Archos, and
whatever else we haven't seen yet.  Having to config in/out something
as important as core PM functionality has other consequences.  It
makes PM-aware driver and subsystem writers (and maintainers) to have
to develop and validate against two different types of PM
functionality.

As co-maintainer of the PM subsystem for an architecture (OMAP) where
people *really* care about power, I don't consider that a viable or
scalable option.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[James Bottomley]

On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote:
> > Also, how does it handle the issue of ill-behaved apps?
> 
> For userspace, apps that have polling behavior or are ill-behaved must
> be found and fixed.  Thanks to tools like powertop, this is a farily
> easy task.

That's a bit glib ... powertop can detect power consumption stats on a
running system ... if you have a polling app preventing your system from
suspending, powertop isn't necessarily going to find it ... especially
if the polling interval is of the order of powertop's.  Powertop can
find the bad tens of wakeups per second, but it only takes one wakup
every few seconds or so to drain the battery significantly when
operating on suspend from idle.

> But really, I don't consider the "ill-behaved app" problem to be a
> real-world problem.  Both in maemo/meego and Android, if someone
> writes an app that kills battery life, it will get reported as a bug,
> or get bad ratings etc.  On these kinds of devices, there is a *stong*
> developer incentive to not write battery sucking apps.

I'm not sure this is real world, either.  Developers can fire up
powertop from the command line when their phone isn't idling for as long
as it should.  But a phone is a consumer device: the average smart phone
user just wants to browse the web, get email, go to facebook and play
with some cool apps.  If one of those cool apps is rogue, they're not
really going to know which one or how to find it (and firing up powertop
from the command line isn't something which will occur to them as a
matter of routine).

One of the nice things that suspend blockers actually does is to give
the kernel a clear name for the process blocking suspend (and thus
consuming power).  This allows a nice way to assign power budget to the
application and present who's using what in a nice visible form, which
does facilitate the reporting of bad apps, even for the non-developer
user.

James

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

[James Bottomley]

On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote:
> > Also, how does it handle the issue of ill-behaved apps?
> 
> For userspace, apps that have polling behavior or are ill-behaved must
> be found and fixed.  Thanks to tools like powertop, this is a farily
> easy task.

That's a bit glib ... powertop can detect power consumption stats on a
running system ... if you have a polling app preventing your system from
suspending, powertop isn't necessarily going to find it ... especially
if the polling interval is of the order of powertop's.  Powertop can
find the bad tens of wakeups per second, but it only takes one wakup
every few seconds or so to drain the battery significantly when
operating on suspend from idle.

> But really, I don't consider the "ill-behaved app" problem to be a
> real-world problem.  Both in maemo/meego and Android, if someone
> writes an app that kills battery life, it will get reported as a bug,
> or get bad ratings etc.  On these kinds of devices, there is a *stong*
> developer incentive to not write battery sucking apps.

I'm not sure this is real world, either.  Developers can fire up
powertop from the command line when their phone isn't idling for as long
as it should.  But a phone is a consumer device: the average smart phone
user just wants to browse the web, get email, go to facebook and play
with some cool apps.  If one of those cool apps is rogue, they're not
really going to know which one or how to find it (and firing up powertop
from the command line isn't something which will occur to them as a
matter of routine).

One of the nice things that suspend blockers actually does is to give
the kernel a clear name for the process blocking suspend (and thus
consuming power).  This allows a nice way to assign power budget to the
application and present who's using what in a nice visible form, which
does facilitate the reporting of bad apps, even for the non-developer
user.

James

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > For userspace, apps that have polling behavior or are ill-behaved must
> > be found and fixed.  Thanks to tools like powertop, this is a farily
> > easy task.
> 
> That's a bit glib ... powertop can detect power consumption stats on a
> running system ... if you have a polling app preventing your system from
> suspending, powertop isn't necessarily going to find it ... especially
> if the polling interval is of the order of powertop's.  Powertop can
> find the bad tens of wakeups per second, but it only takes one wakup
> every few seconds or so to drain the battery significantly when
> operating on suspend from idle.

you can always increase powertop's interval through command line and
once you went down to 1 wakeup every two seconds, you increase
powertop's interval and try to cut down 10 more ill-behaved apps. And
you keep going until you have e.g. 1 wakeup per minute or whatever your
target is.

> > But really, I don't consider the "ill-behaved app" problem to be a
> > real-world problem.  Both in maemo/meego and Android, if someone
> > writes an app that kills battery life, it will get reported as a bug,
> > or get bad ratings etc.  On these kinds of devices, there is a *stong*
> > developer incentive to not write battery sucking apps.
> 
> I'm not sure this is real world, either.  Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should.  But a phone is a consumer device: the average smart phone
> user just wants to browse the web, get email, go to facebook and play
> with some cool apps.  If one of those cool apps is rogue, they're not
> really going to know which one or how to find it (and firing up powertop
> from the command line isn't something which will occur to them as a
> matter of routine).

Agree with you here.

> One of the nice things that suspend blockers actually does is to give
> the kernel a clear name for the process blocking suspend (and thus
> consuming power).  This allows a nice way to assign power budget to the
> application and present who's using what in a nice visible form, which
> does facilitate the reporting of bad apps, even for the non-developer
> user.

if that's the only thing we want suspend_blockers for, there are other
simpler ways to do it. Just add a kernel debugging option for anyone
doing poll() or keeping a device open() or whatever and you have the
name the of the processes consuming power and preventing system from
going into sleep.

IMO, suspend_blocker is trying to fix application problems in kernel
space by unconditionaly (well sort of) freezing userspace if there are
no suspen_blockers held. So even if application is doing
poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as
the suspend_blocker is released, that poll() will be frozen, no ?

IMO the real fix would be on that particular poll(), changing the
timeout e.g. based on cpufreq notifications or even relying completely
on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
crude example trying to show that the real issue lies on the application
rather than on kernel.

-- 
balbi

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

[Felipe Balbi]

On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > For userspace, apps that have polling behavior or are ill-behaved must
> > be found and fixed.  Thanks to tools like powertop, this is a farily
> > easy task.
> 
> That's a bit glib ... powertop can detect power consumption stats on a
> running system ... if you have a polling app preventing your system from
> suspending, powertop isn't necessarily going to find it ... especially
> if the polling interval is of the order of powertop's.  Powertop can
> find the bad tens of wakeups per second, but it only takes one wakup
> every few seconds or so to drain the battery significantly when
> operating on suspend from idle.

you can always increase powertop's interval through command line and
once you went down to 1 wakeup every two seconds, you increase
powertop's interval and try to cut down 10 more ill-behaved apps. And
you keep going until you have e.g. 1 wakeup per minute or whatever your
target is.

> > But really, I don't consider the "ill-behaved app" problem to be a
> > real-world problem.  Both in maemo/meego and Android, if someone
> > writes an app that kills battery life, it will get reported as a bug,
> > or get bad ratings etc.  On these kinds of devices, there is a *stong*
> > developer incentive to not write battery sucking apps.
> 
> I'm not sure this is real world, either.  Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should.  But a phone is a consumer device: the average smart phone
> user just wants to browse the web, get email, go to facebook and play
> with some cool apps.  If one of those cool apps is rogue, they're not
> really going to know which one or how to find it (and firing up powertop
> from the command line isn't something which will occur to them as a
> matter of routine).

Agree with you here.

> One of the nice things that suspend blockers actually does is to give
> the kernel a clear name for the process blocking suspend (and thus
> consuming power).  This allows a nice way to assign power budget to the
> application and present who's using what in a nice visible form, which
> does facilitate the reporting of bad apps, even for the non-developer
> user.

if that's the only thing we want suspend_blockers for, there are other
simpler ways to do it. Just add a kernel debugging option for anyone
doing poll() or keeping a device open() or whatever and you have the
name the of the processes consuming power and preventing system from
going into sleep.

IMO, suspend_blocker is trying to fix application problems in kernel
space by unconditionaly (well sort of) freezing userspace if there are
no suspen_blockers held. So even if application is doing
poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as
the suspend_blocker is released, that poll() will be frozen, no ?

IMO the real fix would be on that particular poll(), changing the
timeout e.g. based on cpufreq notifications or even relying completely
on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
crude example trying to show that the real issue lies on the application
rather than on kernel.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Daniel Walker]

On Mon, 2010-05-17 at 13:04 -0400, James Bottomley wrote:

> I'm not sure this is real world, either.  Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should.  But a phone is a consumer device: the average smart phone
> user just wants to browse the web, get email, go to facebook and play
> with some cool apps.  If one of those cool apps is rogue, they're not
> really going to know which one or how to find it (and firing up powertop
> from the command line isn't something which will occur to them as a
> matter of routine).
> 
> One of the nice things that suspend blockers actually does is to give
> the kernel a clear name for the process blocking suspend (and thus
> consuming power).  This allows a nice way to assign power budget to the
> application and present who's using what in a nice visible form, which
> does facilitate the reporting of bad apps, even for the non-developer
> user.

If you have an idle based PM system you could get the same information
from having scheduler statistics. Since the "bad" apps are the ones that
are always either running or ready to run, and they would hardly ever
sleep. I don't know if there are specific scheduler statistics for that,
but it doesn't seem like it would be hard to make. It's even much more
natural than getting statistics from suspend blockers, since it requires
the app to be custom made to use suspend blockers.

Daniel

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

[Daniel Walker]

On Mon, 2010-05-17 at 13:04 -0400, James Bottomley wrote:

> I'm not sure this is real world, either.  Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should.  But a phone is a consumer device: the average smart phone
> user just wants to browse the web, get email, go to facebook and play
> with some cool apps.  If one of those cool apps is rogue, they're not
> really going to know which one or how to find it (and firing up powertop
> from the command line isn't something which will occur to them as a
> matter of routine).
> 
> One of the nice things that suspend blockers actually does is to give
> the kernel a clear name for the process blocking suspend (and thus
> consuming power).  This allows a nice way to assign power budget to the
> application and present who's using what in a nice visible form, which
> does facilitate the reporting of bad apps, even for the non-developer
> user.

If you have an idle based PM system you could get the same information
from having scheduler statistics. Since the "bad" apps are the ones that
are always either running or ready to run, and they would hardly ever
sleep. I don't know if there are specific scheduler statistics for that,
but it doesn't seem like it would be hard to make. It's even much more
natural than getting statistics from suspend blockers, since it requires
the app to be custom made to use suspend blockers.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Matthew Garrett]

On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote:

> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example trying to show that the real issue lies on the application
> rather than on kernel.

We know that this problem is mostly uninteresting if your userland is 
well written. The sad truth is that it's impossible to trust that your 
userland is well written, and broadly impossible to communicate to users 
that the reason that their battery life is miserable is because of the 
applications and not because of the platform. If you don't believe that 
that's a worthwhile use case to deal with then suspend blockers buy you 
pretty much nothing. But if you do, then nobody's yet demonstrated 
another workable way for this to be handled.

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

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

[Matthew Garrett]

On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote:

> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example trying to show that the real issue lies on the application
> rather than on kernel.

We know that this problem is mostly uninteresting if your userland is 
well written. The sad truth is that it's impossible to trust that your 
userland is well written, and broadly impossible to communicate to users 
that the reason that their battery life is miserable is because of the 
applications and not because of the platform. If you don't believe that 
that's a worthwhile use case to deal with then suspend blockers buy you 
pretty much nothing. But if you do, then nobody's yet demonstrated 
another workable way for this to be handled.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[James Bottomley]

On Mon, 2010-05-17 at 20:47 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > > For userspace, apps that have polling behavior or are ill-behaved must
> > > be found and fixed.  Thanks to tools like powertop, this is a farily
> > > easy task.
> > 
> > That's a bit glib ... powertop can detect power consumption stats on a
> > running system ... if you have a polling app preventing your system from
> > suspending, powertop isn't necessarily going to find it ... especially
> > if the polling interval is of the order of powertop's.  Powertop can
> > find the bad tens of wakeups per second, but it only takes one wakup
> > every few seconds or so to drain the battery significantly when
> > operating on suspend from idle.
> 
> you can always increase powertop's interval through command line and
> once you went down to 1 wakeup every two seconds, you increase
> powertop's interval and try to cut down 10 more ill-behaved apps. And
> you keep going until you have e.g. 1 wakeup per minute or whatever your
> target is.

Have you actually tried this?  On my N1 with CM5.0.6 just running
powertop requires me to keep the USB system up (debugging cable) and
paths into the usb console ... all of this produces significant wakeup
distortion, mostly in the msm i2c subsystem.  But in all the noise it's
hard to find rogue applications.

> > > But really, I don't consider the "ill-behaved app" problem to be a
> > > real-world problem.  Both in maemo/meego and Android, if someone
> > > writes an app that kills battery life, it will get reported as a bug,
> > > or get bad ratings etc.  On these kinds of devices, there is a *stong*
> > > developer incentive to not write battery sucking apps.
> > 
> > I'm not sure this is real world, either.  Developers can fire up
> > powertop from the command line when their phone isn't idling for as long
> > as it should.  But a phone is a consumer device: the average smart phone
> > user just wants to browse the web, get email, go to facebook and play
> > with some cool apps.  If one of those cool apps is rogue, they're not
> > really going to know which one or how to find it (and firing up powertop
> > from the command line isn't something which will occur to them as a
> > matter of routine).
> 
> Agree with you here.
> 
> > One of the nice things that suspend blockers actually does is to give
> > the kernel a clear name for the process blocking suspend (and thus
> > consuming power).  This allows a nice way to assign power budget to the
> > application and present who's using what in a nice visible form, which
> > does facilitate the reporting of bad apps, even for the non-developer
> > user.
> 
> if that's the only thing we want suspend_blockers for, there are other
> simpler ways to do it.

Nice straw man slide.

The technical reason for wanting suspend blockers (as has been stated
more times than I can be bothered to go back and count) is that no-one
can currently produce a working model for race free kernel to user work
handoff and, in the face of open app stores, rogue applications are a
significant problem.  The fact that suspend blockers enables easy
identification of power hogging apps is just a very useful side effect.

James


>  Just add a kernel debugging option for anyone
> doing poll() or keeping a device open() or whatever and you have the
> name the of the processes consuming power and preventing system from
> going into sleep.
> 
> IMO, suspend_blocker is trying to fix application problems in kernel
> space by unconditionaly (well sort of) freezing userspace if there are
> no suspen_blockers held. So even if application is doing
> poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as
> the suspend_blocker is released, that poll() will be frozen, no ?
> 
> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example trying to show that the real issue lies on the application
> rather than on kernel.

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

[James Bottomley]

On Mon, 2010-05-17 at 20:47 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > > For userspace, apps that have polling behavior or are ill-behaved must
> > > be found and fixed.  Thanks to tools like powertop, this is a farily
> > > easy task.
> > 
> > That's a bit glib ... powertop can detect power consumption stats on a
> > running system ... if you have a polling app preventing your system from
> > suspending, powertop isn't necessarily going to find it ... especially
> > if the polling interval is of the order of powertop's.  Powertop can
> > find the bad tens of wakeups per second, but it only takes one wakup
> > every few seconds or so to drain the battery significantly when
> > operating on suspend from idle.
> 
> you can always increase powertop's interval through command line and
> once you went down to 1 wakeup every two seconds, you increase
> powertop's interval and try to cut down 10 more ill-behaved apps. And
> you keep going until you have e.g. 1 wakeup per minute or whatever your
> target is.

Have you actually tried this?  On my N1 with CM5.0.6 just running
powertop requires me to keep the USB system up (debugging cable) and
paths into the usb console ... all of this produces significant wakeup
distortion, mostly in the msm i2c subsystem.  But in all the noise it's
hard to find rogue applications.

> > > But really, I don't consider the "ill-behaved app" problem to be a
> > > real-world problem.  Both in maemo/meego and Android, if someone
> > > writes an app that kills battery life, it will get reported as a bug,
> > > or get bad ratings etc.  On these kinds of devices, there is a *stong*
> > > developer incentive to not write battery sucking apps.
> > 
> > I'm not sure this is real world, either.  Developers can fire up
> > powertop from the command line when their phone isn't idling for as long
> > as it should.  But a phone is a consumer device: the average smart phone
> > user just wants to browse the web, get email, go to facebook and play
> > with some cool apps.  If one of those cool apps is rogue, they're not
> > really going to know which one or how to find it (and firing up powertop
> > from the command line isn't something which will occur to them as a
> > matter of routine).
> 
> Agree with you here.
> 
> > One of the nice things that suspend blockers actually does is to give
> > the kernel a clear name for the process blocking suspend (and thus
> > consuming power).  This allows a nice way to assign power budget to the
> > application and present who's using what in a nice visible form, which
> > does facilitate the reporting of bad apps, even for the non-developer
> > user.
> 
> if that's the only thing we want suspend_blockers for, there are other
> simpler ways to do it.

Nice straw man slide.

The technical reason for wanting suspend blockers (as has been stated
more times than I can be bothered to go back and count) is that no-one
can currently produce a working model for race free kernel to user work
handoff and, in the face of open app stores, rogue applications are a
significant problem.  The fact that suspend blockers enables easy
identification of power hogging apps is just a very useful side effect.

James


>  Just add a kernel debugging option for anyone
> doing poll() or keeping a device open() or whatever and you have the
> name the of the processes consuming power and preventing system from
> going into sleep.
> 
> IMO, suspend_blocker is trying to fix application problems in kernel
> space by unconditionaly (well sort of) freezing userspace if there are
> no suspen_blockers held. So even if application is doing
> poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as
> the suspend_blocker is released, that poll() will be frozen, no ?
> 
> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example trying to show that the real issue lies on the application
> rather than on kernel.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> Have you actually tried this?  On my N1 with CM5.0.6 just running
> powertop requires me to keep the USB system up (debugging cable) and
> paths into the usb console ... all of this produces significant wakeup
> distortion, mostly in the msm i2c subsystem.  But in all the noise it's
> hard to find rogue applications.

Well, I use serial console, but in the worst case scenario I would make
powertop save the output to a memory buffer a big one, and after
finished flush to some mmc or anything like that.

> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff and, in the face of open app stores, rogue applications are a
> significant problem.  The fact that suspend blockers enables easy
> identification of power hogging apps is just a very useful side effect.

I still can't get over the fact that suspend_blockers are dealing with
userland problems in kernel space. If we can't really trust apps, I'm
sorry but companies like Google and Nokia (which I work for) will have
to setup better application acceptance on their stores. The fact that we
can get statistics of power usage from kernel space is actually really
good and could be easily automated on an AppStore environment. If it's
cause too many wakeups you report that to the developer of the app
before accepting. The same feature could be shipped on the SDK, so
developer has also early feedback about how good (or bad) his/her
application really is to the system.

IMO we should be celebrating good apps, not dealing in kernel space with
bad ones. And on top of all that, we would still need custom
applications with suspend_blockers support built into them.

-- 
balbi

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

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> Have you actually tried this?  On my N1 with CM5.0.6 just running
> powertop requires me to keep the USB system up (debugging cable) and
> paths into the usb console ... all of this produces significant wakeup
> distortion, mostly in the msm i2c subsystem.  But in all the noise it's
> hard to find rogue applications.

Well, I use serial console, but in the worst case scenario I would make
powertop save the output to a memory buffer a big one, and after
finished flush to some mmc or anything like that.

> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff and, in the face of open app stores, rogue applications are a
> significant problem.  The fact that suspend blockers enables easy
> identification of power hogging apps is just a very useful side effect.

I still can't get over the fact that suspend_blockers are dealing with
userland problems in kernel space. If we can't really trust apps, I'm
sorry but companies like Google and Nokia (which I work for) will have
to setup better application acceptance on their stores. The fact that we
can get statistics of power usage from kernel space is actually really
good and could be easily automated on an AppStore environment. If it's
cause too many wakeups you report that to the developer of the app
before accepting. The same feature could be shipped on the SDK, so
developer has also early feedback about how good (or bad) his/her
application really is to the system.

IMO we should be celebrating good apps, not dealing in kernel space with
bad ones. And on top of all that, we would still need custom
applications with suspend_blockers support built into them.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 06:58:20PM +0100, Matthew Garrett wrote:
> We know that this problem is mostly uninteresting if your userland is 
> well written. The sad truth is that it's impossible to trust that your 
> userland is well written, and broadly impossible to communicate to users 
> that the reason that their battery life is miserable is because of the 
> applications and not because of the platform. If you don't believe that 
> that's a worthwhile use case to deal with then suspend blockers buy you 
> pretty much nothing. But if you do, then nobody's yet demonstrated 
> another workable way for this to be handled.

don't get me wrong, I have faced similar problems of use time targets
due to ill-behaved applications, we just decided to deal with it with
the help of bugzilla. File a bug to that application and get the
developer to fix it. At least you are teaching the guy to fish. I
understand when you open an AppStore the problem grows bigger but, like
I replied to James, build an automated system to check average power
usage on the SDK and AppStore acceptance process and you get developers
to fix their apps before they reach the device.

-- 
balbi

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

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 06:58:20PM +0100, Matthew Garrett wrote:
> We know that this problem is mostly uninteresting if your userland is 
> well written. The sad truth is that it's impossible to trust that your 
> userland is well written, and broadly impossible to communicate to users 
> that the reason that their battery life is miserable is because of the 
> applications and not because of the platform. If you don't believe that 
> that's a worthwhile use case to deal with then suspend blockers buy you 
> pretty much nothing. But if you do, then nobody's yet demonstrated 
> another workable way for this to be handled.

don't get me wrong, I have faced similar problems of use time targets
due to ill-behaved applications, we just decided to deal with it with
the help of bugzilla. File a bug to that application and get the
developer to fix it. At least you are teaching the guy to fish. I
understand when you open an AppStore the problem grows bigger but, like
I replied to James, build an automated system to check average power
usage on the SDK and AppStore acceptance process and you get developers
to fix their apps before they reach the device.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>
>> The technical reason for wanting suspend blockers (as has been stated
>> more times than I can be bothered to go back and count) is that no-one
>> can currently produce a working model for race free kernel to user work
>> handoff and, in the face of open app stores, rogue applications are a
>> significant problem.  The fact that suspend blockers enables easy
>> identification of power hogging apps is just a very useful side effect.
>
> I still can't get over the fact that suspend_blockers are dealing with
> userland problems in kernel space. If we can't really trust apps, I'm
> sorry but companies like Google and Nokia (which I work for) will have
> to setup better application acceptance on their stores.

We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach.  Toward this
goal we're not even requiring the use of a central app store for
distribution.

Obviously, given the ability to run *any* app, users will run into bad
(or perhaps just less-than-optimal-powerwise) apps.  Being able to
provide the best possible battery life (in spite of
sometimes-nonoptimal userspace apps) and simultaneously informing
users about which apps are better/worse for their battery life is a
goal here.

> IMO we should be celebrating good apps, not dealing in kernel space with
> bad ones. And on top of all that, we would still need custom
> applications with suspend_blockers support built into them.

For a large majority of apps, running in the background while the
device is asleep (screen off) is not essential, they don't request the
"keep device awake" permission, never hold a wakelock, etc.  Those
that do need to do this have the permission, may hold suspend
blockers, and are accounted for.

Unrelated to apps, the ability to say "please enter suspend as soon as
there's no more work (kernel or userspace) preventing it", in a
simple, non-racy way is useful.

Brian

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

[Brian Swetland]

On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>
>> The technical reason for wanting suspend blockers (as has been stated
>> more times than I can be bothered to go back and count) is that no-one
>> can currently produce a working model for race free kernel to user work
>> handoff and, in the face of open app stores, rogue applications are a
>> significant problem.  The fact that suspend blockers enables easy
>> identification of power hogging apps is just a very useful side effect.
>
> I still can't get over the fact that suspend_blockers are dealing with
> userland problems in kernel space. If we can't really trust apps, I'm
> sorry but companies like Google and Nokia (which I work for) will have
> to setup better application acceptance on their stores.

We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach.  Toward this
goal we're not even requiring the use of a central app store for
distribution.

Obviously, given the ability to run *any* app, users will run into bad
(or perhaps just less-than-optimal-powerwise) apps.  Being able to
provide the best possible battery life (in spite of
sometimes-nonoptimal userspace apps) and simultaneously informing
users about which apps are better/worse for their battery life is a
goal here.

> IMO we should be celebrating good apps, not dealing in kernel space with
> bad ones. And on top of all that, we would still need custom
> applications with suspend_blockers support built into them.

For a large majority of apps, running in the background while the
device is asleep (screen off) is not essential, they don't request the
"keep device awake" permission, never hold a wakelock, etc.  Those
that do need to do this have the permission, may hold suspend
blockers, and are accounted for.

Unrelated to apps, the ability to say "please enter suspend as soon as
there's no more work (kernel or userspace) preventing it", in a
simple, non-racy way is useful.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>
>> The technical reason for wanting suspend blockers (as has been stated
>> more times than I can be bothered to go back and count) is that no-one
>> can currently produce a working model for race free kernel to user work
>> handoff and, in the face of open app stores, rogue applications are a
>> significant problem.  The fact that suspend blockers enables easy
>> identification of power hogging apps is just a very useful side effect.
>
> I still can't get over the fact that suspend_blockers are dealing with
> userland problems in kernel space. If we can't really trust apps, I'm
> sorry but companies like Google and Nokia (which I work for) will have
> to setup better application acceptance on their stores.

We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach.  Toward this
goal we're not even requiring the use of a central app store for
distribution.

Obviously, given the ability to run *any* app, users will run into bad
(or perhaps just less-than-optimal-powerwise) apps.  Being able to
provide the best possible battery life (in spite of
sometimes-nonoptimal userspace apps) and simultaneously informing
users about which apps are better/worse for their battery life is a
goal here.

> IMO we should be celebrating good apps, not dealing in kernel space with
> bad ones. And on top of all that, we would still need custom
> applications with suspend_blockers support built into them.

For a large majority of apps, running in the background while the
device is asleep (screen off) is not essential, they don't request the
"keep device awake" permission, never hold a wakelock, etc.  Those
that do need to do this have the permission, may hold suspend
blockers, and are accounted for.

Unrelated to apps, the ability to say "please enter suspend as soon as
there's no more work (kernel or userspace) preventing it", in a
simple, non-racy way is useful.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
> We (Google) would like to allow completely open app distribution with
> minimal hurdles, and avoid the walled garden approach.  Toward this
> goal we're not even requiring the use of a central app store for
> distribution.

I understand that, but still we should be telling developers what
they're doing wrong so that they can improve themselves as professionals
and still make the final device better.

> Obviously, given the ability to run *any* app, users will run into bad
> (or perhaps just less-than-optimal-powerwise) apps.  Being able to
> provide the best possible battery life (in spite of
> sometimes-nonoptimal userspace apps) and simultaneously informing
> users about which apps are better/worse for their battery life is a
> goal here.

I see. Just hope MeeGo doesn't venture on the same waters :-s

> For a large majority of apps, running in the background while the
> device is asleep (screen off) is not essential, they don't request the
> "keep device awake" permission, never hold a wakelock, etc.  Those
> that do need to do this have the permission, may hold suspend
> blockers, and are accounted for.

but can anyone write an app that holds a suspend_blocker ?? If so, then
your goal is already broken, right ? I mean, if anyone can keep a
suspend_blocker held forever, you'll never ever sleep, right ? While
with runtime, if you keep the keypad open, only the keypad and the paths
directly related to it (probably the i2c controller and the power domain
where the i2c controller sits) will be kept alive, no ?

> Unrelated to apps, the ability to say "please enter suspend as soon as
> there's no more work (kernel or userspace) preventing it", in a
> simple, non-racy way is useful.

I just tend to agree with Kevin on questioning how different how
different this actually is from runtime_pm. I guess I would need to dig
through some documentation in order to understand but it seems really
similar.

-- 
balbi

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

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
> We (Google) would like to allow completely open app distribution with
> minimal hurdles, and avoid the walled garden approach.  Toward this
> goal we're not even requiring the use of a central app store for
> distribution.

I understand that, but still we should be telling developers what
they're doing wrong so that they can improve themselves as professionals
and still make the final device better.

> Obviously, given the ability to run *any* app, users will run into bad
> (or perhaps just less-than-optimal-powerwise) apps.  Being able to
> provide the best possible battery life (in spite of
> sometimes-nonoptimal userspace apps) and simultaneously informing
> users about which apps are better/worse for their battery life is a
> goal here.

I see. Just hope MeeGo doesn't venture on the same waters :-s

> For a large majority of apps, running in the background while the
> device is asleep (screen off) is not essential, they don't request the
> "keep device awake" permission, never hold a wakelock, etc.  Those
> that do need to do this have the permission, may hold suspend
> blockers, and are accounted for.

but can anyone write an app that holds a suspend_blocker ?? If so, then
your goal is already broken, right ? I mean, if anyone can keep a
suspend_blocker held forever, you'll never ever sleep, right ? While
with runtime, if you keep the keypad open, only the keypad and the paths
directly related to it (probably the i2c controller and the power domain
where the i2c controller sits) will be kept alive, no ?

> Unrelated to apps, the ability to say "please enter suspend as soon as
> there's no more work (kernel or userspace) preventing it", in a
> simple, non-racy way is useful.

I just tend to agree with Kevin on questioning how different how
different this actually is from runtime_pm. I guess I would need to dig
through some documentation in order to understand but it seems really
similar.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.

I agree.  Which is why we develop tools to help developers understand
what their apps are doing.

>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

No, you'll never suspend, which is different from never going to the
lowest CPU power state.  On shipping Android devices we aggressively
completely power down the CPU in idle whenever we can (based on
latency requirements generally).  We power off peripherals whenever
they're not in use.

This is why I've stated previously that I don't think runtime PM and
opportunistic suspend are competitive features.  Everyone who cares
about minimizing power should want runtime pm or at least similar
functionality (our drivers have always powered down peripherals when
not in use, even while the device is open, etc, prior to the existence
of runtime PM).

If your environment is such that going to full suspend will not gain
you anything, then don't use opportunistic suspend.  We find that
there are savings to be had with this model in Android which is why we
use it.  If you are going to use opportunistic suspend,
suspend_blockers provide useful functionality.

Brian

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

[Brian Swetland]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.

I agree.  Which is why we develop tools to help developers understand
what their apps are doing.

>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

No, you'll never suspend, which is different from never going to the
lowest CPU power state.  On shipping Android devices we aggressively
completely power down the CPU in idle whenever we can (based on
latency requirements generally).  We power off peripherals whenever
they're not in use.

This is why I've stated previously that I don't think runtime PM and
opportunistic suspend are competitive features.  Everyone who cares
about minimizing power should want runtime pm or at least similar
functionality (our drivers have always powered down peripherals when
not in use, even while the device is open, etc, prior to the existence
of runtime PM).

If your environment is such that going to full suspend will not gain
you anything, then don't use opportunistic suspend.  We find that
there are savings to be had with this model in Android which is why we
use it.  If you are going to use opportunistic suspend,
suspend_blockers provide useful functionality.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.

I agree.  Which is why we develop tools to help developers understand
what their apps are doing.

>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

No, you'll never suspend, which is different from never going to the
lowest CPU power state.  On shipping Android devices we aggressively
completely power down the CPU in idle whenever we can (based on
latency requirements generally).  We power off peripherals whenever
they're not in use.

This is why I've stated previously that I don't think runtime PM and
opportunistic suspend are competitive features.  Everyone who cares
about minimizing power should want runtime pm or at least similar
functionality (our drivers have always powered down peripherals when
not in use, even while the device is open, etc, prior to the existence
of runtime PM).

If your environment is such that going to full suspend will not gain
you anything, then don't use opportunistic suspend.  We find that
there are savings to be had with this model in Android which is why we
use it.  If you are going to use opportunistic suspend,
suspend_blockers provide useful functionality.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Mon, May 17, 2010 at 09:39:05PM +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:

> > For a large majority of apps, running in the background while the
> > device is asleep (screen off) is not essential, they don't request the
> > "keep device awake" permission, never hold a wakelock, etc.  Those
> > that do need to do this have the permission, may hold suspend
> > blockers, and are accounted for.

> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

The Android UI provides a list of which applications have been
preventing suspend and how long for, the idea being that if something
has been holding suspend blockers for ever you can at least look at the
list and see what it was.

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

[Mark Brown]

On Mon, May 17, 2010 at 09:39:05PM +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:

> > For a large majority of apps, running in the background while the
> > device is asleep (screen off) is not essential, they don't request the
> > "keep device awake" permission, never hold a wakelock, etc.  Those
> > that do need to do this have the permission, may hold suspend
> > blockers, and are accounted for.

> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

The Android UI provides a list of which applications have been
preventing suspend and how long for, the idea being that if something
has been holding suspend blockers for ever you can at least look at the
list and see what it was.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mike Chan]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.
>

We currently do track power usage per-application which is displayed
in the phone UI. (Settings -> About Phone -> Battery Usage).  We also
provide several (although not perfect) command line utilities for
developers to see their power impact system.

We are constantly working on ways to improve tracking and make such
power data more accessible to developers so they can see how their
applications are impacting battery life.

>> Obviously, given the ability to run *any* app, users will run into bad
>> (or perhaps just less-than-optimal-powerwise) apps.  Being able to
>> provide the best possible battery life (in spite of
>> sometimes-nonoptimal userspace apps) and simultaneously informing
>> users about which apps are better/worse for their battery life is a
>> goal here.
>
> I see. Just hope MeeGo doesn't venture on the same waters :-s
>
>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?
>

Any app can grab a suspend blocker, and the stats are logged, and if
you're app is abusing wakelocks and CPU resource it will show up in
the "Battery Use" panel.

-- Mike

>> Unrelated to apps, the ability to say "please enter suspend as soon as
>> there's no more work (kernel or userspace) preventing it", in a
>> simple, non-racy way is useful.
>
> I just tend to agree with Kevin on questioning how different how
> different this actually is from runtime_pm. I guess I would need to dig
> through some documentation in order to understand but it seems really
> similar.
>
> --
> balbi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Mike Chan]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.
>

We currently do track power usage per-application which is displayed
in the phone UI. (Settings -> About Phone -> Battery Usage).  We also
provide several (although not perfect) command line utilities for
developers to see their power impact system.

We are constantly working on ways to improve tracking and make such
power data more accessible to developers so they can see how their
applications are impacting battery life.

>> Obviously, given the ability to run *any* app, users will run into bad
>> (or perhaps just less-than-optimal-powerwise) apps.  Being able to
>> provide the best possible battery life (in spite of
>> sometimes-nonoptimal userspace apps) and simultaneously informing
>> users about which apps are better/worse for their battery life is a
>> goal here.
>
> I see. Just hope MeeGo doesn't venture on the same waters :-s
>
>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?
>

Any app can grab a suspend blocker, and the stats are logged, and if
you're app is abusing wakelocks and CPU resource it will show up in
the "Battery Use" panel.

-- Mike

>> Unrelated to apps, the ability to say "please enter suspend as soon as
>> there's no more work (kernel or userspace) preventing it", in a
>> simple, non-racy way is useful.
>
> I just tend to agree with Kevin on questioning how different how
> different this actually is from runtime_pm. I guess I would need to dig
> through some documentation in order to understand but it seems really
> similar.
>
> --
> balbi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

James Bottomley <James.Bottomley@suse.de> writes:

> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff

At least I've never heard this technial reason stated so succinctly.  It's
not in the changelogs or in the Documentation file included.

The way I undertand things, today's mainline kernel has a race-free
kernel-to-user work handoff already.

The possibility of races is introduced by the opportunistic suspend
feature itself (patch 1.)  The use of suspend blockers later in the
series is needed to avoid the potential races introduced by
opportunistic suspend.

Kevin

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

[Kevin Hilman]

James Bottomley <James.Bottomley@suse.de> writes:

> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff

At least I've never heard this technial reason stated so succinctly.  It's
not in the changelogs or in the Documentation file included.

The way I undertand things, today's mainline kernel has a race-free
kernel-to-user work handoff already.

The possibility of races is introduced by the opportunistic suspend
feature itself (patch 1.)  The use of suspend blockers later in the
series is needed to avoid the potential races introduced by
opportunistic suspend.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[James Bottomley]

On Mon, 2010-05-17 at 21:12 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> > Have you actually tried this?  On my N1 with CM5.0.6 just running
> > powertop requires me to keep the USB system up (debugging cable) and
> > paths into the usb console ... all of this produces significant wakeup
> > distortion, mostly in the msm i2c subsystem.  But in all the noise it's
> > hard to find rogue applications.
> 
> Well, I use serial console, but in the worst case scenario I would make
> powertop save the output to a memory buffer a big one, and after
> finished flush to some mmc or anything like that.

Surely, depending on your UART FIFO depth, of course, a serial console
interrupts once every 16 characters or so ... how do you filter out that
storm of interrupts refreshing the powertop screen from the actual
application problems?

But anyway, the average user probably either doesn't have or doesn't
know how to get to a serial console on their phone ...

> > The technical reason for wanting suspend blockers (as has been stated
> > more times than I can be bothered to go back and count) is that no-one
> > can currently produce a working model for race free kernel to user work
> > handoff and, in the face of open app stores, rogue applications are a
> > significant problem.  The fact that suspend blockers enables easy
> > identification of power hogging apps is just a very useful side effect.
> 
> I still can't get over the fact that suspend_blockers are dealing with
> userland problems in kernel space. If we can't really trust apps, I'm
> sorry but companies like Google and Nokia (which I work for) will have
> to setup better application acceptance on their stores. The fact that we
> can get statistics of power usage from kernel space is actually really
> good and could be easily automated on an AppStore environment. If it's
> cause too many wakeups you report that to the developer of the app
> before accepting. The same feature could be shipped on the SDK, so
> developer has also early feedback about how good (or bad) his/her
> application really is to the system.
> 
> IMO we should be celebrating good apps, not dealing in kernel space with
> bad ones. And on top of all that, we would still need custom
> applications with suspend_blockers support built into them.

If you actually s/app/USB storage device/ (with a few other obvious text
changes) in most of the above two paragraphs, you've got a good
description of the problems we go through on an almost daily basis in
the kernel for USB storage ... and why we've grown a massive exception
table.

Just saying "devices should conform to specifications" is a wonderful
magic wand for wishing away all the problems bad devices cause and
bludgeoning manufacturers with the said spec wrapped around a large lead
brick is very cathartic but it doesn't change the fact that users blame
the kernel for not working with the bad devices ... and we gave up
trying to re-educate users on that score years ago.

James

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

[James Bottomley]

On Mon, 2010-05-17 at 21:12 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> > Have you actually tried this?  On my N1 with CM5.0.6 just running
> > powertop requires me to keep the USB system up (debugging cable) and
> > paths into the usb console ... all of this produces significant wakeup
> > distortion, mostly in the msm i2c subsystem.  But in all the noise it's
> > hard to find rogue applications.
> 
> Well, I use serial console, but in the worst case scenario I would make
> powertop save the output to a memory buffer a big one, and after
> finished flush to some mmc or anything like that.

Surely, depending on your UART FIFO depth, of course, a serial console
interrupts once every 16 characters or so ... how do you filter out that
storm of interrupts refreshing the powertop screen from the actual
application problems?

But anyway, the average user probably either doesn't have or doesn't
know how to get to a serial console on their phone ...

> > The technical reason for wanting suspend blockers (as has been stated
> > more times than I can be bothered to go back and count) is that no-one
> > can currently produce a working model for race free kernel to user work
> > handoff and, in the face of open app stores, rogue applications are a
> > significant problem.  The fact that suspend blockers enables easy
> > identification of power hogging apps is just a very useful side effect.
> 
> I still can't get over the fact that suspend_blockers are dealing with
> userland problems in kernel space. If we can't really trust apps, I'm
> sorry but companies like Google and Nokia (which I work for) will have
> to setup better application acceptance on their stores. The fact that we
> can get statistics of power usage from kernel space is actually really
> good and could be easily automated on an AppStore environment. If it's
> cause too many wakeups you report that to the developer of the app
> before accepting. The same feature could be shipped on the SDK, so
> developer has also early feedback about how good (or bad) his/her
> application really is to the system.
> 
> IMO we should be celebrating good apps, not dealing in kernel space with
> bad ones. And on top of all that, we would still need custom
> applications with suspend_blockers support built into them.

If you actually s/app/USB storage device/ (with a few other obvious text
changes) in most of the above two paragraphs, you've got a good
description of the problems we go through on an almost daily basis in
the kernel for USB storage ... and why we've grown a massive exception
table.

Just saying "devices should conform to specifications" is a wonderful
magic wand for wishing away all the problems bad devices cause and
bludgeoning manufacturers with the said spec wrapped around a large lead
brick is very cathartic but it doesn't change the fact that users blame
the kernel for not working with the bad devices ... and we gave up
trying to re-educate users on that score years ago.

James

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

[Vitaly Wool]

On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:

>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>> is **appalling** **bad**.
>
> Appalling bad compared to what?
>
> What's probably more interesting in terms of rough comparisons is
> comparing similar devices with and without opportunistic suspend.  The
> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
> OMAP3) and roughly the same kernel (2.6.2[89], although both are
> heavily patched from mainline.)
>
> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>
> I don't know of any more objective comparison of the two, but as a
> user of both devices I can say that the active usage is basically the
> same (around a day) and the idle use is similar as well, even though
> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
> own usage suggests the n900 is a bit better in idle time, but I have
> not done any measuring or objective tests.  I'm guessing the
> difference is probably because the Droid does not use the deepest
> off-mode power states either in idle or suspend (IIRC) where the n900
> does.  I suspect that if both were using off-mode and had the same
> battery, these differences would go away.
>
> While this is not really a scientific comparison, it at least gives a
> rough idea.  If using opportunistic suspend was adding noticably
> better battery life, I think this would be a different discussion.

Exactly. The point is, opportunistic suspend doesn't in fact add any
value compared to dynamic PM + CPUIdle. It only produces some false
impression that one can handle power management right without using
dynamic PM. And this false impression is the cause for many really
ugly designs (like, for instance, 15 minutes touchscreen inactivity
delay before forcibly shutting down the wireless, as it's done in
stock Android framework).

Thanks,
   Vitaly

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

[Matthew Garrett]

On Mon, May 17, 2010 at 09:27:47PM +0200, Vitaly Wool wrote:

> Exactly. The point is, opportunistic suspend doesn't in fact add any
> value compared to dynamic PM + CPUIdle. It only produces some false
> impression that one can handle power management right without using
> dynamic PM. And this false impression is the cause for many really
> ugly designs (like, for instance, 15 minutes touchscreen inactivity
> delay before forcibly shutting down the wireless, as it's done in
> stock Android framework).

Run this (or equivalent code) on an N900 and on an Android. Measure the 
screen-off power draw on both.

int main() {
	int i;
	while (1)
		i++;
	return 0;
}

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote:
> Surely, depending on your UART FIFO depth, of course, a serial console
> interrupts once every 16 characters or so ... how do you filter out that
> storm of interrupts refreshing the powertop screen from the actual
> application problems?
> 
> But anyway, the average user probably either doesn't have or doesn't
> know how to get to a serial console on their phone ...

like I said: use a big memory buffer and print to that. Only flush after
you're done profiling. Something like dmesg.

> If you actually s/app/USB storage device/ (with a few other obvious text
> changes) in most of the above two paragraphs, you've got a good
> description of the problems we go through on an almost daily basis in
> the kernel for USB storage ... and why we've grown a massive exception
> table.
> 
> Just saying "devices should conform to specifications" is a wonderful
> magic wand for wishing away all the problems bad devices cause and
> bludgeoning manufacturers with the said spec wrapped around a large lead
> brick is very cathartic but it doesn't change the fact that users blame
> the kernel for not working with the bad devices ... and we gave up
> trying to re-educate users on that score years ago.

that's a whole other story. Hardware issues are things which in 99.999%
of the cases we can't change. We have to work around them. Software
bugs, on the other hand, can be fixed much more easily. I'm sure you
agree with that, don't you ?

Trying to make a comparisson between hardware bug and software bug is
simply non-sense in this case.

-- 
balbi

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

[Felipe Balbi]

Hi,

On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote:
> Surely, depending on your UART FIFO depth, of course, a serial console
> interrupts once every 16 characters or so ... how do you filter out that
> storm of interrupts refreshing the powertop screen from the actual
> application problems?
> 
> But anyway, the average user probably either doesn't have or doesn't
> know how to get to a serial console on their phone ...

like I said: use a big memory buffer and print to that. Only flush after
you're done profiling. Something like dmesg.

> If you actually s/app/USB storage device/ (with a few other obvious text
> changes) in most of the above two paragraphs, you've got a good
> description of the problems we go through on an almost daily basis in
> the kernel for USB storage ... and why we've grown a massive exception
> table.
> 
> Just saying "devices should conform to specifications" is a wonderful
> magic wand for wishing away all the problems bad devices cause and
> bludgeoning manufacturers with the said spec wrapped around a large lead
> brick is very cathartic but it doesn't change the fact that users blame
> the kernel for not working with the bad devices ... and we gave up
> trying to re-educate users on that score years ago.

that's a whole other story. Hardware issues are things which in 99.999%
of the cases we can't change. We have to work around them. Software
bugs, on the other hand, can be fixed much more easily. I'm sure you
agree with that, don't you ?

Trying to make a comparisson between hardware bug and software bug is
simply non-sense in this case.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

hi,

On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> that's a whole other story. Hardware issues are things which in 99.999%
> of the cases we can't change. We have to work around them. Software
> bugs, on the other hand, can be fixed much more easily. I'm sure you
> agree with that, don't you ?
> 
> Trying to make a comparisson between hardware bug and software bug is
> simply non-sense in this case.

before you reply saying that most of the problems are firmware bugs, try
to file a bug to any of the usb storage manufacturers and wait for them
to fix. It's virtualy impossible, so let's consider it a problem that
has to be worked around.

-- 
balbi

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

[Felipe Balbi]

hi,

On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> that's a whole other story. Hardware issues are things which in 99.999%
> of the cases we can't change. We have to work around them. Software
> bugs, on the other hand, can be fixed much more easily. I'm sure you
> agree with that, don't you ?
> 
> Trying to make a comparisson between hardware bug and software bug is
> simply non-sense in this case.

before you reply saying that most of the problems are firmware bugs, try
to file a bug to any of the usb storage manufacturers and wait for them
to fix. It's virtualy impossible, so let's consider it a problem that
has to be worked around.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[James Bottomley]

On Mon, 2010-05-17 at 22:39 +0300, Felipe Balbi wrote:
> hi,
> 
> On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> > that's a whole other story. Hardware issues are things which in 99.999%
> > of the cases we can't change. We have to work around them. Software
> > bugs, on the other hand, can be fixed much more easily. I'm sure you
> > agree with that, don't you ?
> > 
> > Trying to make a comparisson between hardware bug and software bug is
> > simply non-sense in this case.
> 
> before you reply saying that most of the problems are firmware bugs, try
> to file a bug to any of the usb storage manufacturers and wait for them
> to fix. It's virtualy impossible, so let's consider it a problem that
> has to be worked around.

Right, because Firmware writers are from the rugged unresponsive uplands
of planet
ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
Software writers are from the emollient responsive groves of planet
harmony.  Obviously what would work for one wouldn't work for the other.

As a software writer, I fully buy into that world view.  The trouble is
that when I go to dinner with hardware people, they seem to be awfully
nice chaps ... almost exactly like me, in fact ...

James

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

[James Bottomley]

On Mon, 2010-05-17 at 22:39 +0300, Felipe Balbi wrote:
> hi,
> 
> On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> > that's a whole other story. Hardware issues are things which in 99.999%
> > of the cases we can't change. We have to work around them. Software
> > bugs, on the other hand, can be fixed much more easily. I'm sure you
> > agree with that, don't you ?
> > 
> > Trying to make a comparisson between hardware bug and software bug is
> > simply non-sense in this case.
> 
> before you reply saying that most of the problems are firmware bugs, try
> to file a bug to any of the usb storage manufacturers and wait for them
> to fix. It's virtualy impossible, so let's consider it a problem that
> has to be worked around.

Right, because Firmware writers are from the rugged unresponsive uplands
of planet
ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
Software writers are from the emollient responsive groves of planet
harmony.  Obviously what would work for one wouldn't work for the other.

As a software writer, I fully buy into that world view.  The trouble is
that when I go to dinner with hardware people, they seem to be awfully
nice chaps ... almost exactly like me, in fact ...

James

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

[Daniel Walker]

On Mon, 2010-05-17 at 20:34 +0100, Matthew Garrett wrote:

> int main() {
> 	int i;
> 	while (1)
> 		i++;
> 	return 0;
> }
> 

We already know it's really rare on an embedded system you would get
this bad of an app. However, if you assume that you might have this 1 in
a million app, couldn't we just have a watch dog that identifies and
kills it. It would also let the user know what happened of course.
Killing the app seems pretty reasonable to me.

Daniel

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

[Matthew Garrett]

On Mon, May 17, 2010 at 12:50:40PM -0700, Daniel Walker wrote:
> On Mon, 2010-05-17 at 20:34 +0100, Matthew Garrett wrote:
> 
> > int main() {
> > 	int i;
> > 	while (1)
> > 		i++;
> > 	return 0;
> > }
> > 
> 
> We already know it's really rare on an embedded system you would get
> this bad of an app. However, if you assume that you might have this 1 in
> a million app, couldn't we just have a watch dog that identifies and
> kills it. It would also let the user know what happened of course.
> Killing the app seems pretty reasonable to me.

In a world where anyone can provide this kind of app for Android users, 
I'd submit that it's going to be significantly more common than that. 
I'd expect real world cases to be at least slightly more subtle, but...

But yeah. Fundamentally the real argument here isn't about suspend 
blockers. It's about whether it's valid to require that the Linux kernel 
provide mechanisms to enable power management in the face of poorly 
written applications. If you think that that argument is invalid then 
suspend blockers are an entirely unnecessary set of layering violations. 
If you think it's valid, suspend blockers are the only currently 
proposed solution that will work in a race-free manner.

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

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

[Brian Swetland]

On Mon, May 17, 2010 at 12:50 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Mon, 2010-05-17 at 20:34 +0100, Matthew Garrett wrote:
>
>> int main() {
>>       int i;
>>       while (1)
>>               i++;
>>       return 0;
>> }
>>
>
> We already know it's really rare on an embedded system you would get
> this bad of an app. However, if you assume that you might have this 1 in
> a million app, couldn't we just have a watch dog that identifies and
> kills it. It would also let the user know what happened of course.
> Killing the app seems pretty reasonable to me.

However, it is not uncommon to run into apps that poll once (or
several times) a second for IO, or have other behavior that's not
*quite* as bad as constantly running but still ends up having a
significant impact on battery life.  Polling even on "reasonable"
intervals can make a huge difference in overall battery life while not
having a very visible impact on device performance when the device is
being used interactively.  opportunistic suspend helps a lot here.

We see this in the field with real apps on real devices -- there's a
lot of not so great code out there.

Sometimes those apps are apps that, despite being badly written, do
things users want.  Thus both reducing the impact of these bad apps
and educating users and developers about the apps being bad for their
battery life is worthwhile.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mike Chan]

On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>
>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>> is **appalling** **bad**.
>>
>> Appalling bad compared to what?
>>
>> What's probably more interesting in terms of rough comparisons is
>> comparing similar devices with and without opportunistic suspend.  The
>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>> heavily patched from mainline.)
>>
>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>
>> I don't know of any more objective comparison of the two, but as a
>> user of both devices I can say that the active usage is basically the
>> same (around a day) and the idle use is similar as well, even though
>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>> own usage suggests the n900 is a bit better in idle time, but I have
>> not done any measuring or objective tests.  I'm guessing the
>> difference is probably because the Droid does not use the deepest
>> off-mode power states either in idle or suspend (IIRC) where the n900
>> does.  I suspect that if both were using off-mode and had the same
>> battery, these differences would go away.
>>

Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
and Droid's perceived user battery life to one another to evaluate
opportunistic suspend. There are many factors uncounted for such as:
network reception, screen brightness (and size), button back-light,
keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
in uerspace.

>> While this is not really a scientific comparison, it at least gives a
>> rough idea.  If using opportunistic suspend was adding noticably
>> better battery life, I think this would be a different discussion.
>
> Exactly. The point is, opportunistic suspend doesn't in fact add any
> value compared to dynamic PM + CPUIdle. It only produces some false
> impression that one can handle power management right without using
> dynamic PM. And this false impression is the cause for many really
> ugly designs (like, for instance, 15 minutes touchscreen inactivity
> delay before forcibly shutting down the wireless, as it's done in
> stock Android framework).
>

Opportunistic suspend is an extension to the current suspend model,
not a replacement dynamic / run-time PM. If you can replace good old
suspend then this would be a different story.

As you mention, Droid uses opportunistic suspend + dynamic pm +
cpuidle + freq. So I decided to do some measurements on a Droid using
our 2.9.32 kernel
(http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
little better apples to apples comparison.

Droid (idle system, airplane mode, screen off, 3 min interval):
measured average current
- with opportunity suspend: 3.19mA
- without opportunistic suspend: 3.5mA

Stock userspace build, all I did was replace the kernel. We are
hitting retention on idle as well as suspend for omap (instead of full
off-mode).

Also, your point about wifi, the 15 min timeout is in the framework
and is configurable in the code and via UI, nothing to do with kernel,
opportunistic suspend or run time suspend.


-- Mike

> Thanks,
>   Vitaly
> _______________________________________________
> 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 6)

[Mike Chan]

On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>
>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>> is **appalling** **bad**.
>>
>> Appalling bad compared to what?
>>
>> What's probably more interesting in terms of rough comparisons is
>> comparing similar devices with and without opportunistic suspend.  The
>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>> heavily patched from mainline.)
>>
>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>
>> I don't know of any more objective comparison of the two, but as a
>> user of both devices I can say that the active usage is basically the
>> same (around a day) and the idle use is similar as well, even though
>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>> own usage suggests the n900 is a bit better in idle time, but I have
>> not done any measuring or objective tests.  I'm guessing the
>> difference is probably because the Droid does not use the deepest
>> off-mode power states either in idle or suspend (IIRC) where the n900
>> does.  I suspect that if both were using off-mode and had the same
>> battery, these differences would go away.
>>

Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
and Droid's perceived user battery life to one another to evaluate
opportunistic suspend. There are many factors uncounted for such as:
network reception, screen brightness (and size), button back-light,
keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
in uerspace.

>> While this is not really a scientific comparison, it at least gives a
>> rough idea.  If using opportunistic suspend was adding noticably
>> better battery life, I think this would be a different discussion.
>
> Exactly. The point is, opportunistic suspend doesn't in fact add any
> value compared to dynamic PM + CPUIdle. It only produces some false
> impression that one can handle power management right without using
> dynamic PM. And this false impression is the cause for many really
> ugly designs (like, for instance, 15 minutes touchscreen inactivity
> delay before forcibly shutting down the wireless, as it's done in
> stock Android framework).
>

Opportunistic suspend is an extension to the current suspend model,
not a replacement dynamic / run-time PM. If you can replace good old
suspend then this would be a different story.

As you mention, Droid uses opportunistic suspend + dynamic pm +
cpuidle + freq. So I decided to do some measurements on a Droid using
our 2.9.32 kernel
(http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
little better apples to apples comparison.

Droid (idle system, airplane mode, screen off, 3 min interval):
measured average current
- with opportunity suspend: 3.19mA
- without opportunistic suspend: 3.5mA

Stock userspace build, all I did was replace the kernel. We are
hitting retention on idle as well as suspend for omap (instead of full
off-mode).

Also, your point about wifi, the 15 min timeout is in the framework
and is configurable in the code and via UI, nothing to do with kernel,
opportunistic suspend or run time suspend.


-- Mike

> Thanks,
>   Vitaly
> _______________________________________________
> 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 6)

[Rafael J. Wysocki]

On Monday 17 May 2010, Kevin Hilman wrote:
> tytso@mit.edu writes:
...
> At least for OMAP, I don't consider "config it out" a viable option.
> 
> We would like one kernel (in particular one PM core) to be usable for
> a broad range of devices: maemo/meego, Android, webOS, Archos, and
> whatever else we haven't seen yet.

You don't need to config it out in the first place, so this argument doesn't
really fly.  Besides, I don't get how rejecting the opportunisting suspend
feature would help us achieve this goal.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike@android.com> wrote:
> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.
>
>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.

Yes, but what does it extend? What aspect it makes the current suspend
model better in?

> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.
>
> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

That's implementation specific. If CPUIdle implemented CPU deep sleep,
I bet you would see different figures.

> Also, your point about wifi, the 15 min timeout is in the framework
> and is configurable in the code and via UI, nothing to do with kernel,
> opportunistic suspend or run time suspend.

You don't quite get it :) This should NOT at all be timeout driven.
This should be activity driven or constraint driven which perfectly
fits into the runtime PM paradigm but is in no way cleanly implemented
within the "pure" Android PM.

Thanks,
   Vitaly

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

[Vitaly Wool]

On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike@android.com> wrote:
> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.
>
>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.

Yes, but what does it extend? What aspect it makes the current suspend
model better in?

> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.
>
> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

That's implementation specific. If CPUIdle implemented CPU deep sleep,
I bet you would see different figures.

> Also, your point about wifi, the 15 min timeout is in the framework
> and is configurable in the code and via UI, nothing to do with kernel,
> opportunistic suspend or run time suspend.

You don't quite get it :) This should NOT at all be timeout driven.
This should be activity driven or constraint driven which perfectly
fits into the runtime PM paradigm but is in no way cleanly implemented
within the "pure" Android PM.

Thanks,
   Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Vitaly Wool]

On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike@android.com> wrote:
> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.
>
>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.

Yes, but what does it extend? What aspect it makes the current suspend
model better in?

> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.
>
> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

That's implementation specific. If CPUIdle implemented CPU deep sleep,
I bet you would see different figures.

> Also, your point about wifi, the 15 min timeout is in the framework
> and is configurable in the code and via UI, nothing to do with kernel,
> opportunistic suspend or run time suspend.

You don't quite get it :) This should NOT at all be timeout driven.
This should be activity driven or constraint driven which perfectly
fits into the runtime PM paradigm but is in no way cleanly implemented
within the "pure" Android PM.

Thanks,
   Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Monday 17 May 2010, Brian Swetland wrote:
> On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
...
> > but can anyone write an app that holds a suspend_blocker ?? If so, then
> > your goal is already broken, right ? I mean, if anyone can keep a
> > suspend_blocker held forever, you'll never ever sleep, right ? While
> > with runtime, if you keep the keypad open, only the keypad and the paths
> > directly related to it (probably the i2c controller and the power domain
> > where the i2c controller sits) will be kept alive, no ?
> 
> No, you'll never suspend, which is different from never going to the
> lowest CPU power state.  On shipping Android devices we aggressively
> completely power down the CPU in idle whenever we can (based on
> latency requirements generally).  We power off peripherals whenever
> they're not in use.
> 
> This is why I've stated previously that I don't think runtime PM and
> opportunistic suspend are competitive features.

Agreed.

> Everyone who cares about minimizing power should want runtime pm or at least
> similar functionality (our drivers have always powered down peripherals when
> not in use, even while the device is open, etc, prior to the existence
> of runtime PM).

Yes.

> If your environment is such that going to full suspend will not gain
> you anything, then don't use opportunistic suspend.

Exactly.

> We find that there are savings to be had with this model in Android which is
> why we use it.  If you are going to use opportunistic suspend,
> suspend_blockers provide useful functionality.

And as I said, I regard this as a legitimate approach to power management.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Monday 17 May 2010, Brian Swetland wrote:
> On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
...
> > but can anyone write an app that holds a suspend_blocker ?? If so, then
> > your goal is already broken, right ? I mean, if anyone can keep a
> > suspend_blocker held forever, you'll never ever sleep, right ? While
> > with runtime, if you keep the keypad open, only the keypad and the paths
> > directly related to it (probably the i2c controller and the power domain
> > where the i2c controller sits) will be kept alive, no ?
> 
> No, you'll never suspend, which is different from never going to the
> lowest CPU power state.  On shipping Android devices we aggressively
> completely power down the CPU in idle whenever we can (based on
> latency requirements generally).  We power off peripherals whenever
> they're not in use.
> 
> This is why I've stated previously that I don't think runtime PM and
> opportunistic suspend are competitive features.

Agreed.

> Everyone who cares about minimizing power should want runtime pm or at least
> similar functionality (our drivers have always powered down peripherals when
> not in use, even while the device is open, etc, prior to the existence
> of runtime PM).

Yes.

> If your environment is such that going to full suspend will not gain
> you anything, then don't use opportunistic suspend.

Exactly.

> We find that there are savings to be had with this model in Android which is
> why we use it.  If you are going to use opportunistic suspend,
> suspend_blockers provide useful functionality.

And as I said, I regard this as a legitimate approach to power management.

Thanks,
Rafael

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

[Linus WALLEIJ]

[Matthew]

> Run this (or equivalent code) on an N900 and on an Android. Measure the
> screen-off power draw on both.
> 
> int main() {
> 	int i;
> 	while (1)
> 		i++;
> 	return 0;
> }

I understand the problem such that the scheduler cannot determine whether
a certain process should be allowed to schedule or not.

It strikes me that the intuitive solution is to group all un-trusted 
processes/threads/tasks that need to be shut off even if they are
scheduling into a control group and let the idle code ignore the
processes in this group.

Or is there something too naïve about this?

Android is already using control groups to give some processes an
extra share of CPU and some less IIRC.

Yours,
Linus Walleij

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mike Chan]

On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike@android.com> wrote:
>> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>
>>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>>> is **appalling** **bad**.
>>>>
>>>> Appalling bad compared to what?
>>>>
>>>> What's probably more interesting in terms of rough comparisons is
>>>> comparing similar devices with and without opportunistic suspend.  The
>>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>>> heavily patched from mainline.)
>>>>
>>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>>
>>>> I don't know of any more objective comparison of the two, but as a
>>>> user of both devices I can say that the active usage is basically the
>>>> same (around a day) and the idle use is similar as well, even though
>>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>>> own usage suggests the n900 is a bit better in idle time, but I have
>>>> not done any measuring or objective tests.  I'm guessing the
>>>> difference is probably because the Droid does not use the deepest
>>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>>> does.  I suspect that if both were using off-mode and had the same
>>>> battery, these differences would go away.
>>>>
>>
>> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
>> and Droid's perceived user battery life to one another to evaluate
>> opportunistic suspend. There are many factors uncounted for such as:
>> network reception, screen brightness (and size), button back-light,
>> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
>> in uerspace.
>>
>>>> While this is not really a scientific comparison, it at least gives a
>>>> rough idea.  If using opportunistic suspend was adding noticably
>>>> better battery life, I think this would be a different discussion.
>>>


Okay, I measured with and without using the scientific method. With a
1390mAh battery, if you set your device in airplane mode you will get
435.7 hours of standby vs 397.14 hours of standby.

Is this data sufficient for a "different discussion" now?

>>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>>> value compared to dynamic PM + CPUIdle. It only produces some false
>>> impression that one can handle power management right without using
>>> dynamic PM. And this false impression is the cause for many really
>>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>>> delay before forcibly shutting down the wireless, as it's done in
>>> stock Android framework).
>>>
>>
>> Opportunistic suspend is an extension to the current suspend model,
>> not a replacement dynamic / run-time PM. If you can replace good old
>> suspend then this would be a different story.
>
> Yes, but what does it extend? What aspect it makes the current suspend
> model better in?
>

Network configuration and cell reception is a big factor here. You can
easily get +4-8mA on the original numbers I gave below, so its large
enough to skew your "perceived" power usage.

>> As you mention, Droid uses opportunistic suspend + dynamic pm +
>> cpuidle + freq. So I decided to do some measurements on a Droid using
>> our 2.9.32 kernel
>> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
>> little better apples to apples comparison.
>>
>> Droid (idle system, airplane mode, screen off, 3 min interval):
>> measured average current
>> - with opportunity suspend: 3.19mA
>> - without opportunistic suspend: 3.5mA
>>
>> Stock userspace build, all I did was replace the kernel. We are
>> hitting retention on idle as well as suspend for omap (instead of full
>> off-mode).
>
> That's implementation specific. If CPUIdle implemented CPU deep sleep,
> I bet you would see different figures.
>

The important part here is not the absolute value, but how they
compare relatively. If I added off-mode support then I the averages
would both drop, but they would not be the same (key point).

I simply wanted show with real numbers that there is a difference in
opportunistic suspend and without. Instead of purely hypothesizing
that there is no power benefit from using opportunistic suspend.


>> Also, your point about wifi, the 15 min timeout is in the framework
>> and is configurable in the code and via UI, nothing to do with kernel,
>> opportunistic suspend or run time suspend.
>
> You don't quite get it :) This should NOT at all be timeout driven.
> This should be activity driven or constraint driven which perfectly
> fits into the runtime PM paradigm but is in no way cleanly implemented
> within the "pure" Android PM.
>

I admit, our timeout approach is a bit hacky, but there is method for
the madness.

In order to properly determine when you should turn off wifi for
"perfect" power management, you need to know a few things. 1) When, in
the 'future' is the user going to turn on the screen. 2) How many
network packets will be sent  to the device while the screen is off.

Some of these factors are Android specific, in particular the device
always has a TCP connection open to google servers. So switching from
WIFI -> 3G for example causes us to generate extra network traffic as
we try to establish our SSL connection to google servers. Likewise
this cost is paid when moving from 3G -> wifi.

Its *really* hard to predict the future, so we use this timeout based
off of various heuristics, usability studies and power measurements.

So we attempt to minimize excessive network io for both power reasons
and network reasons (ie: cell carriers), as well as user experience
(latency to connect / disconnect to a wifi access point).

However we are not talking about kernel power management here, we are
talking about Android policy that might be dedicated by various OEM /
carrier requirements and user experience. I wouldn't necessarily go so
far and say its flat out "wrong" what we are doing, but I do feel that
it is Android specific enough that having our own policy for this is
valid.

If you feel strongly against this, I will be more than happy to dive
into details in an android specific thread off lkml.

-- Mike

> Thanks,
>   Vitaly
>

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

[Mike Chan]

On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike@android.com> wrote:
>> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>
>>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>>> is **appalling** **bad**.
>>>>
>>>> Appalling bad compared to what?
>>>>
>>>> What's probably more interesting in terms of rough comparisons is
>>>> comparing similar devices with and without opportunistic suspend.  The
>>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>>> heavily patched from mainline.)
>>>>
>>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>>
>>>> I don't know of any more objective comparison of the two, but as a
>>>> user of both devices I can say that the active usage is basically the
>>>> same (around a day) and the idle use is similar as well, even though
>>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>>> own usage suggests the n900 is a bit better in idle time, but I have
>>>> not done any measuring or objective tests.  I'm guessing the
>>>> difference is probably because the Droid does not use the deepest
>>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>>> does.  I suspect that if both were using off-mode and had the same
>>>> battery, these differences would go away.
>>>>
>>
>> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
>> and Droid's perceived user battery life to one another to evaluate
>> opportunistic suspend. There are many factors uncounted for such as:
>> network reception, screen brightness (and size), button back-light,
>> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
>> in uerspace.
>>
>>>> While this is not really a scientific comparison, it at least gives a
>>>> rough idea.  If using opportunistic suspend was adding noticably
>>>> better battery life, I think this would be a different discussion.
>>>


Okay, I measured with and without using the scientific method. With a
1390mAh battery, if you set your device in airplane mode you will get
435.7 hours of standby vs 397.14 hours of standby.

Is this data sufficient for a "different discussion" now?

>>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>>> value compared to dynamic PM + CPUIdle. It only produces some false
>>> impression that one can handle power management right without using
>>> dynamic PM. And this false impression is the cause for many really
>>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>>> delay before forcibly shutting down the wireless, as it's done in
>>> stock Android framework).
>>>
>>
>> Opportunistic suspend is an extension to the current suspend model,
>> not a replacement dynamic / run-time PM. If you can replace good old
>> suspend then this would be a different story.
>
> Yes, but what does it extend? What aspect it makes the current suspend
> model better in?
>

Network configuration and cell reception is a big factor here. You can
easily get +4-8mA on the original numbers I gave below, so its large
enough to skew your "perceived" power usage.

>> As you mention, Droid uses opportunistic suspend + dynamic pm +
>> cpuidle + freq. So I decided to do some measurements on a Droid using
>> our 2.9.32 kernel
>> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
>> little better apples to apples comparison.
>>
>> Droid (idle system, airplane mode, screen off, 3 min interval):
>> measured average current
>> - with opportunity suspend: 3.19mA
>> - without opportunistic suspend: 3.5mA
>>
>> Stock userspace build, all I did was replace the kernel. We are
>> hitting retention on idle as well as suspend for omap (instead of full
>> off-mode).
>
> That's implementation specific. If CPUIdle implemented CPU deep sleep,
> I bet you would see different figures.
>

The important part here is not the absolute value, but how they
compare relatively. If I added off-mode support then I the averages
would both drop, but they would not be the same (key point).

I simply wanted show with real numbers that there is a difference in
opportunistic suspend and without. Instead of purely hypothesizing
that there is no power benefit from using opportunistic suspend.


>> Also, your point about wifi, the 15 min timeout is in the framework
>> and is configurable in the code and via UI, nothing to do with kernel,
>> opportunistic suspend or run time suspend.
>
> You don't quite get it :) This should NOT at all be timeout driven.
> This should be activity driven or constraint driven which perfectly
> fits into the runtime PM paradigm but is in no way cleanly implemented
> within the "pure" Android PM.
>

I admit, our timeout approach is a bit hacky, but there is method for
the madness.

In order to properly determine when you should turn off wifi for
"perfect" power management, you need to know a few things. 1) When, in
the 'future' is the user going to turn on the screen. 2) How many
network packets will be sent  to the device while the screen is off.

Some of these factors are Android specific, in particular the device
always has a TCP connection open to google servers. So switching from
WIFI -> 3G for example causes us to generate extra network traffic as
we try to establish our SSL connection to google servers. Likewise
this cost is paid when moving from 3G -> wifi.

Its *really* hard to predict the future, so we use this timeout based
off of various heuristics, usability studies and power measurements.

So we attempt to minimize excessive network io for both power reasons
and network reasons (ie: cell carriers), as well as user experience
(latency to connect / disconnect to a wifi access point).

However we are not talking about kernel power management here, we are
talking about Android policy that might be dedicated by various OEM /
carrier requirements and user experience. I wouldn't necessarily go so
far and say its flat out "wrong" what we are doing, but I do feel that
it is Android specific enough that having our own policy for this is
valid.

If you feel strongly against this, I will be more than happy to dive
into details in an android specific thread off lkml.

-- Mike

> Thanks,
>   Vitaly
>

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

[Matthew Garrett]

On Mon, May 17, 2010 at 10:53:36PM +0200, Linus WALLEIJ wrote:
> I understand the problem such that the scheduler cannot determine whether
> a certain process should be allowed to schedule or not.
> 
> It strikes me that the intuitive solution is to group all un-trusted 
> processes/threads/tasks that need to be shut off even if they are
> scheduling into a control group and let the idle code ignore the
> processes in this group.
> 
> Or is there something too naïve about this?

It gets most of the way there (and I spent a while playing with it), but 
the problem is that not all wakeup events get proxied through the 
trusted userspace runtime. Network packets are the easiest example - a 
packet may wake the system, but if the process it's delivered to is 
frozen then obviously things get trickier. It's also racy, in that if 
you're currently awake and receive a packet that would otherwise have 
woken the system you may go to sleep between the packet being received 
and bubbling up through the kernel to get to userspace.

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

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

[Linus WALLEIJ]

[Matthew]
> On Mon, May 17, 2010 at 10:53:36PM +0200, Linus WALLEIJ wrote:
> > I understand the problem such that the scheduler cannot determine whether
> > a certain process should be allowed to schedule or not.
> >
> > It strikes me that the intuitive solution is to group all un-trusted
> > processes/threads/tasks that need to be shut off even if they are
> > scheduling into a control group and let the idle code ignore the
> > processes in this group.
> >
> > Or is there something too naïve about this?
> 
> It gets most of the way there (and I spent a while playing with it), but
> the problem is that not all wakeup events get proxied through the
> trusted userspace runtime. Network packets are the easiest example - a
> packet may wake the system, but if the process it's delivered to is
> frozen then obviously things get trickier. It's also racy, in that if
> you're currently awake and receive a packet that would otherwise have
> woken the system you may go to sleep between the packet being received
> and bubbling up through the kernel to get to userspace.

Maybe I'm misunderstanding something basic here, but when you say frozen,
are you referring to freezer control groups
Documentation/cgroups/freezer-subsystem.txt?

I was more thinking about something new, that isn't freezing anything.
The only purpose would be to group the stuff that CPUidle can ignore,
and let CPUidle ignore it, so that the system can still be idled.

Yours,
Linus Walleij

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

[Matthew Garrett]

On Mon, May 17, 2010 at 11:16:52PM +0200, Linus WALLEIJ wrote:
> Maybe I'm misunderstanding something basic here, but when you say frozen,
> are you referring to freezer control groups
> Documentation/cgroups/freezer-subsystem.txt?
> 
> I was more thinking about something new, that isn't freezing anything.
> The only purpose would be to group the stuff that CPUidle can ignore,
> and let CPUidle ignore it, so that the system can still be idled.

So they'd be on the runqeue but wouldn't factor into cpuidle's 
calculations of when the next wakeup should be? Ok. I think that still 
leaves you with the same problem - you're not scheduling that task, so 
how do you know to execute it when a network packet is received? I think 
you also still have the race condition.

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

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Mon, May 17, 2010 at 09:27:47PM +0200, Vitaly Wool wrote:
>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>
> Run this (or equivalent code) on an N900 and on an Android. Measure the 
> screen-off power draw on both.
>
> int main() {
> 	int i;
> 	while (1)
> 		i++;
> 	return 0;
> }

This kind of rogue app will also kill my CPU performance.  For rogue
CPU-hog apps, we use _tools_ to find and fix this kind of problem:
top, renice, kill, etc. that use features of the scheduler to find
and/or solve the problem.

For rogue apps that affect PM, what is being proposed is to bypass the
root causes (timers, scheduler, activity, etc.) and just freeze the
apps.

Rogue CPU-hog apps are generally not tolerated.  The problems are
found using tools and fixed (or removed.)  Why should we do any
different for rogue power-hog apps?

Maybe the tools aren't as good for finding power-sucking apps.
Then we should be focusing on the _tools_ instead of masking the
problem.

Kevin

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

[Daniel Walker]

On Mon, 2010-05-17 at 22:24 +0100, Matthew Garrett wrote:
> On Mon, May 17, 2010 at 11:16:52PM +0200, Linus WALLEIJ wrote:
> > Maybe I'm misunderstanding something basic here, but when you say frozen,
> > are you referring to freezer control groups
> > Documentation/cgroups/freezer-subsystem.txt?
> > 
> > I was more thinking about something new, that isn't freezing anything.
> > The only purpose would be to group the stuff that CPUidle can ignore,
> > and let CPUidle ignore it, so that the system can still be idled.
> 
> So they'd be on the runqeue but wouldn't factor into cpuidle's 
> calculations of when the next wakeup should be? Ok. I think that still 
> leaves you with the same problem - you're not scheduling that task, so 
> how do you know to execute it when a network packet is received? I think 
> you also still have the race condition.

Couldn't you special case the network packet situation ? Like the idle
loop could take into account that there are packets flowing through the
networking stack that may need to get handled.

Daniel

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

[Matthew Garrett]

On Mon, May 17, 2010 at 02:27:52PM -0700, Kevin Hilman wrote:
> Matthew Garrett <mjg@redhat.com> writes:
> > Run this (or equivalent code) on an N900 and on an Android. Measure the 
> > screen-off power draw on both.
> >
> > int main() {
> > 	int i;
> > 	while (1)
> > 		i++;
> > 	return 0;
> > }
> 
> This kind of rogue app will also kill my CPU performance.  For rogue
> CPU-hog apps, we use _tools_ to find and fix this kind of problem:
> top, renice, kill, etc. that use features of the scheduler to find
> and/or solve the problem.

If my phone is able to avoid losing almost all of its standby time 
without me having to care about whether my bouncing cow game was written 
by a complete fool or not, that means that my phone is *better* than one 
where I have to care. Would the world be better if said fool could be 
sent to reeducation camps before being allowed to write any more 
software? Probably, but sadly that doesn't seem to be something we can 
implement through code. I'd love it if we could assume that all software 
is going to be perfect, but in the absence of that ideal world there's a 
strong incentive to develop technology that does its best to cope with 
adverse situations.

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

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

[Matthew Garrett]

On Mon, May 17, 2010 at 02:29:24PM -0700, Daniel Walker wrote:
> On Mon, 2010-05-17 at 22:24 +0100, Matthew Garrett wrote:
> > > I was more thinking about something new, that isn't freezing anything.
> > > The only purpose would be to group the stuff that CPUidle can ignore,
> > > and let CPUidle ignore it, so that the system can still be idled.
> > 
> > So they'd be on the runqeue but wouldn't factor into cpuidle's 
> > calculations of when the next wakeup should be? Ok. I think that still 
> > leaves you with the same problem - you're not scheduling that task, so 
> > how do you know to execute it when a network packet is received? I think 
> > you also still have the race condition.
> 
> Couldn't you special case the network packet situation ? Like the idle
> loop could take into account that there are packets flowing through the
> networking stack that may need to get handled.

And once you've done that for every wakeup source you have something 
that looks pretty much like suspend blockers.

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

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

[Brian Swetland]

On Mon, May 17, 2010 at 2:27 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> This kind of rogue app will also kill my CPU performance.  For rogue
> CPU-hog apps, we use _tools_ to find and fix this kind of problem:
> top, renice, kill, etc. that use features of the scheduler to find
> and/or solve the problem.
>
> For rogue apps that affect PM, what is being proposed is to bypass the
> root causes (timers, scheduler, activity, etc.) and just freeze the
> apps.
>
> Rogue CPU-hog apps are generally not tolerated.  The problems are
> found using tools and fixed (or removed.)  Why should we do any
> different for rogue power-hog apps?
>
> Maybe the tools aren't as good for finding power-sucking apps.
> Then we should be focusing on the _tools_ instead of masking the
> problem.

Mass market consumer devices that allow arbitrary app installation are
a fun challenge because many (most?) users are not aware of the low
level details here or why one app is bad and another is good.  They
often don't even know which app of N they installed is causing their
problems.  We're providing this information as we can to help users
understand which apps are using cpu or preventing suspend, via the
battery usage UI.  We try to provide even more detailed information to
developers so they can test and adjust for poor cpu/power usage.

We are also doing our best to behave well even in the face of poorly
written apps.

I think you need to do both -- provide tools and education, but also
make the best of things.  If I can make a device with a poorly written
app make it over a day of standby instead of 4-8 hours of standby,
that has immediate benefit to the user, for example.

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

[Daniel Walker]

On Mon, 2010-05-17 at 22:35 +0100, Matthew Garrett wrote:
> On Mon, May 17, 2010 at 02:29:24PM -0700, Daniel Walker wrote:
> > On Mon, 2010-05-17 at 22:24 +0100, Matthew Garrett wrote:
> > > > I was more thinking about something new, that isn't freezing anything.
> > > > The only purpose would be to group the stuff that CPUidle can ignore,
> > > > and let CPUidle ignore it, so that the system can still be idled.
> > > 
> > > So they'd be on the runqeue but wouldn't factor into cpuidle's 
> > > calculations of when the next wakeup should be? Ok. I think that still 
> > > leaves you with the same problem - you're not scheduling that task, so 
> > > how do you know to execute it when a network packet is received? I think 
> > > you also still have the race condition.
> > 
> > Couldn't you special case the network packet situation ? Like the idle
> > loop could take into account that there are packets flowing through the
> > networking stack that may need to get handled.
> 
> And once you've done that for every wakeup source you have something 
> that looks pretty much like suspend blockers.

Well, maybe (this is theoretical after all), but it's within the
confines of our current PM model .. You basically centralize all the
decision making into the kernel, and into idle. that seems to me more
powerful than suspend blockers since they interleave parts with
userspace.

Daniel

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Mike Chan <mike@android.com> writes:

> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.

Agreed.  I was reluctant to even make the comparison for all those
reasons, but with the lack of real numbers, it was all I had to show a
very rough subjective guess, and at least show that with and without
opportunistic suspend, you're in the same ballpark.

>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.
>
> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.

Excellent.  Thanks for some real numbers.

(btw, sure would be nice to have the basic droid board files in mainline. ;)

> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

[at risk of stating the obvious] Since both approaches hit the same
power states, if the system was truly idle, you'd expect the numbers
to be the same, right?  So what the difference shows is that the
system is not fully idle, IOW userspace and/or kernel wakeups are
cusing the difference.

It might also be instructive to see these numbers with a "noop"
userspace, like just booting into busybox init=/bin/sh (or the android
equivalent.)  That would show how much of that difference is due to
kernel idleness (or lack thereof.)

Even still, to me this all boils down to the lack of definition of the
problem and clear description of the solution

The fundamental problem is one of idleness.  What we want is the
system to be idle in order to hit the lowest power states.  We can't
get there because the system is not truly idle.

So, there are basically two solutions:

1) find and fix the problem spots so we can be idle more often
2) add a new definition of idle so we can be idle more often

Opporuntistic suspend takes the second approach where the new
definition of idle is "no suspend blockers held."

Of course, I clearly prefer the former, but it's also becoming clear
that since I'm the only one still whining about it, I must be too much
of an idealist to keep hoping for it.

Kevin

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

[Kevin Hilman]

Mike Chan <mike@android.com> writes:

> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.

Agreed.  I was reluctant to even make the comparison for all those
reasons, but with the lack of real numbers, it was all I had to show a
very rough subjective guess, and at least show that with and without
opportunistic suspend, you're in the same ballpark.

>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.
>
> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.

Excellent.  Thanks for some real numbers.

(btw, sure would be nice to have the basic droid board files in mainline. ;)

> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

[at risk of stating the obvious] Since both approaches hit the same
power states, if the system was truly idle, you'd expect the numbers
to be the same, right?  So what the difference shows is that the
system is not fully idle, IOW userspace and/or kernel wakeups are
cusing the difference.

It might also be instructive to see these numbers with a "noop"
userspace, like just booting into busybox init=/bin/sh (or the android
equivalent.)  That would show how much of that difference is due to
kernel idleness (or lack thereof.)

Even still, to me this all boils down to the lack of definition of the
problem and clear description of the solution

The fundamental problem is one of idleness.  What we want is the
system to be idle in order to hit the lowest power states.  We can't
get there because the system is not truly idle.

So, there are basically two solutions:

1) find and fix the problem spots so we can be idle more often
2) add a new definition of idle so we can be idle more often

Opporuntistic suspend takes the second approach where the new
definition of idle is "no suspend blockers held."

Of course, I clearly prefer the former, but it's also becoming clear
that since I'm the only one still whining about it, I must be too much
of an idealist to keep hoping for it.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman]

Mike Chan <mike@android.com> writes:

> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>>> is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> What's probably more interesting in terms of rough comparisons is
>>> comparing similar devices with and without opportunistic suspend.  The
>>> Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
>>> OMAP3) and roughly the same kernel (2.6.2[89], although both are
>>> heavily patched from mainline.)
>>>
>>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>>
>>> I don't know of any more objective comparison of the two, but as a
>>> user of both devices I can say that the active usage is basically the
>>> same (around a day) and the idle use is similar as well, even though
>>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
>>> own usage suggests the n900 is a bit better in idle time, but I have
>>> not done any measuring or objective tests.  I'm guessing the
>>> difference is probably because the Droid does not use the deepest
>>> off-mode power states either in idle or suspend (IIRC) where the n900
>>> does.  I suspect that if both were using off-mode and had the same
>>> battery, these differences would go away.
>>>
>
> Although both are OMAP3430 and run 2.6.29 you cannot compare the N900
> and Droid's perceived user battery life to one another to evaluate
> opportunistic suspend. There are many factors uncounted for such as:
> network reception, screen brightness (and size), button back-light,
> keyboard back-light, modem stack (CDMA vs UMTS). Also the difference
> in uerspace.

Agreed.  I was reluctant to even make the comparison for all those
reasons, but with the lack of real numbers, it was all I had to show a
very rough subjective guess, and at least show that with and without
opportunistic suspend, you're in the same ballpark.

>>> While this is not really a scientific comparison, it at least gives a
>>> rough idea.  If using opportunistic suspend was adding noticably
>>> better battery life, I think this would be a different discussion.
>>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>>
>
> Opportunistic suspend is an extension to the current suspend model,
> not a replacement dynamic / run-time PM. If you can replace good old
> suspend then this would be a different story.
>
> As you mention, Droid uses opportunistic suspend + dynamic pm +
> cpuidle + freq. So I decided to do some measurements on a Droid using
> our 2.9.32 kernel
> (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a
> little better apples to apples comparison.

Excellent.  Thanks for some real numbers.

(btw, sure would be nice to have the basic droid board files in mainline. ;)

> Droid (idle system, airplane mode, screen off, 3 min interval):
> measured average current
> - with opportunity suspend: 3.19mA
> - without opportunistic suspend: 3.5mA
>
> Stock userspace build, all I did was replace the kernel. We are
> hitting retention on idle as well as suspend for omap (instead of full
> off-mode).

[at risk of stating the obvious] Since both approaches hit the same
power states, if the system was truly idle, you'd expect the numbers
to be the same, right?  So what the difference shows is that the
system is not fully idle, IOW userspace and/or kernel wakeups are
cusing the difference.

It might also be instructive to see these numbers with a "noop"
userspace, like just booting into busybox init=/bin/sh (or the android
equivalent.)  That would show how much of that difference is due to
kernel idleness (or lack thereof.)

Even still, to me this all boils down to the lack of definition of the
problem and clear description of the solution

The fundamental problem is one of idleness.  What we want is the
system to be idle in order to hit the lowest power states.  We can't
get there because the system is not truly idle.

So, there are basically two solutions:

1) find and fix the problem spots so we can be idle more often
2) add a new definition of idle so we can be idle more often

Opporuntistic suspend takes the second approach where the new
definition of idle is "no suspend blockers held."

Of course, I clearly prefer the former, but it's also becoming clear
that since I'm the only one still whining about it, I must be too much
of an idealist to keep hoping for it.

Kevin



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

Matthew Garrett <mjg@redhat.com> writes:

> On Mon, May 17, 2010 at 02:27:52PM -0700, Kevin Hilman wrote:
>> Matthew Garrett <mjg@redhat.com> writes:
>> > Run this (or equivalent code) on an N900 and on an Android. Measure the 
>> > screen-off power draw on both.
>> >
>> > int main() {
>> > 	int i;
>> > 	while (1)
>> > 		i++;
>> > 	return 0;
>> > }
>> 
>> This kind of rogue app will also kill my CPU performance.  For rogue
>> CPU-hog apps, we use _tools_ to find and fix this kind of problem:
>> top, renice, kill, etc. that use features of the scheduler to find
>> and/or solve the problem.
>
> If my phone is able to avoid losing almost all of its standby time 
> without me having to care about whether my bouncing cow game was written 
> by a complete fool or not, that means that my phone is *better* than one 
> where I have to care. 

Someday I hope to see this bouncing cow app I keep hearing about.  I
must be pretty spectacular since can't help talking about it.  ;)

> Would the world be better if said fool could be 
> sent to reeducation camps before being allowed to write any more 
> software? Probably, but sadly that doesn't seem to be something we can 
> implement through code. I'd love it if we could assume that all software 
> is going to be perfect, but in the absence of that ideal world there's a 
> strong incentive to develop technology that does its best to cope with 
> adverse situations.

I completely agree.  

The only thing being debated is the implementation of the coping
mechanism.

In particular, why the coping mechanism for PM "badness" has to be a
large sledgehammer where other badness (CPU, IO, etc.) has been dealt
with using infrastructure like timers, scheduling, throttling, etc.

My shrink would say that the sledgehammer approach to badness might
work for the short term, but eventually that badness is going to seep
out in other, unpredictable places.

My shrink would also probably tell me that since I'm seem to be the
last one left who seems to care, it's probably time to throw in the
towel.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland]

On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> The fundamental problem is one of idleness.  What we want is the
> system to be idle in order to hit the lowest power states.  We can't
> get there because the system is not truly idle.
>
> So, there are basically two solutions:
>
> 1) find and fix the problem spots so we can be idle more often
> 2) add a new definition of idle so we can be idle more often
>
> Opporuntistic suspend takes the second approach where the new
> definition of idle is "no suspend blockers held."
>
> Of course, I clearly prefer the former, but it's also becoming clear
> that since I'm the only one still whining about it, I must be too much
> of an idealist to keep hoping for it.

I'd love to see the former work, but it is not something that I think
is going to be fixed rapidly.  It potentially involves many different
subsystems, and still requires some need for managing arbitrary
userspace agents which may have non-ideal behaviors (if we're going to
solve the problem for general purpose devices that can run arbitrary
user-installed software).  Incremental improvements are great though
(for example, that we can now be in lowest power idle for periods
greater than 2 seconds due to the change in .32).

Even when operating in opportunistic suspend, it is still advantageous
for idle to be as idle as possible and we should keep working toward
that goal.  If we get to the point where the power difference between
suspend-in-idle and opportunistic suspend is zero, then we no longer
need the latter.

I don't think anybody on the Google/Android side is arguing that we
*shouldn't* pursue dynamic pm and overall making idle more idle more
of the time.  We're just saying that here and now we are not at the
ideal and opportunistic suspend gains us real power savings and is
useful.

Brian

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

[Brian Swetland]

On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> The fundamental problem is one of idleness.  What we want is the
> system to be idle in order to hit the lowest power states.  We can't
> get there because the system is not truly idle.
>
> So, there are basically two solutions:
>
> 1) find and fix the problem spots so we can be idle more often
> 2) add a new definition of idle so we can be idle more often
>
> Opporuntistic suspend takes the second approach where the new
> definition of idle is "no suspend blockers held."
>
> Of course, I clearly prefer the former, but it's also becoming clear
> that since I'm the only one still whining about it, I must be too much
> of an idealist to keep hoping for it.

I'd love to see the former work, but it is not something that I think
is going to be fixed rapidly.  It potentially involves many different
subsystems, and still requires some need for managing arbitrary
userspace agents which may have non-ideal behaviors (if we're going to
solve the problem for general purpose devices that can run arbitrary
user-installed software).  Incremental improvements are great though
(for example, that we can now be in lowest power idle for periods
greater than 2 seconds due to the change in .32).

Even when operating in opportunistic suspend, it is still advantageous
for idle to be as idle as possible and we should keep working toward
that goal.  If we get to the point where the power difference between
suspend-in-idle and opportunistic suspend is zero, then we no longer
need the latter.

I don't think anybody on the Google/Android side is arguing that we
*shouldn't* pursue dynamic pm and overall making idle more idle more
of the time.  We're just saying that here and now we are not at the
ideal and opportunistic suspend gains us real power savings and is
useful.

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

[Paul Walmsley]

Hello Rafael,

On Sat, 15 May 2010, Rafael J. Wysocki wrote:

> And really, the only semi-technical argument against the opportunistic suspend
> feature I've seen so far in this thread is that it _may_ _be_ possible to
> achieve the same goal in a different way.  If I don't see anything more serious
> than that, I will take the patchset and push it to Linus (patches [1-6/8] from
> version 7 to be precise, as soon as the changelogs are improved as
> requested).

The Android opportunistic suspend series still has problems, even if 
opportunistic suspend mode is not enabled.  These problems can be fixed, 
but it's too late to fix them for this merge window.  There shouldn't be a 
rush to merge these patches, given the current amount of discussion.

Details:

A. The series still has problems, even if the opportunistic suspend
   mode is not enabled:

   1. Many suspend_block() calls will need to be added throughout the
      kernel and drivers[1], beyond just those in the current patch 
      series.  Android systems will not work without  these calls.  
      The primary stated goal of adding suspend-block calls is not to
      add a new feature, but to restore an approximation of the
      original, expected behavior of the kernel timer and scheduler
      subsystems: to keep running as long as there is work to be done.
      This approach -- requiring patching of the kernel to restore
      expected behavior -- is inferior to an approach that preserves
      the timer and scheduler subsystems' behavior and only patches
      areas where the kernel doesn't have enough information to make
      the right decision[2].

   2. suspend_block() calls will be difficult for driver and subsystem
      maintainers to test.  This is because the calls contain hidden
      dependencies to specific Android userspace setups and unrelated
      kernel code[3].

B. These problems can be fixed:

   1. Patch 1's opportunistic suspend governor can be converted into
      an "opportunistic system low power governor."  In other words,
      when the governor decides to put the system into a low-power
      state, the way to do it should be up to the architecture, system
      integrator, or user -- not only "queue_work(pm_wq,
      &suspend_work);"
   
   2. The opportunistic system low power governor can then be extended
      to handle multiple system low-power states ("S-states" in ACPI
      terms)[4], rather than just one low-power state; similar to the
      way that CPUIdle selects C-states.
   
   3. The system low power governor can then be entered before the
      last active CPU in the system enters WFI/HLT (i.e., immediately
      before CPUIdle calls state->enter() [5]).  At this point, the
      governor would respect timers and the scheduler, and most
      suspend-block calls can be removed from the kernel.

   4. The process-freezing behavior of the opportunistic suspend
      patches can be implemented by improving the Linux timer and
      scheduler subsystems.  If freezer cgroups won't do, then based
      on a quick glance last week, here might be some reasonable
      approaches for emulating the Android behavior:

      A. To prevent untrusted process timers from waking the system,
         the processes can be run in a cgroup that calls
         del_timer_sync() on all process timers upon receipt of some
         trigger.  When the system returns from the system low-power
         state and some trigger event happens, add_timer() can be
         called to add all the cgroup's timers back.

      B. To prevent untrusted processes from hogging CPUs, the
         processes can be run in a cgroup that puts all threads in
         TASK_RUNNING processes into TASK_INTERRUPTIBLE state and
         calls schedule() [6], upon receipt of some trigger.  This
         should allow processes to be awakened by an external system
         event, e.g., network packet received.  When the system
         returns from the system low-power state and some trigger
         event happens, those process threads can be placed back into
         TASK_RUNNING state and rescheduled.

      The trigger events could be as simple as writing '1' or '0' into
      some cgroup or sysfs control file.

   5. At this point there would likely be a few remaining
      suspend-block users that use suspend_block() as an ersatz PM
      constraint API.  These should be replaced by a declarative PM
      constraint API a la [7] or [8].  Architectures and system
      integrators must be allowed to control how these PM constraints
      are implemented, because different chipsets, boards, and
      use-cases may have different power management feature
      implementations.

   Fixing the above issues should remove any need to add a
   suspend-block API.  It should handle the process-freezing use case.
   Android can still enter full system suspend in their system idle
   governor, but it should no longer need to.  Since this approach
   will honor "trusted" timers and processes, it won't break code that
   relies on longstanding kernel scheduling assumptions.

C. There shouldn't be a rush to merge the existing Android series:

   1. The lack of suspend-block support should not prevent existing
      drivers from being upstreamed without suspend-block calls.
      Non-Android users will be using the drivers without
      suspend-blocks, so the drivers will need to work without
      suspend-blocks anyway.  Until a fixed version of the series is
      submitted, Android can just carry the suspend-block patches in
      their own tree: the suspend-block patch rebase load from one
      Linux kernel release to the next should be light.  Many of the
      code sites where suspend-block calls are currently present in
      Android's MSM kernel[9] are unlikely to change, so git should be
      able to merge those automatically.

   2. Once these patches are merged, it will be difficult to remove
      the suspend-block approach from the kernel[10].  It touches a lot of
      kernel code.  And the power management constraint that it
      specifies is so general ("block system suspend"), that, for the
      subset of suspend_block() use-cases that actually implement a
      driver PM constraint, it will be difficult to figure out what
      these constraints were originally intended to be.

   3. There is no imminent danger if these patches are not merged.
      These are not security patches, or patches that fix some
      existing code that could damage hardware.  There is no liability
      motivation to fast-track these patches, particularly given the
      current high level of discussion.

Some of the features that these opportunistic suspend patches implement 
are desirable, such as process freezing and a system low power governor 
independent from CPUIdle.  However, there are significant problems with 
the way that these opportunistic suspend patches are designed, since they 
break existing kernel semantics and then touch lots of other code to work 
around the breakage.

The right approach should be to implement these features in a way that 
does not require patching all over the kernel, does not break existing 
timer and scheduler behavior, and will not impact bottom-up power 
management approaches.


regards,

- Paul
     

1. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:27:56 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18658

2. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/omap-pm.h;h=3ee41d7114929d771cadbb9f02191fd16c5b5abe;hb=ba2e1c5f25a99dec3873745031ad23ce3fd79bff

3. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:27:56 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18658

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

5. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/cpuidle/cpuidle.c;h=12fdd3987a36c2b09ab65b9d598f276e51fbf5b7;hb=ba2e1c5f25a99dec3873745031ad23ce3fd79bff#l88

6. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/signal.c;h=dbd7fe073c558dbc57080e7d0d9344b2cf47b2dd;hb=ba2e1c5f25a99dec3873745031ad23ce3fd79bff#l2696

7. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/omap-pm.h;h=3ee41d7114929d771cadbb9f02191fd16c5b5abe;hb=ba2e1c5f25a99dec3873745031ad23ce3fd79bff

8. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/pm_qos_params.c;h=3db49b9ca374ded32bf224f266e904a8006e61a8;hb=ba2e1c5f25a99dec3873745031ad23ce3fd79bff

9. Paul Walmsley E-mail to the linux-pm mailing list, dated Fri, 14
   May 2010 00:13:50 -0600:
   http://permalink.gmane.org/gmane.linux.power-management.general/18657

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

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

[Matthew Garrett]

On Mon, May 17, 2010 at 07:39:44PM -0600, Paul Walmsley wrote:

>       A. To prevent untrusted process timers from waking the system,
>          the processes can be run in a cgroup that calls
>          del_timer_sync() on all process timers upon receipt of some
>          trigger.  When the system returns from the system low-power
>          state and some trigger event happens, add_timer() can be
>          called to add all the cgroup's timers back.

This doesn't work, for the reasons previously discussed.

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

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

[Paul Walmsley]

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

Hello Arve,

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

> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
> >
> >> No, suspend blockers are mostly used to ensure wakeup events are not
> >> ignored, and to ensure tasks triggered by these wakeup events
> >> complete.
> >
> > Standard Linux systems don't need these,
> 
> If you don't want to lose wakeup events they do.  Standard Linux systems 
> support suspend, but since they usually don't have a lot of wakeup 
> events you don't run into a lot of problems.

Sorry, I don't follow.  What causes wakeup events to be lost?  Is it the 
current opportunistic suspend governor?  On OMAP Linux systems, as far as 
I know, we don't lose any wakeup events.

> > because the scheduler just keeps the system running as long as there 
> > is work to be done.
> 
> That is only true if you never use suspend.

If, instead of the current Android opportunistic suspend governor, the 
system entered suspend from pm_idle(), wouldn't that keep the system 
running as long as there is work to done?

As far as I can see, it's the current Android opportunistic suspend 
governor design in patch 1 that causes the system to enter suspend even 
when there is work to be done, since it will try to suspend even when the 
system is out of the idle loop.


- Paul

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

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

[tytso]

On Mon, May 17, 2010 at 02:36:26PM -0700, Brian Swetland wrote:
> 
> Mass market consumer devices that allow arbitrary app installation are
> a fun challenge because many (most?) users are not aware of the low
> level details here or why one app is bad and another is good.  They
> often don't even know which app of N they installed is causing their
> problems.

... and this was definitely a problem with Maemo devices that I played
with (N770, N800, et. al.).  You'd install 3 or 4 applications, then
start running without the power adapter permanently attached, and hey
surprise!  The battery would be drained very quickly even though the
device was "idle".  Figuring out which application was at fault was
basically done via brute force, which was not fun....

					- Ted

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

[Arve Hjønnevåg]

On Mon, May 17, 2010 at 7:26 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Arve,
>
> On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>
>> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> No, suspend blockers are mostly used to ensure wakeup events are not
>> >> ignored, and to ensure tasks triggered by these wakeup events
>> >> complete.
>> >
>> > Standard Linux systems don't need these,
>>
>> If you don't want to lose wakeup events they do.  Standard Linux systems
>> support suspend, but since they usually don't have a lot of wakeup
>> events you don't run into a lot of problems.
>
> Sorry, I don't follow.  What causes wakeup events to be lost?  Is it the
> current opportunistic suspend governor?  On OMAP Linux systems, as far as
> I know, we don't lose any wakeup events.
>
Have you used suspend?

>> > because the scheduler just keeps the system running as long as there
>> > is work to be done.
>>
>> That is only true if you never use suspend.
>
> If, instead of the current Android opportunistic suspend governor, the
> system entered suspend from pm_idle(), wouldn't that keep the system
> running as long as there is work to done?
>
How do you know if the work being done while suspending is work that
is needed to suspend or work that should abort suspend? When should
the system wake up?

> As far as I can see, it's the current Android opportunistic suspend
> governor design in patch 1 that causes the system to enter suspend even
> when there is work to be done, since it will try to suspend even when the
> system is out of the idle loop.
>

It does not matter how you enter suspend. Without opportunistic
suspend, once you tell the kernel that you want to suspend, you cannot
abort. If a wakeup event occurs at this point, it will probably not be
processed until the system wakes up for another wakeup event.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
>Right, because Firmware writers are from the rugged unresponsive uplands
>of planet
>ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
>Software writers are from the emollient responsive groves of planet
>harmony.  Obviously what would work for one wouldn't work for the other.
>
>As a software writer, I fully buy into that world view.  The trouble is
>that when I go to dinner with hardware people, they seem to be awfully
>nice chaps ... almost exactly like me, in fact ...

what does this add to suspend_blockers discussion ?

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
>Right, because Firmware writers are from the rugged unresponsive uplands
>of planet
>ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
>Software writers are from the emollient responsive groves of planet
>harmony.  Obviously what would work for one wouldn't work for the other.
>
>As a software writer, I fully buy into that world view.  The trouble is
>that when I go to dinner with hardware people, they seem to be awfully
>nice chaps ... almost exactly like me, in fact ...

what does this add to suspend_blockers discussion ?

-- 
balbi

DefectiveByDesign.org

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

[Henrik Rydberg]

Arve Hjønnevåg wrote:
> It does not matter how you enter suspend. Without opportunistic
> suspend, once you tell the kernel that you want to suspend, you cannot
> abort. If a wakeup event occurs at this point, it will probably not be
> processed until the system wakes up for another wakeup event.
> 

Since it seems to be at the very core of the argument, how long time does it
take to suspend your system? Is it something that could be improved upon?

Henrik

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[James Bottomley]

On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
> >Right, because Firmware writers are from the rugged unresponsive uplands
> >of planet
> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
> >Software writers are from the emollient responsive groves of planet
> >harmony.  Obviously what would work for one wouldn't work for the other.
> >
> >As a software writer, I fully buy into that world view.  The trouble is
> >that when I go to dinner with hardware people, they seem to be awfully
> >nice chaps ... almost exactly like me, in fact ...
> 
> what does this add to suspend_blockers discussion ?

Sorry I was evidently being too subtle.

The point is that if, as you acknowledge, that you can't train firmware
engineers to be responsive, there's no reason to think you can train
software engineers in the same quality ... they're very similar people.

The corollary is that real world systems have to operate in the face of
misbehaving hardware *and* software.

James

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

[James Bottomley]

On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
> >Right, because Firmware writers are from the rugged unresponsive uplands
> >of planet
> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
> >Software writers are from the emollient responsive groves of planet
> >harmony.  Obviously what would work for one wouldn't work for the other.
> >
> >As a software writer, I fully buy into that world view.  The trouble is
> >that when I go to dinner with hardware people, they seem to be awfully
> >nice chaps ... almost exactly like me, in fact ...
> 
> what does this add to suspend_blockers discussion ?

Sorry I was evidently being too subtle.

The point is that if, as you acknowledge, that you can't train firmware
engineers to be responsive, there's no reason to think you can train
software engineers in the same quality ... they're very similar people.

The corollary is that real world systems have to operate in the face of
misbehaving hardware *and* software.

James

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

[Rafael J. Wysocki]

On Tuesday 18 May 2010, Henrik Rydberg wrote:
> Arve Hjønnevåg wrote:
> > It does not matter how you enter suspend. Without opportunistic
> > suspend, once you tell the kernel that you want to suspend, you cannot
> > abort. If a wakeup event occurs at this point, it will probably not be
> > processed until the system wakes up for another wakeup event.
> > 
> 
> Since it seems to be at the very core of the argument, how long time does it
> take to suspend your system? Is it something that could be improved upon?

It's not a matter of time.  It's a matter of lost keystrokes and such.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote:
>On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
>> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
>> >Right, because Firmware writers are from the rugged unresponsive uplands
>> >of planet
>> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
>> >Software writers are from the emollient responsive groves of planet
>> >harmony.  Obviously what would work for one wouldn't work for the other.
>> >
>> >As a software writer, I fully buy into that world view.  The trouble is
>> >that when I go to dinner with hardware people, they seem to be awfully
>> >nice chaps ... almost exactly like me, in fact ...
>>
>> what does this add to suspend_blockers discussion ?
>
>Sorry I was evidently being too subtle.
>
>The point is that if, as you acknowledge, that you can't train firmware
>engineers to be responsive, there's no reason to think you can train
>software engineers in the same quality ... they're very similar people.

I wouldn't say it's up to the engineer himself, it's more related to how 
the company that person works for deal with such things.

>The corollary is that real world systems have to operate in the face of
>misbehaving hardware *and* software.

I still think the kernel shouldn't deal with broken applications and we 
shouldn't try to fix them in kernel space. We can, of course, try to 
find them and have all sorts of bells and whistles shouting 'process 
%s is preventing CPU from sleeping for %llu nanoseconds' or something 
like that.

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote:
>On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
>> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
>> >Right, because Firmware writers are from the rugged unresponsive uplands
>> >of planet
>> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
>> >Software writers are from the emollient responsive groves of planet
>> >harmony.  Obviously what would work for one wouldn't work for the other.
>> >
>> >As a software writer, I fully buy into that world view.  The trouble is
>> >that when I go to dinner with hardware people, they seem to be awfully
>> >nice chaps ... almost exactly like me, in fact ...
>>
>> what does this add to suspend_blockers discussion ?
>
>Sorry I was evidently being too subtle.
>
>The point is that if, as you acknowledge, that you can't train firmware
>engineers to be responsive, there's no reason to think you can train
>software engineers in the same quality ... they're very similar people.

I wouldn't say it's up to the engineer himself, it's more related to how 
the company that person works for deal with such things.

>The corollary is that real world systems have to operate in the face of
>misbehaving hardware *and* software.

I still think the kernel shouldn't deal with broken applications and we 
shouldn't try to fix them in kernel space. We can, of course, try to 
find them and have all sorts of bells and whistles shouting 'process 
%s is preventing CPU from sleeping for %llu nanoseconds' or something 
like that.

-- 
balbi

DefectiveByDesign.org

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

[Paul Walmsley]

Hi Matthew,

On Tue, 18 May 2010, Matthew Garrett wrote:

> On Mon, May 17, 2010 at 07:39:44PM -0600, Paul Walmsley wrote:
> 
> >       A. To prevent untrusted process timers from waking the system,
> >          the processes can be run in a cgroup that calls
> >          del_timer_sync() on all process timers upon receipt of some
> >          trigger.  When the system returns from the system low-power
> >          state and some trigger event happens, add_timer() can be
> >          called to add all the cgroup's timers back.
> 
> This doesn't work, for the reasons previously discussed.

Could you please elaborate, or provide a link to an E-mail in the archives 
that would explain why?

thanks,

- Paul

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

[Matthew Garrett]

On Wed, May 19, 2010 at 10:17:01AM -0600, Paul Walmsley wrote:

> Could you please elaborate, or provide a link to an E-mail in the archives 
> that would explain why?

What would otherwise be a wakeup event may be delivered between you 
deciding to stop tasks and you actually stopping tasks. How do you know 
to restart tasks at that point?

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Felipe Balbi wrote:
> On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote:
> >On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
> >> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
> >> >Right, because Firmware writers are from the rugged unresponsive uplands
> >> >of planet
> >> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
> >> >Software writers are from the emollient responsive groves of planet
> >> >harmony.  Obviously what would work for one wouldn't work for the other.
> >> >
> >> >As a software writer, I fully buy into that world view.  The trouble is
> >> >that when I go to dinner with hardware people, they seem to be awfully
> >> >nice chaps ... almost exactly like me, in fact ...
> >>
> >> what does this add to suspend_blockers discussion ?
> >
> >Sorry I was evidently being too subtle.
> >
> >The point is that if, as you acknowledge, that you can't train firmware
> >engineers to be responsive, there's no reason to think you can train
> >software engineers in the same quality ... they're very similar people.
> 
> I wouldn't say it's up to the engineer himself, it's more related to how 
> the company that person works for deal with such things.
> 
> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
> 
> I still think the kernel shouldn't deal with broken applications and we 
> shouldn't try to fix them in kernel space. We can, of course, try to 
> find them and have all sorts of bells and whistles shouting 'process 
> %s is preventing CPU from sleeping for %llu nanoseconds' or something 
> like that.

Please note that this approach is not too practical for vendors who ship
systems like cell phones to the general public.

Rafael

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

[Rafael J. Wysocki]

On Wednesday 19 May 2010, Felipe Balbi wrote:
> On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote:
> >On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
> >> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
> >> >Right, because Firmware writers are from the rugged unresponsive uplands
> >> >of planet
> >> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
> >> >Software writers are from the emollient responsive groves of planet
> >> >harmony.  Obviously what would work for one wouldn't work for the other.
> >> >
> >> >As a software writer, I fully buy into that world view.  The trouble is
> >> >that when I go to dinner with hardware people, they seem to be awfully
> >> >nice chaps ... almost exactly like me, in fact ...
> >>
> >> what does this add to suspend_blockers discussion ?
> >
> >Sorry I was evidently being too subtle.
> >
> >The point is that if, as you acknowledge, that you can't train firmware
> >engineers to be responsive, there's no reason to think you can train
> >software engineers in the same quality ... they're very similar people.
> 
> I wouldn't say it's up to the engineer himself, it's more related to how 
> the company that person works for deal with such things.
> 
> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
> 
> I still think the kernel shouldn't deal with broken applications and we 
> shouldn't try to fix them in kernel space. We can, of course, try to 
> find them and have all sorts of bells and whistles shouting 'process 
> %s is preventing CPU from sleeping for %llu nanoseconds' or something 
> like that.

Please note that this approach is not too practical for vendors who ship
systems like cell phones to the general public.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>Please note that this approach is not too practical for vendors who ship
>systems like cell phones to the general public.

yeah, tell me about it :-p

during development on MeeGo devices we try to tackle down as much as 
possible the use_time offenders and start by filing bugs to those apps, 
instead of fixing their issues in kernel space.

if suspend_blockers could at least be transparent to applications, then 
it wouldn't be the best scenario but at least applications wouldn't have 
to be specially written to support that. And like I said, if anyone can 
hold a suspend_blocker forever the idea of "improving use_time" is easy 
to break, but then someone replied "anyone holding a suspend_blocker 
will show up in UI", and again I say you don't need suspend_blockers to 
have a fancy UI showing which processes are waking up the processor. 
Powertop already gathers that information, you just need to make a fancy 
UI around it.

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

Hi,

On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>Please note that this approach is not too practical for vendors who ship
>systems like cell phones to the general public.

yeah, tell me about it :-p

during development on MeeGo devices we try to tackle down as much as 
possible the use_time offenders and start by filing bugs to those apps, 
instead of fixing their issues in kernel space.

if suspend_blockers could at least be transparent to applications, then 
it wouldn't be the best scenario but at least applications wouldn't have 
to be specially written to support that. And like I said, if anyone can 
hold a suspend_blocker forever the idea of "improving use_time" is easy 
to break, but then someone replied "anyone holding a suspend_blocker 
will show up in UI", and again I say you don't need suspend_blockers to 
have a fancy UI showing which processes are waking up the processor. 
Powertop already gathers that information, you just need to make a fancy 
UI around it.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Florian Mickler]

On Wed, 19 May 2010 09:59:34 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:


> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
> 
> I still think the kernel shouldn't deal with broken applications and we 
> shouldn't try to fix them in kernel space. We can, of course, try to 
> find them and have all sorts of bells and whistles shouting 'process 
> %s is preventing CPU from sleeping for %llu nanoseconds' or something 
> like that.
> 

But with that, you still shift the burden of exchanging that app with
an feature-equivalent non-broken version to the user. 
which is not user friendly and not necessary if you have a "smart"
enough kernel.

Cheers,
Flo 

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

[Florian Mickler]

On Wed, 19 May 2010 09:59:34 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:


> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
> 
> I still think the kernel shouldn't deal with broken applications and we 
> shouldn't try to fix them in kernel space. We can, of course, try to 
> find them and have all sorts of bells and whistles shouting 'process 
> %s is preventing CPU from sleeping for %llu nanoseconds' or something 
> like that.
> 

But with that, you still shift the burden of exchanging that app with
an feature-equivalent non-broken version to the user. 
which is not user friendly and not necessary if you have a "smart"
enough kernel.

Cheers,
Flo 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Florian Mickler]

On Wed, 19 May 2010 09:59:34 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:


> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
> 
> I still think the kernel shouldn't deal with broken applications and we 
> shouldn't try to fix them in kernel space. We can, of course, try to 
> find them and have all sorts of bells and whistles shouting 'process 
> %s is preventing CPU from sleeping for %llu nanoseconds' or something 
> like that.
> 

But with that, you still shift the burden of exchanging that app with
an feature-equivalent non-broken version to the user. 
which is not user friendly and not necessary if you have a "smart"
enough kernel.

Cheers,
Flo 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote:
> But with that, you still shift the burden of exchanging that app with
> an feature-equivalent non-broken version to the user. 
> which is not user friendly and not necessary if you have a "smart"
> enough kernel.

and _without that_, you shift the burden of having a working power
management completely into the kernel. Forcing the kernel to deal with
completely broken apps. What will happen is that apps developers won't
boder thinking about power consumption since the kernel is "smart"
enough to "fix" their mess.

To me that's much bigger burden to the kernel than the other option is
to apps.

-- 
balbi

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

[Felipe Balbi]

On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote:
> But with that, you still shift the burden of exchanging that app with
> an feature-equivalent non-broken version to the user. 
> which is not user friendly and not necessary if you have a "smart"
> enough kernel.

and _without that_, you shift the burden of having a working power
management completely into the kernel. Forcing the kernel to deal with
completely broken apps. What will happen is that apps developers won't
boder thinking about power consumption since the kernel is "smart"
enough to "fix" their mess.

To me that's much bigger burden to the kernel than the other option is
to apps.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Thu, May 20, 2010 at 10:57:40AM +0200, ext Felipe Balbi wrote:
>boder thinking about power consumption since the kernel is "smart"
  ^I mean bother

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

On Thu, May 20, 2010 at 10:57:40AM +0200, ext Felipe Balbi wrote:
>boder thinking about power consumption since the kernel is "smart"
  ^I mean bother

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Florian Mickler]

On Thu, 20 May 2010 11:57:40 +0300
Felipe Balbi <me@felipebalbi.com> wrote:

> On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote:
> > But with that, you still shift the burden of exchanging that app with
> > an feature-equivalent non-broken version to the user. 
> > which is not user friendly and not necessary if you have a "smart"
> > enough kernel.
> 
> and _without that_, you shift the burden of having a working power
> management completely into the kernel. Forcing the kernel to deal with
> completely broken apps. What will happen is that apps developers won't
> boder thinking about power consumption since the kernel is "smart"
> enough to "fix" their mess.
> 
> To me that's much bigger burden to the kernel than the other option is
> to apps.
> 

You said that already. For me this sounds like you want to take the
users hostage in order to get nice (poweraware) apps.

Robust system design can take crap and perform well. Users will most of
the time prefer a robust system over a nicely designed system. (Just
think of the ak-47)

I think we just have to agree to disagree here? 

Cheers,
Flo

p.s.: don't take me seriously, i'm just a user

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

[Florian Mickler]

On Thu, 20 May 2010 11:57:40 +0300
Felipe Balbi <me@felipebalbi.com> wrote:

> On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote:
> > But with that, you still shift the burden of exchanging that app with
> > an feature-equivalent non-broken version to the user. 
> > which is not user friendly and not necessary if you have a "smart"
> > enough kernel.
> 
> and _without that_, you shift the burden of having a working power
> management completely into the kernel. Forcing the kernel to deal with
> completely broken apps. What will happen is that apps developers won't
> boder thinking about power consumption since the kernel is "smart"
> enough to "fix" their mess.
> 
> To me that's much bigger burden to the kernel than the other option is
> to apps.
> 

You said that already. For me this sounds like you want to take the
users hostage in order to get nice (poweraware) apps.

Robust system design can take crap and perform well. Users will most of
the time prefer a robust system over a nicely designed system. (Just
think of the ak-47)

I think we just have to agree to disagree here? 

Cheers,
Flo

p.s.: don't take me seriously, i'm just a user

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

Hi,

On Thu, May 20, 2010 at 12:05:19PM +0200, ext Florian Mickler wrote:
>You said that already. For me this sounds like you want to take the
>users hostage in order to get nice (poweraware) apps.

not the users, no. The app developers. They should know what bad 
applications can cause to a nicely done system.

>Robust system design can take crap and perform well. Users will most of
>the time prefer a robust system over a nicely designed system. (Just
>think of the ak-47)

(hope you're talking about the gun :-p)
put some bad bullets on ak-47 and see if it behaves well, a really 
crappy trigger will also make it fail. How robust can a system be with 
badly chosen components ?

>I think we just have to agree to disagree here?

I think so.

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

Hi,

On Thu, May 20, 2010 at 12:05:19PM +0200, ext Florian Mickler wrote:
>You said that already. For me this sounds like you want to take the
>users hostage in order to get nice (poweraware) apps.

not the users, no. The app developers. They should know what bad 
applications can cause to a nicely done system.

>Robust system design can take crap and perform well. Users will most of
>the time prefer a robust system over a nicely designed system. (Just
>think of the ak-47)

(hope you're talking about the gun :-p)
put some bad bullets on ak-47 and see if it behaves well, a really 
crappy trigger will also make it fail. How robust can a system be with 
badly chosen components ?

>I think we just have to agree to disagree here?

I think so.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Vladimir Pantelic]

Felipe Balbi wrote:
> Hi,
>
> On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>>Please note that this approach is not too practical for vendors who ship
>>systems like cell phones to the general public.
>
> yeah, tell me about it :-p
>
> during development on MeeGo devices we try to tackle down as much as
> possible the use_time offenders and start by filing bugs to those apps,
> instead of fixing their issues in kernel space.

And you will continue doing that once the Meego app store has 100k apps?

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

[Vladimir Pantelic]

Felipe Balbi wrote:
> Hi,
>
> On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>>Please note that this approach is not too practical for vendors who ship
>>systems like cell phones to the general public.
>
> yeah, tell me about it :-p
>
> during development on MeeGo devices we try to tackle down as much as
> possible the use_time offenders and start by filing bugs to those apps,
> instead of fixing their issues in kernel space.

And you will continue doing that once the Meego app store has 100k apps?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Thu, May 20, 2010 at 01:27:25PM +0200, ext Vladimir Pantelic wrote:
>Felipe Balbi wrote:
>> Hi,
>>
>> On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>>>Please note that this approach is not too practical for vendors who ship
>>>systems like cell phones to the general public.
>>
>> yeah, tell me about it :-p
>>
>> during development on MeeGo devices we try to tackle down as much as
>> possible the use_time offenders and start by filing bugs to those apps,
>> instead of fixing their issues in kernel space.
>
>And you will continue doing that once the Meego app store has 100k apps?

I'm not here speaking for MeeGo. I'm presenting my own feelings and my 
own opinion regarding this issue. Don't bring the company into the game, 
please.

-- 
balbi

DefectiveByDesign.org

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

[Felipe Balbi]

On Thu, May 20, 2010 at 01:27:25PM +0200, ext Vladimir Pantelic wrote:
>Felipe Balbi wrote:
>> Hi,
>>
>> On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote:
>>>Please note that this approach is not too practical for vendors who ship
>>>systems like cell phones to the general public.
>>
>> yeah, tell me about it :-p
>>
>> during development on MeeGo devices we try to tackle down as much as
>> possible the use_time offenders and start by filing bugs to those apps,
>> instead of fixing their issues in kernel space.
>
>And you will continue doing that once the Meego app store has 100k apps?

I'm not here speaking for MeeGo. I'm presenting my own feelings and my 
own opinion regarding this issue. Don't bring the company into the game, 
please.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[David Brownell]

> > during development on MeeGo devices we try to tackle
> down as much as
> > possible the use_time offenders and start by filing
> bugs to those apps,
> > instead of fixing their issues in kernel space.

Some apps do abuse kernel mechanisms, and whether the bug is in the
app or that kernel mechanism can be a judgement call.  I'd expect to
see some fixes be appropriately in-kernel; maybe not many though.

When reading about this suspend block stuff, does anyone else hear
eachoes of APM?  It's been ages since that was used, but ISTR it also
leveraged handshaking between kernel and userspace.  Are there lessons
to be applied from there to this discussion?

On first principles, I don't see anything wrong with acknowledging that
the kernel doesn't have a "whole system PM view" and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request.

Just what that broad PM view consists of gets kind of system-specific.  For OMAP hardware, with smart device-level power reduction active almost
all the time, it may look different from an ACPI laptop where the BIOS
is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially "off-ness").




> And you will continue doing that once the Meego app store
> has 100k apps?

I may have overlooked it, in one of the 100K messsages in my
mailbox about versions of suspend block/etc patches ...

But surely NOBODY is actually contending that broken aps NOT get fixed??

It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools.  (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.)  Once such hogs get identified they will need to get fixed.  Any other proposal seems broken to me...

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

[David Brownell]

> > during development on MeeGo devices we try to tackle
> down as much as
> > possible the use_time offenders and start by filing
> bugs to those apps,
> > instead of fixing their issues in kernel space.

Some apps do abuse kernel mechanisms, and whether the bug is in the
app or that kernel mechanism can be a judgement call.  I'd expect to
see some fixes be appropriately in-kernel; maybe not many though.

When reading about this suspend block stuff, does anyone else hear
eachoes of APM?  It's been ages since that was used, but ISTR it also
leveraged handshaking between kernel and userspace.  Are there lessons
to be applied from there to this discussion?

On first principles, I don't see anything wrong with acknowledging that
the kernel doesn't have a "whole system PM view" and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request.

Just what that broad PM view consists of gets kind of system-specific.  For OMAP hardware, with smart device-level power reduction active almost
all the time, it may look different from an ACPI laptop where the BIOS
is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially "off-ness").




> And you will continue doing that once the Meego app store
> has 100k apps?

I may have overlooked it, in one of the 100K messsages in my
mailbox about versions of suspend block/etc patches ...

But surely NOBODY is actually contending that broken aps NOT get fixed??

It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools.  (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.)  Once such hogs get identified they will need to get fixed.  Any other proposal seems broken to me...

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Felipe Balbi]

On Thu, May 20, 2010 at 10:40:17AM -0700, David Brownell wrote:
> Some apps do abuse kernel mechanisms, and whether the bug is in the
> app or that kernel mechanism can be a judgement call.  I'd expect to

hey come on, there's no judgement call for an app polling every second
to check battery status or some other status that doesn't change that
frequently.

> I may have overlooked it, in one of the 100K messsages in my mailbox
> about versions of suspend block/etc patches ...
> 
> But surely NOBODY is actually contending that broken aps NOT get
> fixed??
> 
> It's clear to me that tools are needed to identify power hogs;
> powertop can't be the extent of such tools.  (ISTR it doesn't monitor
> display power usage, for one thing; maybe newer versions do so.)  Once
> such hogs get identified they will need to get fixed.  Any other
> proposal seems broken to me...

that's my feeling too. I don't see any needs for suspend blockers in any
real system. I acknowledge we need tools probing power consumption to be
shipped to production device, that's a good idea, but forcing apps to
modify just to have that UI fill up some treeview, I think it's a bit
too much.

-- 
balbi

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

[Felipe Balbi]

On Thu, May 20, 2010 at 10:40:17AM -0700, David Brownell wrote:
> Some apps do abuse kernel mechanisms, and whether the bug is in the
> app or that kernel mechanism can be a judgement call.  I'd expect to

hey come on, there's no judgement call for an app polling every second
to check battery status or some other status that doesn't change that
frequently.

> I may have overlooked it, in one of the 100K messsages in my mailbox
> about versions of suspend block/etc patches ...
> 
> But surely NOBODY is actually contending that broken aps NOT get
> fixed??
> 
> It's clear to me that tools are needed to identify power hogs;
> powertop can't be the extent of such tools.  (ISTR it doesn't monitor
> display power usage, for one thing; maybe newer versions do so.)  Once
> such hogs get identified they will need to get fixed.  Any other
> proposal seems broken to me...

that's my feeling too. I don't see any needs for suspend blockers in any
real system. I acknowledge we need tools probing power consumption to be
shipped to production device, that's a good idea, but forcing apps to
modify just to have that UI fill up some treeview, I think it's a bit
too much.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[David Brownell]

> -0700, David Brownell wrote:
> > Some apps do abuse kernel mechanisms, and whether the
> bug is in the
> > app or that kernel mechanism can be a judgement
> call.  I'd expect to
> 
> hey come on, there's no judgement call for an app polling
> every second
> to check battery status or some other status that doesn't
> change that frequently.

Or something as broken as a non-terminating CPU loop ...


Of course not.  But if there's a kernel mechanism exposed to
userspace which really sucks down power ... either it's done
correctly and the problem is userspace abusing it, or it's done
wrong so that it's not possible to be used correctly.  There are
some things that just cost power, and that cost can't be escaped.

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

[David Brownell]

> -0700, David Brownell wrote:
> > Some apps do abuse kernel mechanisms, and whether the
> bug is in the
> > app or that kernel mechanism can be a judgement
> call.  I'd expect to
> 
> hey come on, there's no judgement call for an app polling
> every second
> to check battery status or some other status that doesn't
> change that frequently.

Or something as broken as a non-terminating CPU loop ...


Of course not.  But if there's a kernel mechanism exposed to
userspace which really sucks down power ... either it's done
correctly and the problem is userspace abusing it, or it's done
wrong so that it's not possible to be used correctly.  There are
some things that just cost power, and that cost can't be escaped.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[David Brownell]

> -0700, David Brownell wrote:
> > Some apps do abuse kernel mechanisms, and whether the
> bug is in the
> > app or that kernel mechanism can be a judgement
> call.  I'd expect to
> 
> hey come on, there's no judgement call for an app polling
> every second
> to check battery status or some other status that doesn't
> change that frequently.

Or something as broken as a non-terminating CPU loop ...


Of course not.  But if there's a kernel mechanism exposed to
userspace which really sucks down power ... either it's done
correctly and the problem is userspace abusing it, or it's done
wrong so that it's not possible to be used correctly.  There are
some things that just cost power, and that cost can't be escaped.

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

[David Brownell]

> > > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
> > >
> > >> No, suspend blockers are mostly used to
> ensure wakeup events are not
> > >> ignored, and to ensure tasks triggered by
> these wakeup events
> > >> complete.
> > >
> > > Standard Linux systems don't need these,
> > 
> > If you don't want to lose wakeup events they do. 
> Standard Linux systems 
> > support suspend, but since they usually don't have a
> lot of wakeup 
> > events you don't run into a lot of problems.

Yes and no...  stick a bunch of USB hubs and devices
on the system, and you may have a lot of wake events.
Keyboard, mouse, network adapter, and so on.

 Way back when I made USB remote wakeup work, ISTR running
into a version of the issue you're raising.  Briefly, the
wake event could be queued in hardware, but there were also
various unavoidable races .... with ambiguity about just when
particular events should be recognized.  If the system entered
sleep before the wake event(s) triggered, or the relevant devices
suspended first, then things were clear; otherwise, not.  On
first blush, I'd expect every hardware wake mechanism would have
the same issues; the fact that USB wakes are mediated via khubd
is not a huge difference.

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

[Paul Walmsley]

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

Hello Matthew,

On Wed, 19 May 2010, Matthew Garrett wrote:

> On Wed, May 19, 2010 at 10:17:01AM -0600, Paul Walmsley wrote:
> 
> > Could you please elaborate, or provide a link to an E-mail in the archives 
> > that would explain why?
> 
> What would otherwise be a wakeup event may be delivered between you 
> deciding to stop tasks and you actually stopping tasks. How do you know 
> to restart tasks at that point?

The original message you sent[1] quoted this part[2] of the proposal:

----
       A. To prevent untrusted process timers from waking the system,
          the processes can be run in a cgroup that calls
          del_timer_sync() on all process timers upon receipt of some
          trigger.  When the system returns from the system low-power
          state and some trigger event happens, add_timer() can be
          called to add all the cgroup's timers back.
----

That isn't intended to address the task restarting problem.  The task 
restarting problem is intended to be addressed by this part[3]:

----
      B. To prevent untrusted processes from hogging CPUs, the
         processes can be run in a cgroup that puts all threads in
         TASK_RUNNING processes into TASK_INTERRUPTIBLE state and
         calls schedule() [6], upon receipt of some trigger.  This
         should allow processes to be awakened by an external system
         event, e.g., network packet received.  When the system
         returns from the system low-power state and some trigger
         event happens, those process threads can be placed back into
         TASK_RUNNING state and rescheduled.
----

It sounds like Android doesn't even need to use full system suspend if 
some proposal like (A) and (B) are implemented[4].  In that case, all the 
code that deals with races in full system suspend (like suspend blockers) 
can be dropped.


- Paul

1. Matthew Garrett E-mail to the linux-pm mailing list, dated Tue May 18
   02:55:19 +0100
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025664.html

2. Paragraph B4A of Paul Walmsley E-mail to the linux-pm mailing list, 
   dated Mon May 17 19:39:44 CDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html

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

4. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Mon, May 17 
   20:06:33 PDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html

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

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

[Paul Walmsley]

Hi,

just wanted to clarify one point:

On Fri, 21 May 2010, Paul Walmsley wrote:

> In that case, all the code that deals with races in full system suspend 
> (like suspend blockers) can be dropped.

Not necessarily dropped entirely - just considered separately, apart from 
the contexts of "getting Android device drivers upstream" and "pausing 
processes/timers before entering a system low-power state".


- Paul

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

[Matthew Garrett]

On Fri, May 21, 2010 at 10:51:58AM -0600, Paul Walmsley wrote:

>       B. To prevent untrusted processes from hogging CPUs, the
>          processes can be run in a cgroup that puts all threads in
>          TASK_RUNNING processes into TASK_INTERRUPTIBLE state and
>          calls schedule() [6], upon receipt of some trigger.  This
>          should allow processes to be awakened by an external system
>          event, e.g., network packet received.  When the system
>          returns from the system low-power state and some trigger
>          event happens, those process threads can be placed back into
>          TASK_RUNNING state and rescheduled.

I don't think that works. If I have an app that would generally complete 
some work and then call select(), you'll instead stop it in the middle 
of that work. If that app is the one that should process the wakeup 
event then it'll never be delivered because you've never got back to 
select().

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

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

[Pavel Machek]

Hi!

> I agree that the runtime scenario is a far more appealing one from an 
> aesthetic standpoint, but so far we don't have a very compelling 
> argument for dealing with the starting and stopping of userspace. The 
> use-cases that Google have provided are valid and they have an 
> implementation that addresses them, and while we're unable to provide an 
> alternative that provides the same level of functionality I think we're 
> in a poor position to prevent this from going in.

Uhuh?

"We have this ugly code here, but it works and we don't have better
one, so lets merge it"?

I don't really like this line of reasoning. I would not want to judge
wakelocks here, but... "it works, merge it" should not be used as
argument.

And btw I do have wakelock-less implementation of autosleep, that only
sleeped the machine when nothing was ready to run. It was called
"sleepy linux". Should I dig it out?

Major difference was that it only sleeped the machine when it was
absolutely certain machine is idle and no timers are close to firing
-- needing elimination or at least markup of all short timers. It
erred on side of not sleeping the machine when it would break
something.

Still I believe it is better design than wakelocks -- that need
markup/fixes to all places where machine must not sleep -- effectively
sleeping the machine too often than fixing stuff with wakelocks all
over kernel and userspace...
								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 6)

[Pavel Machek]

Hi!

> I agree that the runtime scenario is a far more appealing one from an 
> aesthetic standpoint, but so far we don't have a very compelling 
> argument for dealing with the starting and stopping of userspace. The 
> use-cases that Google have provided are valid and they have an 
> implementation that addresses them, and while we're unable to provide an 
> alternative that provides the same level of functionality I think we're 
> in a poor position to prevent this from going in.

Uhuh?

"We have this ugly code here, but it works and we don't have better
one, so lets merge it"?

I don't really like this line of reasoning. I would not want to judge
wakelocks here, but... "it works, merge it" should not be used as
argument.

And btw I do have wakelock-less implementation of autosleep, that only
sleeped the machine when nothing was ready to run. It was called
"sleepy linux". Should I dig it out?

Major difference was that it only sleeped the machine when it was
absolutely certain machine is idle and no timers are close to firing
-- needing elimination or at least markup of all short timers. It
erred on side of not sleeping the machine when it would break
something.

Still I believe it is better design than wakelocks -- that need
markup/fixes to all places where machine must not sleep -- effectively
sleeping the machine too often than fixing stuff with wakelocks all
over kernel and userspace...
								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 6)

[Matthew Garrett]

On Mon, May 24, 2010 at 08:57:54PM +0200, Pavel Machek wrote:

> And btw I do have wakelock-less implementation of autosleep, that only
> sleeped the machine when nothing was ready to run. It was called
> "sleepy linux". Should I dig it out?

As has been explained several times now, that's not equivalent. The 
difference is what makes this a hard problem. If a usecase is valid and 
nobody can come up with a convincing explanation of what an elegant 
solution would look like, then the ugly solution wins.

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

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

[Matthew Garrett]

On Mon, May 24, 2010 at 08:57:54PM +0200, Pavel Machek wrote:

> And btw I do have wakelock-less implementation of autosleep, that only
> sleeped the machine when nothing was ready to run. It was called
> "sleepy linux". Should I dig it out?

As has been explained several times now, that's not equivalent. The 
difference is what makes this a hard problem. If a usecase is valid and 
nobody can come up with a convincing explanation of what an elegant 
solution would look like, then the ugly solution wins.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Pavel Machek]

Hi!

> > There are several general problems with the design of opportunistic
> > suspend and suspend-blocks.
> > 
> > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> >    such as timers and the scheduler, that indicates when code
> >    needs to run, and when the system is idle.
> 
> Whoa!  That's not my understanding at all.
> 
> As I see it, opportunistic suspend doesn't bypass any code that isn't 
> already bypassed by the existing suspend code.  Users can do
> 
> 	echo mem >/sys/power/state
> 
> whenever they want, without regard to kernel timers and the scheduler 
> (other than the fact that the user's thread must be running in order to 
> carry out the write, of course).

Yep. And while I'm co-responsible for that interface, I would not
call it exactly nice. Yes, it does the job.

But imagine horrors atd/cron would have to do to work properly with
that interface... setting rtc wakeups etc.

So yes, mem > state already breaks promises, but lets not extend that.

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

[Pavel Machek]

Hi!

> > There are several general problems with the design of opportunistic
> > suspend and suspend-blocks.
> > 
> > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> >    such as timers and the scheduler, that indicates when code
> >    needs to run, and when the system is idle.
> 
> Whoa!  That's not my understanding at all.
> 
> As I see it, opportunistic suspend doesn't bypass any code that isn't 
> already bypassed by the existing suspend code.  Users can do
> 
> 	echo mem >/sys/power/state
> 
> whenever they want, without regard to kernel timers and the scheduler 
> (other than the fact that the user's thread must be running in order to 
> carry out the write, of course).

Yep. And while I'm co-responsible for that interface, I would not
call it exactly nice. Yes, it does the job.

But imagine horrors atd/cron would have to do to work properly with
that interface... setting rtc wakeups etc.

So yes, mem > state already breaks promises, but lets not extend that.

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

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Pavel Machek]

On Thu 2010-05-13 21:08:14, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> 
> > The system stays running because there's something to do. The system
> > won't suspend until all the processors hit the kernel idle loop and
> > the next_timer_interrupt_critical() returns nothing.
> 
> At which point an application in a busy loop cripples you. I think we 

Application running busy loop already cripples you, with power going
from 15W to 50W in thinkpad case. Just avoid badly written apps.

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

[Pavel Machek]

On Thu 2010-05-13 21:08:14, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> 
> > The system stays running because there's something to do. The system
> > won't suspend until all the processors hit the kernel idle loop and
> > the next_timer_interrupt_critical() returns nothing.
> 
> At which point an application in a busy loop cripples you. I think we 

Application running busy loop already cripples you, with power going
from 15W to 50W in thinkpad case. Just avoid badly written apps.

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

[Arve Hjønnevåg]

On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> I agree that the runtime scenario is a far more appealing one from an
>> aesthetic standpoint, but so far we don't have a very compelling
>> argument for dealing with the starting and stopping of userspace. The
>> use-cases that Google have provided are valid and they have an
>> implementation that addresses them, and while we're unable to provide an
>> alternative that provides the same level of functionality I think we're
>> in a poor position to prevent this from going in.
>
> Uhuh?
>
> "We have this ugly code here, but it works and we don't have better
> one, so lets merge it"?
>
> I don't really like this line of reasoning. I would not want to judge
> wakelocks here, but... "it works, merge it" should not be used as
> argument.
>
> And btw I do have wakelock-less implementation of autosleep, that only
> sleeped the machine when nothing was ready to run. It was called
> "sleepy linux". Should I dig it out?
>
> Major difference was that it only sleeped the machine when it was
> absolutely certain machine is idle and no timers are close to firing
> -- needing elimination or at least markup of all short timers. It
> erred on side of not sleeping the machine when it would break
> something.
>

How did you handle external events that occur right after you decided to sleep?

> Still I believe it is better design than wakelocks -- that need
> markup/fixes to all places where machine must not sleep -- effectively
> sleeping the machine too often than fixing stuff with wakelocks all
> over kernel and userspace...

-- 
Arve Hjønnevåg

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

[Arve Hjønnevåg]

On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> I agree that the runtime scenario is a far more appealing one from an
>> aesthetic standpoint, but so far we don't have a very compelling
>> argument for dealing with the starting and stopping of userspace. The
>> use-cases that Google have provided are valid and they have an
>> implementation that addresses them, and while we're unable to provide an
>> alternative that provides the same level of functionality I think we're
>> in a poor position to prevent this from going in.
>
> Uhuh?
>
> "We have this ugly code here, but it works and we don't have better
> one, so lets merge it"?
>
> I don't really like this line of reasoning. I would not want to judge
> wakelocks here, but... "it works, merge it" should not be used as
> argument.
>
> And btw I do have wakelock-less implementation of autosleep, that only
> sleeped the machine when nothing was ready to run. It was called
> "sleepy linux". Should I dig it out?
>
> Major difference was that it only sleeped the machine when it was
> absolutely certain machine is idle and no timers are close to firing
> -- needing elimination or at least markup of all short timers. It
> erred on side of not sleeping the machine when it would break
> something.
>

How did you handle external events that occur right after you decided to sleep?

> Still I believe it is better design than wakelocks -- that need
> markup/fixes to all places where machine must not sleep -- effectively
> sleeping the machine too often than fixing stuff with wakelocks all
> over kernel and userspace...

-- 
Arve Hjønnevåg

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

[Paul Walmsley]

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

Hello Arve,

I regret the delay in responding.

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

> On Mon, May 17, 2010 at 7:26 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
> >> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
> >> >
> >> >> No, suspend blockers are mostly used to ensure wakeup events are not
> >> >> ignored, and to ensure tasks triggered by these wakeup events
> >> >> complete.
> >> >
> >> > Standard Linux systems don't need these,
> >>
> >> If you don't want to lose wakeup events they do.  Standard Linux systems
> >> support suspend, but since they usually don't have a lot of wakeup
> >> events you don't run into a lot of problems.
> >
> > Sorry, I don't follow.  What causes wakeup events to be lost?  Is it the
> > current opportunistic suspend governor?  On OMAP Linux systems, as far as
> > I know, we don't lose any wakeup events.
> >
> Have you used suspend?

I see.  You are referring to wakeup event loss/delay caused by the full 
system suspend process (e.g., kernel/power/suspend.c:enter_state() 
onwards[1]), correct?  This message addresses this at the end of the mail.

> >> > because the scheduler just keeps the system running as long as there
> >> > is work to be done.
> >>
> >> That is only true if you never use suspend.
> >
> > If, instead of the current Android opportunistic suspend governor, the
> > system entered suspend from pm_idle(), wouldn't that keep the system
> > running as long as there is work to done?
> >
> How do you know if the work being done while suspending is work that
> is needed to suspend or work that should abort suspend?

Consider a suspending system in which all "untrusted" processes have been 
placed into TASK_INTERRUPTIBLE state and have had their timers 
disabled.[2] The only remaining work to do on the system is work that 
needs to be done as part of the suspend process, or work that is part of a 
"trusted" process or the kernel.  If the suspend needs to be aborted due 
to the arrival of an event, this can be handled as part of the standard 
suspend process (described below).

> When should the system wake up?

I suspect that I am misunderstanding your question, but the system should 
wake up the same way it does now: when a wakeup interrupt arrives (either 
from the next scheduled timer expiration, or from some external device).

> > As far as I can see, it's the current Android opportunistic suspend
> > governor design in patch 1 that causes the system to enter suspend even
> > when there is work to be done, since it will try to suspend even when the
> > system is out of the idle loop.
> 
> It does not matter how you enter suspend. Without opportunistic suspend, 
> once you tell the kernel that you want to suspend, you cannot abort.

Any driver should be able to abort suspend by returning an error from its 
struct device_driver/struct dev_pm_ops suspend function.  Consider this 
partial callgraph for full system suspend, from [3], [4]:

   kernel/power/suspend.c:   enter_state() ->
   kernel/power/suspend.c:    suspend_devices_and_enter() ->
drivers/base/power/main.c:     dpm_suspend_start() ->
drivers/base/power/main.c:      dpm_suspend() ->
drivers/base/power/main.c:       device_suspend() ->
drivers/base/power/main.c:        __device_suspend() ->
drivers/base/power/main.c:         pm_op() ->
drivers/base/power/main.c:          ops->suspend()

If ops->suspend() returns an error, it's ultimately passed back to 
suspend_devices_and_enter(), which aborts the suspend[5].

In this context, the main change that should be necessary is for 
driver/subsystem suspend functions to return an error when there are 
events pending.  For example, as an alternative to the Android series' 
evdev.c patch[6], the evdev.c suspend function could return an error such 
as -EBUSY if events are currently queued (example below).

Aborting suspend in the event of driver activity seems like the right 
thing to do in a system that attempts to enter full system suspend while 
idle.  But it is not the current expected Linux behavior, which also seems 
useful.  Any abort-suspend-if-busy behavior should be configurable.  One 
way would be to add a sysfs file for each driver/subsystem: perhaps 
something like 'abort_suspend_if_busy'.  The default value would be zero 
to preserve the current behavior.  Systems that wish to use opportunistic 
suspend could write a one to some or all of those files.

An untested, purely illustrative example, based on evdev.c, is at the end 
of this message.  It's not meant to be functional; it's just meant to 
demonstrate the basic idea in code form.

...

Like suspend-blockers, adding abort_suspend_if_busy support would require 
changes throughout many drivers and subsystems.  However, unlike 
suspend-blockers, the above abort_suspend_if_busy approach would not 
introduce any new APIs[7], nor would it change the default suspend 
behavior of the system.

As an aside, it seems that Android shouldn't currently need this if it's 
possible to pause "untrusted" processes and timers[8], since current 
shipping Android hardware can enter the same system low power state both 
with and without full system suspend[9].  But this could be useful for 
non-Android systems that still wish to use an idle-loop based, 
opportunistic full system suspend.


regards,

- Paul


1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l258

2. Section B4 of Paul Walmsley E-mail to the linux-pm mailing list, 
   dated Mon May 17 19:39:44 CDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html

3. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l258

4. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/base/power/main.c;h=941fcb87e52a12765df2aaa2e2ab21267693af9f;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l1062

5. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l207

6. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Fri May 21 
   15:46:54 PDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025747.html

7. Paul Walmsley E-mail to the linux-pm mailing list, dated Thu May 13 
   23:13:50 PDT 2010:
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025524.html

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

9. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Mon, May 17 
   20:06:33 PDT 2010:   
   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html



--------------------------------------------------------------------------------------

evdev.c abort_suspend_if_idle experiment:

---
 drivers/input/evdev.c |   64 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 63 insertions(+), 1 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2ee6c7a..23eaad1 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -20,8 +20,16 @@
 #include <linux/input.h>
 #include <linux/major.h>
 #include <linux/device.h>
+#include <linux/pm.h>
 #include "input-compat.h"
 
+/*
+ * abort_suspend_if_busy: set to 1 to prevent suspend as long as there
+ * is an event in the queue; set to 0 to allow suspend at any time.
+ * XXX Intended to be read from sysfs or the input subsystem.
+ */
+static int abort_suspend_if_busy;
+
 struct evdev {
 	int exist;
 	int open;
@@ -118,6 +126,36 @@ static int evdev_flush(struct file *file, fl_owner_t id)
 	return retval;
 }
 
+static int evdev_suspend(struct device *dev)
+{
+	struct evdev *evdev = container_of(dev, struct evdev, dev);
+	struct evdev_client *client;
+	int ret = 0;
+
+	if (!abort_suspend_if_busy)
+		return 0;
+
+	rcu_read_lock();
+
+	client = rcu_dereference(evdev->grab);
+	if (client) {
+		if (client->head != client->tail)
+			ret = -EBUSY;
+	} else {
+		list_for_each_entry_rcu(client, &evdev->client_list, node) {
+			if (client->head != client->tail) {
+				ret = -EBUSY;
+				break;
+			}
+		}
+	}
+
+	rcu_read_unlock();
+
+	return ret;
+}
+
+
 static void evdev_free(struct device *dev)
 {
 	struct evdev *evdev = container_of(dev, struct evdev, dev);
@@ -787,6 +825,21 @@ static void evdev_cleanup(struct evdev *evdev)
 	}
 }
 
+static const struct dev_pm_ops evdev_pm_ops = {
+	.suspend	= &evdev_suspend,
+};
+
+static char *evdev_devnode(struct device *dev, mode_t *mode)
+{
+	return kasprintf(GFP_KERNEL, "input/%s", dev_name(dev));
+}
+
+static struct class evdev_class = {
+	.name		= "evdev",
+	.devnode	= evdev_devnode,
+	.pm		= &evdev_pm_ops,
+};
+
 /*
  * Create new evdev device. Note that input core serializes calls
  * to connect and disconnect so we don't need to lock evdev_table here.
@@ -826,7 +879,7 @@ static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
 	evdev->handle.private = evdev;
 
 	evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
-	evdev->dev.class = &input_class;
+	evdev->dev.class = &evdev_class;
 	evdev->dev.parent = &dev->dev;
 	evdev->dev.release = evdev_free;
 	device_initialize(&evdev->dev);
@@ -883,12 +936,21 @@ static struct input_handler evdev_handler = {
 
 static int __init evdev_init(void)
 {
+	int err;
+
+	err = class_register(&input_class);
+	if (err) {
+		printk(KERN_ERR "evdev: unable to register evdev class\n");
+		return err;
+	}
+
 	return input_register_handler(&evdev_handler);
 }
 
 static void __exit evdev_exit(void)
 {
 	input_unregister_handler(&evdev_handler);
+	class_unregister(&evdev_class);
 }
 
 module_init(evdev_init);
-- 
1.7.1.GIT

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

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

[Dmitry Torokhov]

On Fri, May 14, 2010 at 03:18:13PM -0700, Arve Hjønnevåg wrote:
> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Hello,
> >
> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
> >
> >> No, suspend blockers are mostly used to ensure wakeup events are not
> >> ignored, and to ensure tasks triggered by these wakeup events
> >> complete.
> >
> > Standard Linux systems don't need these,
> 
> If you don't want to lose wakeup events they do. Standard Linux
> systems support suspend, but since they usually don't have a lot of
> wakeup events you don't run into a lot of problems.
> 

What I do not quite understand is how exactly suspend blocks save us
from missing wakeup events. Consider case when all events have been
processed and system starts entering the sleep: we are in a half-sleep,
half awake state, with some devices already put to sleep and some just
now being processed. If user presses a key while physical input device
is being suspended, what will happen? Do you expect interrupt routine
abort suspend process? Initiate resume if suspend of the device has
completed?

Also, let's say device is suspended and is configured as a wakeup source
while the rest of the system is still awake... If I press a key I do not
think that it will necessarily abort suspend process. Or will it?

BTW, If you are concerned about events that already "left" physical
device but has not reached userspace yet - maybe instead of suspend
blockers we should make sure that all drivers throughout the chain
implement suspend/resume and refuse suspending if their queues are not
empty.  In input land that would mean extending suspend routine in
input_dev and adding one to evdev.

Thanks.

-- 
Dmitry

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

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> What I do not quite understand is how exactly suspend blocks save us
> from missing wakeup events. Consider case when all events have been
> processed and system starts entering the sleep: we are in a half-sleep,
> half awake state, with some devices already put to sleep and some just
> now being processed. If user presses a key while physical input device
> is being suspended, what will happen? Do you expect interrupt routine
> abort suspend process? Initiate resume if suspend of the device has
> completed?

This depends on several factors, such as how the input device drivers
are written and how the hardware works, as well as the details of the 
timing.  Here are a few possibilities:

	The keypress is not handled but stays in the hardware as a
	wakeup event.  The system goes through its entire suspend
	procedure, and then the pending wakeup event immediately
	cases it to wake up.  Then the keypress gets handled
	normally.

	Or the keypress is treated as a normal IRQ and handled by
	the hardware.  The input subsystem puts the keystroke on
	the event queue (all done while in_interrupt), where it
	languishes because userspace is frozen and can't read it.
	The system goes to sleep and stays that way until something
	else wakes it up.  (This is a type-3 failure as described
	in my earlier email.)

	Or the keypress is handled normally and the input subsystem 
	interprets it as a runtime resume request, telling the PM core 
	to queue a resume call.  But the PM core's runtime workqueue 
	thread has already been frozen, and so the event remains on the 
	work queue until the system wakes up on its own.  (This is a
	type-2 failure.)

	Or we fix the PM core, so that when the resume call is added
	to the workqueue it realizes the suspend-in-progress needs
	to be aborted.  The system goes back to a fully-awake state
	and the keystroke is handled normally.

> Also, let's say device is suspended and is configured as a wakeup source
> while the rest of the system is still awake... If I press a key I do not
> think that it will necessarily abort suspend process. Or will it?

Since the keyboard is a wakeup device, it certainly should abort the
suspend.  Or at least it should wake the system up as soon as the
system finishes going to sleep.  At the moment, though, I'm not sure
that it does behave either way.

> BTW, If you are concerned about events that already "left" physical
> device but has not reached userspace yet - maybe instead of suspend
> blockers we should make sure that all drivers throughout the chain
> implement suspend/resume and refuse suspending if their queues are not
> empty.  In input land that would mean extending suspend routine in
> input_dev and adding one to evdev.

That's not the only problem.  We also have to consider events that have
reached userspace but not yet been fully processed.  The user thread
handling the event needs some way to prevent the system from suspending
until it is all done.

Alan Stern

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

[Dmitry Torokhov]

On Tue, May 25, 2010 at 02:25:08PM -0400, Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> 
> > BTW, If you are concerned about events that already "left" physical
> > device but has not reached userspace yet - maybe instead of suspend
> > blockers we should make sure that all drivers throughout the chain
> > implement suspend/resume and refuse suspending if their queues are not
> > empty.  In input land that would mean extending suspend routine in
> > input_dev and adding one to evdev.
> 
> That's not the only problem.  We also have to consider events that have
> reached userspace but not yet been fully processed.  The user thread
> handling the event needs some way to prevent the system from suspending
> until it is all done.
> 

It is a problem if kernel initiated suspend transition on its own. I
believe that it is userspace responsibility to initiate sustend (and
make sure that needs of userspace, including processing of certain
events, are served beforehand).

-- 
Dmitry

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

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 11:33 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, May 25, 2010 at 02:25:08PM -0400, Alan Stern wrote:
>> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>
>> > BTW, If you are concerned about events that already "left" physical
>> > device but has not reached userspace yet - maybe instead of suspend
>> > blockers we should make sure that all drivers throughout the chain
>> > implement suspend/resume and refuse suspending if their queues are not
>> > empty.  In input land that would mean extending suspend routine in
>> > input_dev and adding one to evdev.
>>
>> That's not the only problem.  We also have to consider events that have
>> reached userspace but not yet been fully processed.  The user thread
>> handling the event needs some way to prevent the system from suspending
>> until it is all done.
>>
>
> It is a problem if kernel initiated suspend transition on its own. I
> believe that it is userspace responsibility to initiate sustend (and
> make sure that needs of userspace, including processing of certain
> events, are served beforehand).

That only works if a single user-space thread initiates suspend and
consumes all wakeup events (or if the user-space code that initiates
suspend implements suspend blockers), and even then the kernel would
still need to block suspend in same places as it does if the kernel
initiates suspend. If a wakeup event happens right after user-space
initiates suspend, that suspend must be aborted. By only initiating
suspend from user-space, you force this to be a polling operation.

-- 
Arve Hjønnevåg

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

[Dmitry Torokhov]

On Tue, May 25, 2010 at 03:05:41PM -0700, Arve Hjønnevåg wrote:
> On Tue, May 25, 2010 at 11:33 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, May 25, 2010 at 02:25:08PM -0400, Alan Stern wrote:
> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >>
> >> > BTW, If you are concerned about events that already "left" physical
> >> > device but has not reached userspace yet - maybe instead of suspend
> >> > blockers we should make sure that all drivers throughout the chain
> >> > implement suspend/resume and refuse suspending if their queues are not
> >> > empty.  In input land that would mean extending suspend routine in
> >> > input_dev and adding one to evdev.
> >>
> >> That's not the only problem.  We also have to consider events that have
> >> reached userspace but not yet been fully processed.  The user thread
> >> handling the event needs some way to prevent the system from suspending
> >> until it is all done.
> >>
> >
> > It is a problem if kernel initiated suspend transition on its own. I
> > believe that it is userspace responsibility to initiate sustend (and
> > make sure that needs of userspace, including processing of certain
> > events, are served beforehand).
> 
> That only works if a single user-space thread initiates suspend

Yes, there should be a single entity controlling suspend.

> and
> consumes all wakeup events (or if the user-space code that initiates
> suspend implements suspend blockers),

Yes.

> and even then the kernel would
> still need to block suspend in same places as it does if the kernel
> initiates suspend. If a wakeup event happens right after user-space
> initiates suspend, that suspend must be aborted.

This is true regardless of whether we use suspend blockers or not. If,
after initiating suspend, we detect wake up event that event shoudl be
acted upon and suspend should be ignored.

> By only initiating
> suspend from user-space, you force this to be a polling operation.
>

I am not sure what you mean by this.

-- 
Dmitry

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

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 2:41 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Arve,
>
> I regret the delay in responding.
>
> On Mon, 17 May 2010, Arve Hjønnevåg wrote:
>
>> On Mon, May 17, 2010 at 7:26 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Fri, 14 May 2010, Arve Hjønnevåg wrote:
>> >> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> > On Mon, 3 May 2010, Arve Hjønnevåg wrote:
>> >> >
>> >> >> No, suspend blockers are mostly used to ensure wakeup events are not
>> >> >> ignored, and to ensure tasks triggered by these wakeup events
>> >> >> complete.
>> >> >
>> >> > Standard Linux systems don't need these,
>> >>
>> >> If you don't want to lose wakeup events they do.  Standard Linux systems
>> >> support suspend, but since they usually don't have a lot of wakeup
>> >> events you don't run into a lot of problems.
>> >
>> > Sorry, I don't follow.  What causes wakeup events to be lost?  Is it the
>> > current opportunistic suspend governor?  On OMAP Linux systems, as far as
>> > I know, we don't lose any wakeup events.
>> >
>> Have you used suspend?
>
> I see.  You are referring to wakeup event loss/delay caused by the full
> system suspend process (e.g., kernel/power/suspend.c:enter_state()
> onwards[1]), correct?  This message addresses this at the end of the mail.
>
>> >> > because the scheduler just keeps the system running as long as there
>> >> > is work to be done.
>> >>
>> >> That is only true if you never use suspend.
>> >
>> > If, instead of the current Android opportunistic suspend governor, the
>> > system entered suspend from pm_idle(), wouldn't that keep the system
>> > running as long as there is work to done?
>> >
>> How do you know if the work being done while suspending is work that
>> is needed to suspend or work that should abort suspend?
>
> Consider a suspending system in which all "untrusted" processes have been
> placed into TASK_INTERRUPTIBLE state and have had their timers
> disabled.[2] The only remaining work to do on the system is work that
> needs to be done as part of the suspend process, or work that is part of a
> "trusted" process or the kernel.  If the suspend needs to be aborted due
> to the arrival of an event, this can be handled as part of the standard
> suspend process (described below).
>

That means modifying all kernel code that would use suspend blockers
to abort suspend by returning an error from suspend instead. How is
this better than using suspend blockers?

>> When should the system wake up?
>
> I suspect that I am misunderstanding your question, but the system should
> wake up the same way it does now: when a wakeup interrupt arrives (either
> from the next scheduled timer expiration, or from some external device).
>

That is not how the system wakes up from suspend now. The monotonic
clock stops, and timers are ignored.

>> > As far as I can see, it's the current Android opportunistic suspend
>> > governor design in patch 1 that causes the system to enter suspend even
>> > when there is work to be done, since it will try to suspend even when the
>> > system is out of the idle loop.
>>
>> It does not matter how you enter suspend. Without opportunistic suspend,
>> once you tell the kernel that you want to suspend, you cannot abort.
>
> Any driver should be able to abort suspend by returning an error from its
> struct device_driver/struct dev_pm_ops suspend function.  Consider this

Yes a driver can abort, but the user space code that initiated suspend cannot.

> partial callgraph for full system suspend, from [3], [4]:
>
>   kernel/power/suspend.c:   enter_state() ->
>   kernel/power/suspend.c:    suspend_devices_and_enter() ->
> drivers/base/power/main.c:     dpm_suspend_start() ->
> drivers/base/power/main.c:      dpm_suspend() ->
> drivers/base/power/main.c:       device_suspend() ->
> drivers/base/power/main.c:        __device_suspend() ->
> drivers/base/power/main.c:         pm_op() ->
> drivers/base/power/main.c:          ops->suspend()
>
> If ops->suspend() returns an error, it's ultimately passed back to
> suspend_devices_and_enter(), which aborts the suspend[5].
>
> In this context, the main change that should be necessary is for
> driver/subsystem suspend functions to return an error when there are
> events pending.  For example, as an alternative to the Android series'
> evdev.c patch[6], the evdev.c suspend function could return an error such
> as -EBUSY if events are currently queued (example below).
>
> Aborting suspend in the event of driver activity seems like the right
> thing to do in a system that attempts to enter full system suspend while
> idle.  But it is not the current expected Linux behavior, which also seems
> useful.  Any abort-suspend-if-busy behavior should be configurable.  One
> way would be to add a sysfs file for each driver/subsystem: perhaps
> something like 'abort_suspend_if_busy'.  The default value would be zero
> to preserve the current behavior.  Systems that wish to use opportunistic
> suspend could write a one to some or all of those files.
>
> An untested, purely illustrative example, based on evdev.c, is at the end
> of this message.  It's not meant to be functional; it's just meant to
> demonstrate the basic idea in code form.
>

Do you think this is simpler than using a suspend blocker?

> ...
>
> Like suspend-blockers, adding abort_suspend_if_busy support would require
> changes throughout many drivers and subsystems.  However, unlike
> suspend-blockers, the above abort_suspend_if_busy approach would not
> introduce any new APIs[7], nor would it change the default suspend
> behavior of the system.
>

Opportunistic suspend does not change the default behaviour either.
Your proposal requires that all the drivers that would block suspend
using a suspend blocker, now block suspend without the help of the
suspend blocker api.

> As an aside, it seems that Android shouldn't currently need this if it's
> possible to pause "untrusted" processes and timers[8], since current

Your proposal to "pause"processes by putting them in
TASK_INTERRUPTIBLE state and stop their timers does not work. It is
effectivly the same ase freezing them, since if you "paused" it while
it was busy, a wakeup event cannot unpause it.

> shipping Android hardware can enter the same system low power state both
> with and without full system suspend[9].  But this could be useful for
> non-Android systems that still wish to use an idle-loop based,
> opportunistic full system suspend.
>
>
> regards,
>
> - Paul
>
>
> 1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l258
>
> 2. Section B4 of Paul Walmsley E-mail to the linux-pm mailing list,
>   dated Mon May 17 19:39:44 CDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025663.html
>
> 3. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l258
>
> 4. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/base/power/main.c;h=941fcb87e52a12765df2aaa2e2ab21267693af9f;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l1062
>
> 5. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/power/suspend.c;h=56e7dbb8b996db295b4fc7cdf1b5f11a0409cb0c;hb=7e125f7b9cbfce4101191b8076d606c517a73066#l207
>
> 6. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Fri May 21
>   15:46:54 PDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025747.html
>
> 7. Paul Walmsley E-mail to the linux-pm mailing list, dated Thu May 13
>   23:13:50 PDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025524.html
>
> 8. 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
>
> 9. Arve Hjønnevåg E-mail to the linux-pm mailing list, dated Mon, May 17
>   20:06:33 PDT 2010:
>   https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
>
>
>
> --------------------------------------------------------------------------------------
>
> evdev.c abort_suspend_if_idle experiment:
>
> ---
>  drivers/input/evdev.c |   64 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 63 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 2ee6c7a..23eaad1 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -20,8 +20,16 @@
>  #include <linux/input.h>
>  #include <linux/major.h>
>  #include <linux/device.h>
> +#include <linux/pm.h>
>  #include "input-compat.h"
>
> +/*
> + * abort_suspend_if_busy: set to 1 to prevent suspend as long as there
> + * is an event in the queue; set to 0 to allow suspend at any time.
> + * XXX Intended to be read from sysfs or the input subsystem.
> + */
> +static int abort_suspend_if_busy;
> +
>  struct evdev {
>        int exist;
>        int open;
> @@ -118,6 +126,36 @@ static int evdev_flush(struct file *file, fl_owner_t id)
>        return retval;
>  }
>
> +static int evdev_suspend(struct device *dev)
> +{
> +       struct evdev *evdev = container_of(dev, struct evdev, dev);
> +       struct evdev_client *client;
> +       int ret = 0;
> +
> +       if (!abort_suspend_if_busy)
> +               return 0;
> +
> +       rcu_read_lock();
> +
> +       client = rcu_dereference(evdev->grab);
> +       if (client) {
> +               if (client->head != client->tail)
> +                       ret = -EBUSY;
> +       } else {
> +               list_for_each_entry_rcu(client, &evdev->client_list, node) {
> +                       if (client->head != client->tail) {
> +                               ret = -EBUSY;
> +                               break;
> +                       }
> +               }
> +       }
> +
> +       rcu_read_unlock();
> +
> +       return ret;
> +}
> +
> +
>  static void evdev_free(struct device *dev)
>  {
>        struct evdev *evdev = container_of(dev, struct evdev, dev);
> @@ -787,6 +825,21 @@ static void evdev_cleanup(struct evdev *evdev)
>        }
>  }
>
> +static const struct dev_pm_ops evdev_pm_ops = {
> +       .suspend        = &evdev_suspend,
> +};
> +
> +static char *evdev_devnode(struct device *dev, mode_t *mode)
> +{
> +       return kasprintf(GFP_KERNEL, "input/%s", dev_name(dev));
> +}
> +
> +static struct class evdev_class = {
> +       .name           = "evdev",
> +       .devnode        = evdev_devnode,
> +       .pm             = &evdev_pm_ops,
> +};
> +
>  /*
>  * Create new evdev device. Note that input core serializes calls
>  * to connect and disconnect so we don't need to lock evdev_table here.
> @@ -826,7 +879,7 @@ static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
>        evdev->handle.private = evdev;
>
>        evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
> -       evdev->dev.class = &input_class;
> +       evdev->dev.class = &evdev_class;
>        evdev->dev.parent = &dev->dev;
>        evdev->dev.release = evdev_free;
>        device_initialize(&evdev->dev);
> @@ -883,12 +936,21 @@ static struct input_handler evdev_handler = {
>
>  static int __init evdev_init(void)
>  {
> +       int err;
> +
> +       err = class_register(&input_class);
> +       if (err) {
> +               printk(KERN_ERR "evdev: unable to register evdev class\n");
> +               return err;
> +       }
> +
>        return input_register_handler(&evdev_handler);
>  }
>
>  static void __exit evdev_exit(void)
>  {
>        input_unregister_handler(&evdev_handler);
> +       class_unregister(&evdev_class);
>  }
>
>  module_init(evdev_init);
> --
> 1.7.1.GIT



-- 
Arve Hjønnevåg

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

[Linus WALLEIJ]

[Arve wrote]
> On Tue, May 25, 2010 at 2:41 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Mon, 17 May 2010, Arve Hjønnevåg wrote:
> >>
> >> How do you know if the work being done while suspending is work that
> >> is needed to suspend or work that should abort suspend?
> >
> > Consider a suspending system in which all "untrusted" processes have been
> > placed into TASK_INTERRUPTIBLE state and have had their timers
> > disabled.[2] The only remaining work to do on the system is work that
> > needs to be done as part of the suspend process, or work that is part of
> > a
> > "trusted" process or the kernel.  If the suspend needs to be aborted due
> > to the arrival of an event, this can be handled as part of the standard
> > suspend process (described below).
> 
> That means modifying all kernel code that would use suspend blockers
> to abort suspend by returning an error from suspend instead. How is
> this better than using suspend blockers?

It will mean that the same API is used for blocking suspend in
regular suspend/resume, runtime PM runtime_suspend/runtime_resume
and now also suspend blockers, right? So only one code path for
drivers that want to support both, no?

That'll be a bit more elegant for drivers that want to support
both runtime PM and suspend blockers I believe.

Overall as a driver writer I'm quite confused at this point, if
I have a driver X, how is that code going to look if it is going
to support both runtime PM *and* suspend blockers? I don't say
it has to support both mechanisms in parallell, I'm even fine
with putting it in #ifdef:s, but how will the source code look?
A real-world example on a simple driver out of the Motorola Droid
git or so would help a lot.

It's quite relevant since e.g. all OMAP drivers will need this
modification to be used with Android-like systems, and at
ST-Ericsson we will need both runtime PM and suspend blockers for
our drivers as well. It will as a consequence affect the drivers
for all ARM reference boards since we use the drivers for ARM
PrimeCells. etc...

Now if this mechanism is going in, my main interest is that there
is some clearly cut way and design pattern for supporting both
runtime PM and suspend blocks.

Yours,
Linus Walleij

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

[Alan Stern]

On Wed, 26 May 2010, Linus WALLEIJ wrote:

> Overall as a driver writer I'm quite confused at this point, if
> I have a driver X, how is that code going to look if it is going
> to support both runtime PM *and* suspend blockers? I don't say
> it has to support both mechanisms in parallell, I'm even fine
> with putting it in #ifdef:s, but how will the source code look?
> A real-world example on a simple driver out of the Motorola Droid
> git or so would help a lot.
> 
> It's quite relevant since e.g. all OMAP drivers will need this
> modification to be used with Android-like systems, and at
> ST-Ericsson we will need both runtime PM and suspend blockers for
> our drivers as well. It will as a consequence affect the drivers
> for all ARM reference boards since we use the drivers for ARM
> PrimeCells. etc...
> 
> Now if this mechanism is going in, my main interest is that there
> is some clearly cut way and design pattern for supporting both
> runtime PM and suspend blocks.

It's not difficult.  You just have to decide what situations should 
block opportunistic suspend.  For example, let's say that opportunistic 
suspend should be blocked when your event queue is non-empty.

Then in the routine that adds new events to the queue, while still
holding the spinlock that protects your queue, you enable your suspend
blocker.  Likewise, in the routine that takes events off the queue and
sends them to userspace, while holding the spinlock you test whether
the queue has become empty; if it has you disable your suspend blocker.

That's all.  No other changes are needed (except to create and destroy 
the suspend blocker, of course).  No other interaction with suspend, 
resume, or runtime PM.

Alan Stern

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

[Pavel Machek]

On Mon 2010-05-24 18:16:15, Arve Hj?nnev?g wrote:
> On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> I agree that the runtime scenario is a far more appealing one from an
> >> aesthetic standpoint, but so far we don't have a very compelling
> >> argument for dealing with the starting and stopping of userspace. The
> >> use-cases that Google have provided are valid and they have an
> >> implementation that addresses them, and while we're unable to provide an
> >> alternative that provides the same level of functionality I think we're
> >> in a poor position to prevent this from going in.
> >
> > Uhuh?
> >
> > "We have this ugly code here, but it works and we don't have better
> > one, so lets merge it"?
> >
> > I don't really like this line of reasoning. I would not want to judge
> > wakelocks here, but... "it works, merge it" should not be used as
> > argument.
> >
> > And btw I do have wakelock-less implementation of autosleep, that only
> > sleeped the machine when nothing was ready to run. It was called
> > "sleepy linux". Should I dig it out?
> >
> > Major difference was that it only sleeped the machine when it was
> > absolutely certain machine is idle and no timers are close to firing
> > -- needing elimination or at least markup of all short timers. It
> > erred on side of not sleeping the machine when it would break
> > something.
> >
> 
> How did you handle external events that occur right after you decided to sleep?

I decided to go to sleep with interrupts disabled... it was prototype
on x86, so it was rather tricky.

I'd expect external events after sleep decision to just wakeup machine
immediately, similar to entering deep CPU sleep mode...
-- 
(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 6)

[Pavel Machek]

On Mon 2010-05-24 18:16:15, Arve Hj?nnev?g wrote:
> On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> I agree that the runtime scenario is a far more appealing one from an
> >> aesthetic standpoint, but so far we don't have a very compelling
> >> argument for dealing with the starting and stopping of userspace. The
> >> use-cases that Google have provided are valid and they have an
> >> implementation that addresses them, and while we're unable to provide an
> >> alternative that provides the same level of functionality I think we're
> >> in a poor position to prevent this from going in.
> >
> > Uhuh?
> >
> > "We have this ugly code here, but it works and we don't have better
> > one, so lets merge it"?
> >
> > I don't really like this line of reasoning. I would not want to judge
> > wakelocks here, but... "it works, merge it" should not be used as
> > argument.
> >
> > And btw I do have wakelock-less implementation of autosleep, that only
> > sleeped the machine when nothing was ready to run. It was called
> > "sleepy linux". Should I dig it out?
> >
> > Major difference was that it only sleeped the machine when it was
> > absolutely certain machine is idle and no timers are close to firing
> > -- needing elimination or at least markup of all short timers. It
> > erred on side of not sleeping the machine when it would break
> > something.
> >
> 
> How did you handle external events that occur right after you decided to sleep?

I decided to go to sleep with interrupts disabled... it was prototype
on x86, so it was rather tricky.

I'd expect external events after sleep decision to just wakeup machine
immediately, similar to entering deep CPU sleep mode...
-- 
(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 6)

[Linus WALLEIJ]

[Alan Stern]
> On Wed, 26 May 2010, Linus WALLEIJ wrote:
> (...)
> > Now if this mechanism is going in, my main interest is that there
> > is some clearly cut way and design pattern for supporting both
> > runtime PM and suspend blocks.
> 
> It's not difficult.  You just have to decide what situations should
> block opportunistic suspend.  For example, let's say that opportunistic
> suspend should be blocked when your event queue is non-empty.
> 
> Then in the routine that adds new events to the queue, while still
> holding the spinlock that protects your queue, you enable your suspend
> blocker.  Likewise, in the routine that takes events off the queue and
> sends them to userspace, while holding the spinlock you test whether
> the queue has become empty; if it has you disable your suspend blocker.
> 
> That's all.  No other changes are needed (except to create and destroy
> the suspend blocker, of course).  No other interaction with suspend,
> resume, or runtime PM.

OK I understand it will be rather OK to do this. For example I have
drivers/spi/amba-pl022.c which is quite clearly taking elements
off a queue and transmitting them.

Currently, as we do not have suspend blockers, we try to stop the
queue in suspend() and if that fails we return something negative
so that the suspend() is blocked by the negative return code.

Maybe the behaviour for an SPI bus should rather be to return
-EBUSY as long as there are events in the queue. I don't quite
know frankly.

(We haven't added runtime PM yet, it will likely be the same
thing.)

With suspend blockers we take a suspend blocker when we add
elements to the queue and release it when the queue is empty.

But with suspend blockers the need for suspend() to check if
the queue can be stopped or return -EBUSY if there are elements
in it is not necessary: suspend() simply won't be called
since a suspend blocker is taken. There is no way for
suspend() to stop a running queue like we do today if using
suspend blockers.

This means that driver writers only targeting configurations
where suspend blockers are used will probably not care about
handling suspend() calls by trying to stop the queue or
checking if there are things in it, because there will never
be anything there.

So while it is easy for me to have the driver work under both
suspend blockers and runtime PM or common suspend(), the
two configurations actually have different semantics of the
suspend() call: in the suspend blockers case you don't need
to check anything, just suspend, and in  the runtime PM
case you have to check that you can actually suspend.

Is this analysis correct?

If yes then OK, it's not totally elegant but if that is
where we have to go, I can live with it. There will likely
be people who implement for only one or the other semantic
behaviour, but we have worse things to cope with already.

Yours,
Linus Walleij

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

[Florian Mickler]

On Thu, 27 May 2010 09:46:51 +0200
Linus WALLEIJ <linus.walleij@stericsson.com> wrote:


> If yes then OK, it's not totally elegant but if that is
> where we have to go, I can live with it. There will likely
> be people who implement for only one or the other semantic
> behaviour, but we have worse things to cope with already.

Alan Cox suggested, that this kind of explicit requirement definition
might be necessary for all drivers anyway in the long run.

That way, the semantic differences between those two cases would
vanish. 

Cheers,
Flo

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

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 12:46 AM, Linus WALLEIJ
<linus.walleij@stericsson.com> wrote:
> [Alan Stern]
>> On Wed, 26 May 2010, Linus WALLEIJ wrote:
>> (...)
>> > Now if this mechanism is going in, my main interest is that there
>> > is some clearly cut way and design pattern for supporting both
>> > runtime PM and suspend blocks.
>>
>> It's not difficult.  You just have to decide what situations should
>> block opportunistic suspend.  For example, let's say that opportunistic
>> suspend should be blocked when your event queue is non-empty.
>>
>> Then in the routine that adds new events to the queue, while still
>> holding the spinlock that protects your queue, you enable your suspend
>> blocker.  Likewise, in the routine that takes events off the queue and
>> sends them to userspace, while holding the spinlock you test whether
>> the queue has become empty; if it has you disable your suspend blocker.
>>
>> That's all.  No other changes are needed (except to create and destroy
>> the suspend blocker, of course).  No other interaction with suspend,
>> resume, or runtime PM.
>
> OK I understand it will be rather OK to do this. For example I have
> drivers/spi/amba-pl022.c which is quite clearly taking elements
> off a queue and transmitting them.
>
> Currently, as we do not have suspend blockers, we try to stop the
> queue in suspend() and if that fails we return something negative
> so that the suspend() is blocked by the negative return code.
>
> Maybe the behaviour for an SPI bus should rather be to return
> -EBUSY as long as there are events in the queue. I don't quite
> know frankly.
>
> (We haven't added runtime PM yet, it will likely be the same
> thing.)
>
> With suspend blockers we take a suspend blocker when we add
> elements to the queue and release it when the queue is empty.
>
> But with suspend blockers the need for suspend() to check if
> the queue can be stopped or return -EBUSY if there are elements
> in it is not necessary: suspend() simply won't be called
> since a suspend blocker is taken. There is no way for
> suspend() to stop a running queue like we do today if using
> suspend blockers.
>
> This means that driver writers only targeting configurations
> where suspend blockers are used will probably not care about
> handling suspend() calls by trying to stop the queue or
> checking if there are things in it, because there will never
> be anything there.
>
> So while it is easy for me to have the driver work under both
> suspend blockers and runtime PM or common suspend(), the
> two configurations actually have different semantics of the
> suspend() call: in the suspend blockers case you don't need
> to check anything, just suspend, and in  the runtime PM
> case you have to check that you can actually suspend.
>
> Is this analysis correct?
>

Mostly, yes. With the current suspend blocker implementation, if you
only start blocking suspend from a user-space thread, or a freezable
kernel thread, then your suspend hook will never be called while you
block suspend unless you use forced suspend. If you for instance start
blocking suspend in response to an interrupt on the other hand, there
is no guarantee that drivers you depend on have not already been
suspended or that they will not suspend after you block suspend, so
you may have to implement a suspend hook to manually abort suspend
even when using suspend blockers. You can add a check if your suspend
blocker is active within your critical section in your suspend hook.
Our alarm driver does this.

> If yes then OK, it's not totally elegant but if that is
> where we have to go, I can live with it. There will likely
> be people who implement for only one or the other semantic
> behaviour, but we have worse things to cope with already.
>

Yes, but you can support both forced suspend and opportunistic suspend
in the same driver. Supporting both is harder if the suspend blocker
api is not in the mainline kernel.

-- 
Arve Hjønnevåg

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

[Alan Stern]

On Thu, 27 May 2010, Linus WALLEIJ wrote:

> OK I understand it will be rather OK to do this. For example I have
> drivers/spi/amba-pl022.c which is quite clearly taking elements
> off a queue and transmitting them.
> 
> Currently, as we do not have suspend blockers, we try to stop the
> queue in suspend() and if that fails we return something negative
> so that the suspend() is blocked by the negative return code.

How can it fail?  Even if the queue can't be stopped immediately, can't
the suspend routine block for a few milliseconds until the queue can be 
stopped?

> Maybe the behaviour for an SPI bus should rather be to return
> -EBUSY as long as there are events in the queue. I don't quite
> know frankly.

No.  It should stop the queue.

Think of it this way: Somebody has just closed the lid of their 
laptop and thrown the computer into a backpack.  You don't want the 
machine to fail to suspend merely because an SPI queue wasn't empty.

> (We haven't added runtime PM yet, it will likely be the same
> thing.)

Runtime PM is very different.  It is supposed to take effect only when 
the device is idle.  So failing if the queue is non-empty makes sense.

> With suspend blockers we take a suspend blocker when we add
> elements to the queue and release it when the queue is empty.
> 
> But with suspend blockers the need for suspend() to check if
> the queue can be stopped or return -EBUSY if there are elements
> in it is not necessary: suspend() simply won't be called
> since a suspend blocker is taken.

No, that's completely wrong.  The user can tell the computer to suspend
at any time, whether or not any suspend blockers are enabled.  Think of
the laptop-in-the-backpack case.

> There is no way for
> suspend() to stop a running queue like we do today if using
> suspend blockers.

I don't know what you mean by this, but it doesn't sound right.

> This means that driver writers only targeting configurations
> where suspend blockers are used will probably not care about
> handling suspend() calls by trying to stop the queue or
> checking if there are things in it, because there will never
> be anything there.

You also have to handle races.  What happens if your suspend routine is 
called, and at that moment an interrupt occurs, causing the driver to 
add an entry to the queue?

You're trying to over-simplify this, probably because you're not 
thinking about it in the right way.  To put it bluntly, suspend 
blockers should not affect with your suspend/resume routines at all.

> So while it is easy for me to have the driver work under both
> suspend blockers and runtime PM or common suspend(), the
> two configurations actually have different semantics of the
> suspend() call: in the suspend blockers case you don't need
> to check anything, just suspend, and in  the runtime PM
> case you have to check that you can actually suspend.

The suspend-blockers case is exactly the same as the normal suspend 
case.  The runtime PM case does require extra checking.

> Is this analysis correct?

No, it's mostly wrong.

Alan Stern

Re: [linux-pm] [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.

[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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[Linus WALLEIJ]

[Alan]
> On Thu, 27 May 2010, Linus WALLEIJ wrote:
> 
> > OK I understand it will be rather OK to do this. For example I have
> > drivers/spi/amba-pl022.c which is quite clearly taking elements
> > off a queue and transmitting them.
> >
> > Currently, as we do not have suspend blockers, we try to stop the
> > queue in suspend() and if that fails we return something negative
> > so that the suspend() is blocked by the negative return code.
> 
> How can it fail?  Even if the queue can't be stopped immediately, can't
> the suspend routine block for a few milliseconds until the queue can be
> stopped?
> 
> > Maybe the behaviour for an SPI bus should rather be to return
> > -EBUSY as long as there are events in the queue. I don't quite
> > know frankly.
> 
> No.  It should stop the queue.
> 
> Think of it this way: Somebody has just closed the lid of their
> laptop and thrown the computer into a backpack.  You don't want the
> machine to fail to suspend merely because an SPI queue wasn't empty.

Not quite! On the other end of that SPI link is our power
regulators. (I'm not making this up, they are really there.) The events
in the queue may be the register writes that actually put the system
to low-power sleep.

But the apropriate action may likely be to wait for this queue to become
empty before returning 0 from suspend().

Yours,
Linus Walleij

Re: [linux-pm] [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.

[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: [linux-pm] [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.

[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 0/8] Suspend block api (version 6)

[tytso]

On Mon, May 17, 2010 at 09:12:03AM -0700, Kevin Hilman wrote:
> 
> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
> 
> I don't know of any more objective comparison of the two, but as a
> user of both devices I can say that the active usage is basically the
> same (around a day) and the idle use is similar as well, even though
> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)....

Just for a bit of light amusement, although hopefully we've killed the
meme that other platforms have absolutely no problems in this area
without using something like suspend blockers, I offer for your
consideration this thread from maemo-developers:

http://lists.maemo.org/pipermail/maemo-developers/2010-May/026490.html

Note how users conflate battery lifetime after downloading a random
application with the platform being "stable".  I also was amazed that
the thread degenerated into trying to detect processes that are taking
90% of the CPU.  It's not necessary for a process to be constantly
running before it starts chewing up your battery, and if people think
the "blame the victim" trick works (``It's the user's fault for
"approving" the application by installing it!''), I suspect that
the platform will be not be very successful...

							- Ted

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

[Igor Stoppa]

ext tytso@mit.edu wrote:

> On Mon, May 17, 2010 at 09:12:03AM -0700, Kevin Hilman wrote:
>   
>> The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
>> The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)
>>
>> I don't know of any more objective comparison of the two, but as a
>> user of both devices I can say that the active usage is basically the
>> same (around a day) and the idle use is similar as well, even though
>> the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)....
>>     
>
> Just for a bit of light amusement, although hopefully we've killed the
> meme that other platforms have absolutely no problems in this area
> without using something like suspend blockers,

If you are advocating QoS, I think it's a general agreement that 
something like that is needed.

If you are saying that suspend blockers - or the like - are needed, no, 
that is not true.
>  I offer for your
> consideration this thread from maemo-developers:
>
> http://lists.maemo.org/pipermail/maemo-developers/2010-May/026490.html
>
> Note how users conflate battery lifetime after downloading a random
> application with the platform being "stable".  I also was amazed that
> the thread degenerated into trying to detect processes that are taking
> 90% of the CPU.  It's not necessary for a process to be constantly
> running before it starts chewing up your battery, and if people think
> the "blame the victim" trick works (``It's the user's fault for
> "approving" the application by installing it!''), I suspect that
> the platform will be not be very successful...
>   
 From the thread - if i have not missed it - the user doesn't say if 
this is a newly flashed device or if he has done an upgrade of something 
he used to hack with. Erroneous settings might be an explanation there ...

Yes, I am blaming the victim, mostly out of previous experience in 
similar cases.

 From a platform pov I think this mostly proves the need to embed more 
self diagnostic in the system and have QoS.

igor

[PATCH 0/8] Suspend block api (version 6)

[Arve Hjønnevåg]

This patch series adds a suspend-block api that provides the same
functionality as the android wakelock api. This version fixes a race
in suspend blocking work, has some documentation changes and
opportunistic suspend now uses the same workqueue as runtime pm.

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

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