Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

2,230 views
Skip to first unread message

Arve Hjønnevåg

unread,
Apr 30, 2010, 6:40:02 PM4/30/10
to
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 <ar...@android.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Arve Hjønnevåg

unread,
Apr 30, 2010, 6:40:02 PM4/30/10
to
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 <ar...@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

Pavel Machek

unread,
May 2, 2010, 3:00:01 AM5/2/10
to
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 <ar...@android.com>

NAK.

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

Pavel Machek

unread,
May 2, 2010, 3:10:02 AM5/2/10
to
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 <ar...@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 :-(.

--

Rafael J. Wysocki

unread,
May 2, 2010, 4:20:01 PM5/2/10
to
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 <ar...@android.com>
>
> NAK.

Ignored.

Thanks,
Rafael

Pavel Machek

unread,
May 2, 2010, 5:00:02 PM5/2/10
to
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 <ar...@android.com>
> >
> > NAK.
>
> Ignored.

WTF?
Pavel

Rafael J. Wysocki

unread,
May 2, 2010, 5:30:01 PM5/2/10
to
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 <ar...@android.com>
> > >
> > > NAK.
> >
> > Ignored.
>
> WTF?

Literally. I'm not going to take that NAK into consideration.

Rafael

Kevin Hilman

unread,
May 3, 2010, 12:50:02 PM5/3/10
to
Arve Hj�nnev�g <ar...@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

Alan Stern

unread,
May 3, 2010, 1:20:02 PM5/3/10
to
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

Mark Brown

unread,
May 3, 2010, 2:10:03 PM5/3/10
to
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.

Kevin Hilman

unread,
May 3, 2010, 2:20:03 PM5/3/10
to
Alan Stern <st...@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

Pavel Machek

unread,
May 3, 2010, 3:10:02 PM5/3/10
to
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

Rafael J. Wysocki

unread,
May 3, 2010, 5:20:02 PM5/3/10
to

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

Rafael J. Wysocki

unread,
May 3, 2010, 5:40:02 PM5/3/10
to

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

Matthew Garrett

unread,
May 3, 2010, 6:00:02 PM5/3/10
to
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 | mj...@srcf.ucam.org

Alan Stern

unread,
May 3, 2010, 6:20:01 PM5/3/10
to
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

Arve Hjønnevåg

unread,
May 3, 2010, 6:30:02 PM5/3/10
to
On Mon, May 3, 2010 at 3:11 PM, Alan Stern <st...@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

Kevin Hilman

unread,
May 3, 2010, 7:40:02 PM5/3/10
to

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

Arve Hjønnevåg

unread,
May 3, 2010, 8:10:02 PM5/3/10
to

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

Matthew Garrett

unread,
May 3, 2010, 8:50:01 PM5/3/10
to
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 | mj...@srcf.ucam.org

Brian Swetland

unread,
May 3, 2010, 8:50:01 PM5/3/10
to
On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <ar...@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

mark gross

unread,
May 4, 2010, 1:20:01 AM5/4/10
to
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 <ar...@android.com>

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

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

Alan Stern

unread,
May 4, 2010, 10:00:02 AM5/4/10
to
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

Mark Brown

unread,
May 4, 2010, 10:00:02 AM5/4/10
to
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 <ar...@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.

Alan Stern

unread,
May 4, 2010, 10:10:02 AM5/4/10
to
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

Mark Brown

unread,
May 4, 2010, 11:00:02 AM5/4/10
to
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.

Kevin Hilman

unread,
May 4, 2010, 11:20:01 AM5/4/10
to
Alan Stern <st...@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

Kevin Hilman

unread,
May 4, 2010, 11:20:01 AM5/4/10
to
Matthew Garrett <m...@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

Matthew Garrett

unread,
May 4, 2010, 11:30:01 AM5/4/10
to
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 | mj...@srcf.ucam.org

Matthew Garrett

unread,
May 4, 2010, 11:30:02 AM5/4/10
to
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 | mj...@srcf.ucam.org

mark gross

unread,
May 4, 2010, 12:10:02 PM5/4/10
to
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

Alan Stern

unread,
May 4, 2010, 1:20:01 PM5/4/10
to

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

Kevin Hilman

unread,
May 4, 2010, 2:10:03 PM5/4/10
to
Arve Hj�nnev�g <ar...@android.com> writes:

> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
> <khi...@deeprootsystems.com> wrote:
>> "Rafael J. Wysocki" <r...@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

Kevin Hilman

unread,
May 4, 2010, 2:10:03 PM5/4/10
to
Mark Brown <bro...@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 <ar...@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

Mark Brown

unread,
May 4, 2010, 3:10:02 PM5/4/10
to
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.

Rafael J. Wysocki

unread,
May 4, 2010, 4:30:03 PM5/4/10
to
On Tuesday 04 May 2010, Kevin Hilman wrote:
> Mark Brown <bro...@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 <ar...@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

Rafael J. Wysocki

unread,
May 4, 2010, 4:40:03 PM5/4/10
to
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

Rafael J. Wysocki

unread,
May 4, 2010, 4:50:02 PM5/4/10
to

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

Arve Hjønnevåg

unread,
May 4, 2010, 4:50:01 PM5/4/10
to
2010/5/3 mark gross <640e...@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

Kevin Hilman

unread,
May 4, 2010, 7:30:01 PM5/4/10
to
"Rafael J. Wysocki" <r...@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

Rafael J. Wysocki

unread,
May 4, 2010, 7:50:02 PM5/4/10
to

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

Mark Brown

unread,
May 4, 2010, 8:00:01 PM5/4/10
to
On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 04 May 2010, Kevin Hilman wrote:
> > Mark Brown <bro...@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.

Rafael J. Wysocki

unread,
May 4, 2010, 8:30:01 PM5/4/10
to
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 <bro...@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

Brian Swetland

unread,
May 4, 2010, 9:20:01 PM5/4/10
to
On Tue, May 4, 2010 at 5:22 PM, Rafael J. Wysocki <r...@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

mark gross

unread,
May 4, 2010, 10:00:01 PM5/4/10
to
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.

ok.

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

--mgross

Mark Brown

unread,
May 5, 2010, 7:10:02 AM5/5/10
to
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.

Brian Swetland

unread,
May 5, 2010, 8:10:01 AM5/5/10
to
On Wed, May 5, 2010 at 4:06 AM, Mark Brown
<bro...@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

Matthew Garrett

unread,
May 5, 2010, 9:40:02 AM5/5/10
to
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 | mj...@srcf.ucam.org

Mark Brown

unread,
May 5, 2010, 10:00:03 AM5/5/10
to
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.

Alan Stern

unread,
May 5, 2010, 11:40:03 AM5/5/10
to
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

Alan Stern

unread,
May 5, 2010, 11:50:02 AM5/5/10
to
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

Mark Brown

unread,
May 5, 2010, 12:30:01 PM5/5/10
to
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.

Matthew Garrett

unread,
May 5, 2010, 1:40:02 PM5/5/10
to
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 | mj...@srcf.ucam.org

Alan Stern

unread,
May 5, 2010, 2:40:02 PM5/5/10
to
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

Mark Brown

unread,
May 5, 2010, 2:50:02 PM5/5/10
to
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.

Matthew Garrett

unread,
May 5, 2010, 3:00:02 PM5/5/10
to
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 | mj...@srcf.ucam.org

Mark Brown

unread,
May 5, 2010, 3:10:03 PM5/5/10
to
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.

Alan Stern

unread,
May 5, 2010, 3:20:02 PM5/5/10
to
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

Matthew Garrett

unread,
May 5, 2010, 3:30:02 PM5/5/10
to
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 | mj...@srcf.ucam.org

Alan Stern

unread,
May 5, 2010, 3:30:02 PM5/5/10
to
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

Matthew Garrett

unread,
May 5, 2010, 3:30:01 PM5/5/10
to
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 | mj...@srcf.ucam.org

Mark Brown

unread,
May 5, 2010, 3:50:02 PM5/5/10
to
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.

Mark Brown

unread,
May 5, 2010, 4:00:02 PM5/5/10
to
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.

ty...@mit.edu

unread,
May 5, 2010, 4:00:01 PM5/5/10
to
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

Alan Stern

unread,
May 5, 2010, 4:10:02 PM5/5/10
to
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?

Matthew Garrett

unread,
May 5, 2010, 4:10:03 PM5/5/10
to
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 | mj...@srcf.ucam.org

mark gross

unread,
May 5, 2010, 4:10:02 PM5/5/10
to
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.

Mark Brown

unread,
May 5, 2010, 4:20:02 PM5/5/10
to
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.

Mark Brown

unread,
May 5, 2010, 4:20:01 PM5/5/10
to
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.

Mark Brown

unread,
May 5, 2010, 4:30:02 PM5/5/10
to
On Wed, May 05, 2010 at 03:55:34PM -0400, ty...@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.

mark gross

unread,
May 5, 2010, 4:30:02 PM5/5/10
to
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

Rafael J. Wysocki

unread,
May 5, 2010, 4:30:02 PM5/5/10
to

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

Matthew Garrett

unread,
May 5, 2010, 4:30:02 PM5/5/10
to
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 | mj...@srcf.ucam.org

mark gross

unread,
May 5, 2010, 4:40:01 PM5/5/10
to
On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> Arve Hj�nnev�g <ar...@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

Rafael J. Wysocki

unread,
May 5, 2010, 4:50:02 PM5/5/10
to

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

Brian Swetland

unread,
May 5, 2010, 5:00:02 PM5/5/10
to
On Wed, May 5, 2010 at 12:13 PM, Alan Stern <st...@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

Alan Stern

unread,
May 5, 2010, 5:20:01 PM5/5/10
to
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

Brian Swetland

unread,
May 5, 2010, 5:40:01 PM5/5/10
to
On Wed, May 5, 2010 at 2:12 PM, Alan Stern <st...@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

Mark Brown

unread,
May 5, 2010, 6:00:02 PM5/5/10
to
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.

Brian Swetland

unread,
May 5, 2010, 6:10:02 PM5/5/10
to
On Wed, May 5, 2010 at 2:57 PM, Mark Brown
<bro...@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

Rafael J. Wysocki

unread,
May 5, 2010, 6:10:02 PM5/5/10
to
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

Mark Brown

unread,
May 5, 2010, 7:10:02 PM5/5/10
to
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.

Kevin Hilman

unread,
May 5, 2010, 7:10:02 PM5/5/10
to
Alan Stern <st...@rowland.harvard.edu> writes:

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

Rafael J. Wysocki

unread,
May 5, 2010, 7:20:01 PM5/5/10
to

That sounds reasonable although it may be a challenge to find a set of
universal constraints common to all devices.

Rafael

Rafael J. Wysocki

unread,
May 5, 2010, 7:40:02 PM5/5/10
to
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

Mark Brown

unread,
May 5, 2010, 7:50:02 PM5/5/10
to
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.

Tony Lindgren

unread,
May 5, 2010, 7:50:01 PM5/5/10
to
* Brian Swetland <swet...@google.com> [100505 14:34]:

> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <st...@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

Brian Swetland

unread,
May 5, 2010, 7:50:02 PM5/5/10
to
On Wed, May 5, 2010 at 4:03 PM, Kevin Hilman
<khi...@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

Brian Swetland

unread,
May 5, 2010, 8:00:03 PM5/5/10
to
On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <to...@atomide.com> wrote:
> * Brian Swetland <swet...@google.com> [100505 14:34]:
>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <st...@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

Tony Lindgren

unread,
May 5, 2010, 8:10:03 PM5/5/10
to
* Brian Swetland <swet...@google.com> [100505 16:51]:

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

Mark Brown

unread,
May 5, 2010, 8:30:01 PM5/5/10
to
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?

Rafael J. Wysocki

unread,
May 5, 2010, 9:00:01 PM5/5/10
to

I agree that this appears to be the best approach for the time being, although
I can only speak for myself.

Rafael

Magnus Damm

unread,
May 5, 2010, 9:50:01 PM5/5/10
to
On Wed, May 5, 2010 at 12:27 AM, Matthew Garrett <m...@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

Arve Hjønnevåg

unread,
May 6, 2010, 12:20:02 AM5/6/10
to

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

Arve Hjønnevåg

unread,
May 6, 2010, 12:30:01 AM5/6/10
to
On Wed, May 5, 2010 at 4:40 PM, Mark Brown
<bro...@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

Matthew Garrett

unread,
May 6, 2010, 9:50:02 AM5/6/10
to
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 | mj...@srcf.ucam.org

Alan Stern

unread,
May 6, 2010, 10:10:02 AM5/6/10
to
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

Tony Lindgren

unread,
May 6, 2010, 1:10:01 PM5/6/10
to
* Matthew Garrett <m...@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

Tony Lindgren

unread,
May 6, 2010, 1:10:02 PM5/6/10
to
* Arve Hjønnevåg <ar...@android.com> [100505 21:11]:

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

Matthew Garrett

unread,
May 6, 2010, 1:20:01 PM5/6/10
to
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 | mj...@srcf.ucam.org

It is loading more messages.
0 new messages