Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1220389 > unrolled thread

[RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Irina Tirdea <irina.tirdea@intel.com> - 2015-09-07 22:50 +0200
    Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-07 23:00 +0200
      RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend "Tirdea, Irina" <irina.tirdea@intel.com> - 2015-09-08 03:20 +0200
        Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Oliver Neukum <oneukum@suse.com> - 2015-09-08 09:40 +0200
          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-08 23:00 +0200
            Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Ulf Hansson <ulf.hansson@linaro.org> - 2015-09-09 00:30 +0200
              Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-09 02:00 +0200
                Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Octavian Purdila <octavian.purdila@intel.com> - 2015-09-09 13:20 +0200
                  Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-09 14:30 +0200
                    Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Oliver Neukum <oneukum@suse.com> - 2015-09-09 16:00 +0200
                      Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Octavian Purdila <octavian.purdila@intel.com> - 2015-09-09 17:10 +0200
                        Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-09 22:00 +0200
                          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Oliver Neukum <oneukum@suse.com> - 2015-09-10 11:50 +0200
                          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Pavel Machek <pavel@ucw.cz> - 2015-09-21 14:30 +0200
                    Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-09 17:30 +0200
                      Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-09 22:10 +0200
                        Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Colin Cross <ccross@google.com> - 2015-09-09 22:20 +0200
                      Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Pavel Machek <pavel@ucw.cz> - 2015-09-21 14:40 +0200
                        Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-21 16:40 +0200
                          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-09-21 18:20 +0200
                            Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-21 18:40 +0200
                              Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-09-21 19:00 +0200
                                Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-21 19:40 +0200
                                  Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-09-21 20:10 +0200
                                    Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-21 22:10 +0200
                                      Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-09-21 23:00 +0200
                          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Pavel Machek <pavel@ucw.cz> - 2015-09-21 22:30 +0200
        RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-08 16:50 +0200
          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-08 16:50 +0200
            Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-08 17:10 +0200
              Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-08 22:30 +0200
                Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-09 17:30 +0200
          Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Oliver Neukum <oneukum@suse.com> - 2015-09-09 08:30 +0200
            Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing  runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-09 16:40 +0200

Page 1 of 2  [1] 2  Next page →

#1220389 — [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

Add new option to sysfs control interface, allowing the user to force
suspend the device. This is useful for devices that need to be
suspended when closing the lid of a laptop or the screen of a mobile
device, while userspace still holds open handles to it and the
system does not enter system suspend.

Add the "off" option to the sysfs control power interface, along with
the already present "on" and "auto". When this attribute is set to
"off", the device will be force suspended by calling its runtime
suspend callback and disabling runtime power management so that
further acceses to the device will not change the actual state.
The device can be resumed by setting the attribute to "on" or "auto".
The behaviour of the interface when switching only between "on"
and "auto" states remains unchanged.

Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
---

Hi,

This is a proposal for suspending devices when the closing the lid of
a laptop or the screen of a mobile device.

I am testing this with a Goodix touchscreen [1] for an Android mobile
device. Android has an userspace layer (power HAL) that would normally
close the touchscreen when the screen is closed. Android touchscreen
drivers usually provide a custom sysfs interface to allow this.
This would be better implemented in a common place, to avoid code
duplication and to simplify the driver code (as previosly discussed
in [1]).

I know there are more ways to implement this, so I would appreciate
your feedback.

Thank you,
Irina

[1] https://lkml.org/lkml/2015/9/7/329
[2] https://lkml.org/lkml/2014/7/15/928

 drivers/base/power/main.c    |   8 +++
 drivers/base/power/runtime.c | 141 ++++++++++++++++++++++++++++++++++++-------
 drivers/base/power/sysfs.c   |  22 ++++---
 drivers/usb/core/sysfs.c     |   3 +-
 include/linux/pm.h           |   8 ++-
 include/linux/pm_runtime.h   |  18 +++++-
 include/trace/events/rpm.h   |   6 +-
 7 files changed, 169 insertions(+), 37 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 9717d5f..e497c38 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -927,6 +927,9 @@ static void device_complete(struct device *dev, pm_message_t state)
 
 	device_unlock(dev);
 
+	if (dev->power.runtime_mode == RPM_MODE_OFF)
+		pm_runtime_force_suspend(dev);
+
 	pm_runtime_put(dev);
 }
 
@@ -1596,6 +1599,11 @@ static int device_prepare(struct device *dev, pm_message_t state)
 	spin_lock_irq(&dev->power.lock);
 	dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND;
 	spin_unlock_irq(&dev->power.lock);
+
+	if (!dev->power.direct_complete &&
+	    dev->power.runtime_mode == RPM_MODE_OFF)
+		pm_runtime_enable(dev);
+
 	return 0;
 }
 
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 5070c4f..0d94b8c 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1189,49 +1189,144 @@ void pm_runtime_enable(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(pm_runtime_enable);
 
+static int dev_pm_mode_on(struct device *dev, void *data)
+{
+	return dev->power.runtime_mode != RPM_MODE_OFF;
+}
+
 /**
- * pm_runtime_forbid - Block runtime PM of a device.
+ * pm_runtime_force_off - Block runtime PM of a device and keep it suspended.
  * @dev: Device to handle.
  *
- * Increase the device's usage count and clear its power.runtime_auto flag,
- * so that it cannot be suspended at run time until pm_runtime_allow() is called
- * for it.
+ * Change the device's power.runtime_mode field to RPM_MODE_OFF and
+ * force runtime suspend (by running the device's runtime suspend
+ * and disabling runtime power management), so that it cannot be
+ * resumed at run time until pm_runtime_force_on() or
+ * pm_runtime_force_auto() is called for it.
  */
-void pm_runtime_forbid(struct device *dev)
+int pm_runtime_force_off(struct device *dev)
 {
+	int mode, ret;
+
 	spin_lock_irq(&dev->power.lock);
-	if (!dev->power.runtime_auto)
-		goto out;
+	mode = dev->power.runtime_mode;
+	if (mode == RPM_MODE_OFF) {
+		spin_unlock_irq(&dev->power.lock);
+		return 0;
+	}
 
-	dev->power.runtime_auto = false;
-	atomic_inc(&dev->power.usage_count);
-	rpm_resume(dev, 0);
+	/* Cannot force suspend if runtime pm is disabled */
+	if (!pm_runtime_enabled(dev)) {
+		spin_unlock_irq(&dev->power.lock);
+		return -EACCES;
+	}
 
- out:
+	/*
+	 * Cannot force suspend if children are on/auto and
+	 * device ignore_children flag is not set.
+	 */
+	if (!dev->power.ignore_children &&
+	    device_for_each_child(dev, NULL, dev_pm_mode_on)) {
+		spin_unlock_irq(&dev->power.lock);
+		return -EBUSY;
+	}
+
+	dev->power.runtime_mode = RPM_MODE_OFF;
+	if (mode == RPM_MODE_ON)
+		atomic_dec(&dev->power.usage_count);
 	spin_unlock_irq(&dev->power.lock);
+
+	ret = pm_runtime_force_suspend(dev);
+	if (ret) {
+		spin_lock_irq(&dev->power.lock);
+		dev->power.runtime_mode = mode;
+		if (mode == RPM_MODE_ON)
+			atomic_inc(&dev->power.usage_count);
+		spin_unlock_irq(&dev->power.lock);
+		return ret;
+	}
+
+	return 0;
 }
-EXPORT_SYMBOL_GPL(pm_runtime_forbid);
+EXPORT_SYMBOL_GPL(pm_runtime_force_off);
 
 /**
- * pm_runtime_allow - Unblock runtime PM of a device.
+ * pm_runtime_force_on - Block runtime PM of a device and keep it resumed.
  * @dev: Device to handle.
  *
- * Decrease the device's usage count and set its power.runtime_auto flag.
+ * Increase the device's usage count and set its power.runtime_mode field,
+ * to RPM_MODE_ON, so that it cannot be suspended at run time until
+ * pm_runtime_force_auto() is called for it.
  */
-void pm_runtime_allow(struct device *dev)
+int pm_runtime_force_on(struct device *dev)
 {
+	int mode;
+
 	spin_lock_irq(&dev->power.lock);
-	if (dev->power.runtime_auto)
-		goto out;
+	mode = dev->power.runtime_mode;
+	if (mode == RPM_MODE_ON) {
+		spin_unlock_irq(&dev->power.lock);
+		return 0;
+	}
 
-	dev->power.runtime_auto = true;
-	if (atomic_dec_and_test(&dev->power.usage_count))
-		rpm_idle(dev, RPM_AUTO);
+	/* Cannot resume if parent is force suspended. */
+	if (dev->parent && dev->parent->power.runtime_mode == RPM_MODE_OFF) {
+		spin_unlock_irq(&dev->power.lock);
+		return -EBUSY;
+	}
 
- out:
+	dev->power.runtime_mode = RPM_MODE_ON;
+	spin_unlock_irq(&dev->power.lock);
+
+	if (mode == RPM_MODE_OFF)
+		pm_runtime_enable(dev);
+
+	__pm_runtime_resume(dev, RPM_GET_PUT);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pm_runtime_force_on);
+
+/**
+ * pm_runtime_force_auto - Unblock runtime PM of a device.
+ * @dev: Device to handle.
+ *
+ * Set the device's power.runtime_mode field to RPM_MODE_AUTO.
+ * If previous state was suspended, enable runtime power
+ * management and resume. If previous state was resumed,
+ * decrease the device's usage count.
+ */
+int pm_runtime_force_auto(struct device *dev)
+{
+	int mode, flags = 0;
+
+	spin_lock_irq(&dev->power.lock);
+	mode = dev->power.runtime_mode;
+	if (mode == RPM_MODE_AUTO) {
+		spin_unlock_irq(&dev->power.lock);
+		return 0;
+	}
+
+	/* Cannot resume if both device and its parent are force suspended */
+	if (mode == RPM_MODE_OFF && dev->parent &&
+	    dev->parent->power.runtime_mode == RPM_MODE_OFF) {
+		spin_unlock_irq(&dev->power.lock);
+		return -EBUSY;
+	}
+
+	dev->power.runtime_mode = RPM_MODE_AUTO;
 	spin_unlock_irq(&dev->power.lock);
+
+	if (mode == RPM_MODE_OFF) {
+		pm_runtime_enable(dev);
+		__pm_runtime_resume(dev, 0);
+	} else if (mode == RPM_MODE_ON) {
+		flags = RPM_GET_PUT;
+	}
+
+	__pm_runtime_idle(dev, RPM_AUTO | flags);
+	return 0;
 }
-EXPORT_SYMBOL_GPL(pm_runtime_allow);
+EXPORT_SYMBOL_GPL(pm_runtime_force_auto);
 
 /**
  * pm_runtime_no_callbacks - Ignore runtime PM callbacks for a device.
@@ -1368,7 +1463,7 @@ void pm_runtime_init(struct device *dev)
 
 	atomic_set(&dev->power.child_count, 0);
 	pm_suspend_ignore_children(dev, false);
-	dev->power.runtime_auto = true;
+	dev->power.runtime_mode = RPM_MODE_AUTO;
 
 	dev->power.request_pending = false;
 	dev->power.request = RPM_REQ_NONE;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d2be3f9..db0630a 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -97,31 +97,38 @@ EXPORT_SYMBOL_GPL(power_group_name);
 
 static const char ctrl_auto[] = "auto";
 static const char ctrl_on[] = "on";
+static const char ctrl_off[] = "off";
 
 static ssize_t control_show(struct device *dev, struct device_attribute *attr,
 			    char *buf)
 {
 	return sprintf(buf, "%s\n",
-				dev->power.runtime_auto ? ctrl_auto : ctrl_on);
+		       dev->power.runtime_mode == RPM_MODE_AUTO ? ctrl_auto :
+		       dev->power.runtime_mode == RPM_MODE_ON ? ctrl_on :
+		       ctrl_off);
 }
 
 static ssize_t control_store(struct device * dev, struct device_attribute *attr,
 			     const char * buf, size_t n)
 {
 	char *cp;
-	int len = n;
+	int len = n, ret = 0;
 
 	cp = memchr(buf, '\n', n);
 	if (cp)
 		len = cp - buf;
 	device_lock(dev);
 	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
-		pm_runtime_allow(dev);
+		ret = pm_runtime_force_auto(dev);
 	else if (len == sizeof ctrl_on - 1 && strncmp(buf, ctrl_on, len) == 0)
-		pm_runtime_forbid(dev);
+		ret = pm_runtime_force_on(dev);
+	else if (len == sizeof ctrl_off - 1 && strncmp(buf, ctrl_off, len) == 0)
+		ret = pm_runtime_force_off(dev);
 	else
-		n = -EINVAL;
+		ret = -EINVAL;
 	device_unlock(dev);
+	if (ret)
+		return ret;
 	return n;
 }
 
@@ -545,11 +552,12 @@ static ssize_t rtpm_children_show(struct device *dev,
 static ssize_t rtpm_enabled_show(struct device *dev,
 				 struct device_attribute *attr, char *buf)
 {
-	if ((dev->power.disable_depth) && (dev->power.runtime_auto == false))
+	if ((dev->power.disable_depth) &&
+	    (dev->power.runtime_mode != RPM_MODE_AUTO))
 		return sprintf(buf, "disabled & forbidden\n");
 	else if (dev->power.disable_depth)
 		return sprintf(buf, "disabled\n");
-	else if (dev->power.runtime_auto == false)
+	else if (dev->power.runtime_mode != RPM_MODE_AUTO)
 		return sprintf(buf, "forbidden\n");
 	return sprintf(buf, "enabled\n");
 }
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index d269738..8165102 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -408,7 +408,8 @@ static ssize_t level_show(struct device *dev, struct device_attribute *attr,
 	const char *p = auto_string;
 
 	warn_level();
-	if (udev->state != USB_STATE_SUSPENDED && !udev->dev.power.runtime_auto)
+	if (udev->state != USB_STATE_SUSPENDED &&
+	    udev->dev.power.runtime_mode != RPM_MODE_AUTO)
 		p = on_string;
 	return sprintf(buf, "%s\n", p);
 }
diff --git a/include/linux/pm.h b/include/linux/pm.h
index e2f1be6..69273d4 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -542,6 +542,12 @@ struct pm_subsys_data {
 #endif
 };
 
+enum rpm_mode {
+	RPM_MODE_AUTO = 0,
+	RPM_MODE_ON,
+	RPM_MODE_OFF,
+};
+
 struct dev_pm_info {
 	pm_message_t		power_state;
 	unsigned int		can_wakeup:1;
@@ -575,12 +581,12 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
-	unsigned int		runtime_auto:1;
 	unsigned int		no_callbacks:1;
 	unsigned int		irq_safe:1;
 	unsigned int		use_autosuspend:1;
 	unsigned int		timer_autosuspends:1;
 	unsigned int		memalloc_noio:1;
+	enum rpm_mode		runtime_mode;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 30e84d4..186e9f0 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -44,8 +44,9 @@ extern int __pm_runtime_set_status(struct device *dev, unsigned int status);
 extern int pm_runtime_barrier(struct device *dev);
 extern void pm_runtime_enable(struct device *dev);
 extern void __pm_runtime_disable(struct device *dev, bool check_resume);
-extern void pm_runtime_allow(struct device *dev);
-extern void pm_runtime_forbid(struct device *dev);
+extern int pm_runtime_force_off(struct device *dev);
+extern int pm_runtime_force_on(struct device *dev);
+extern int pm_runtime_force_auto(struct device *dev);
 extern void pm_runtime_no_callbacks(struct device *dev);
 extern void pm_runtime_irq_safe(struct device *dev);
 extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
@@ -55,6 +56,16 @@ extern void pm_runtime_update_max_time_suspended(struct device *dev,
 						 s64 delta_ns);
 extern void pm_runtime_set_memalloc_noio(struct device *dev, bool enable);
 
+static inline void pm_runtime_allow(struct device *dev)
+{
+	pm_runtime_force_auto(dev);
+}
+
+static inline void pm_runtime_forbid(struct device *dev)
+{
+	pm_runtime_force_on(dev);
+}
+
 static inline bool pm_children_suspended(struct device *dev)
 {
 	return dev->power.ignore_children
@@ -155,6 +166,9 @@ static inline void pm_runtime_enable(struct device *dev) {}
 static inline void __pm_runtime_disable(struct device *dev, bool c) {}
 static inline void pm_runtime_allow(struct device *dev) {}
 static inline void pm_runtime_forbid(struct device *dev) {}
+static inline int pm_runtime_force_off(struct device *dev) { return 0; }
+static inline int pm_runtime_force_on(struct device *dev) { return 0; }
+static inline int pm_runtime_force_auto(struct device *dev) { return 0; }
 
 static inline bool pm_children_suspended(struct device *dev) { return false; }
 static inline void pm_runtime_get_noresume(struct device *dev) {}
diff --git a/include/trace/events/rpm.h b/include/trace/events/rpm.h
index 33f85b6..ab9cc18 100644
--- a/include/trace/events/rpm.h
+++ b/include/trace/events/rpm.h
@@ -25,7 +25,7 @@ DECLARE_EVENT_CLASS(rpm_internal,
 		__field(        int,            flags           )
 		__field(        int ,   	usage_count	)
 		__field(        int ,   	disable_depth   )
-		__field(        int ,   	runtime_auto	)
+		__field(        int ,   	runtime_mode	)
 		__field(        int ,   	request_pending	)
 		__field(        int ,   	irq_safe	)
 		__field(        int ,   	child_count 	)
@@ -37,7 +37,7 @@ DECLARE_EVENT_CLASS(rpm_internal,
 		__entry->usage_count = atomic_read(
 			&dev->power.usage_count);
 		__entry->disable_depth = dev->power.disable_depth;
-		__entry->runtime_auto = dev->power.runtime_auto;
+		__entry->runtime_mode = dev->power.runtime_mode;
 		__entry->request_pending = dev->power.request_pending;
 		__entry->irq_safe = dev->power.irq_safe;
 		__entry->child_count = atomic_read(
@@ -49,7 +49,7 @@ DECLARE_EVENT_CLASS(rpm_internal,
 			__get_str(name), __entry->flags,
 			__entry->usage_count,
 			__entry->disable_depth,
-			__entry->runtime_auto,
+			__entry->runtime_mode,
 			__entry->request_pending,
 			__entry->irq_safe,
 			__entry->child_count
-- 
1.9.1

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

[toc] | [next] | [standalone]

#1220393

On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote:
> Add new option to sysfs control interface, allowing the user to force
> suspend the device.

Had we thought this had been a good idea, we'd have added that thing to
the interface from the start.

The problem with it is that user space generally doesn't know when it is
safe to suspend a device, so it cannot force anything into runtime suspend.

> This is useful for devices that need to be
> suspended when closing the lid of a laptop or the screen of a mobile
> device, while userspace still holds open handles to it and the
> system does not enter system suspend.
> 
> Add the "off" option to the sysfs control power interface, along with
> the already present "on" and "auto". When this attribute is set to
> "off", the device will be force suspended by calling its runtime
> suspend callback and disabling runtime power management so that
> further acceses to the device will not change the actual state.

And how is user space supposed to know that it doesn't break things
this way?

> The device can be resumed by setting the attribute to "on" or "auto".
> The behaviour of the interface when switching only between "on"
> and "auto" states remains unchanged.
> 
> Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
> ---
> 
> Hi,
> 
> This is a proposal for suspending devices when the closing the lid of
> a laptop or the screen of a mobile device.
> 
> I am testing this with a Goodix touchscreen [1] for an Android mobile
> device. Android has an userspace layer (power HAL) that would normally
> close the touchscreen when the screen is closed. Android touchscreen
> drivers usually provide a custom sysfs interface to allow this.
> This would be better implemented in a common place, to avoid code
> duplication and to simplify the driver code (as previosly discussed
> in [1]).
> 
> I know there are more ways to implement this, so I would appreciate
> your feedback.

So the feedback is that this is not going to work in general.  Please
use a different approach.

Thanks,
Rafael

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

[toc] | [prev] | [next] | [standalone]

#1220438 — RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgtaW5wdXQtb3du
ZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtaW5wdXQtb3duZXJAdmdlci5rZXJuZWwu
b3JnXSBPbiBCZWhhbGYgT2YgUmFmYWVsIEouIFd5c29ja2kNCj4gU2VudDogMDggU2VwdGVtYmVy
LCAyMDE1IDA6MjANCj4gVG86IFRpcmRlYSwgSXJpbmENCj4gQ2M6IEFsYW4gU3Rlcm47IGxpbnV4
LXBtQHZnZXIua2VybmVsLm9yZzsgbGludXgtaW5wdXRAdmdlci5rZXJuZWwub3JnOyBsaW51eC1r
ZXJuZWxAdmdlci5rZXJuZWwub3JnOyBCcm93biwgTGVuOyBQYXZlbCBNYWNoZWs7DQo+IFB1cmRp
bGEsIE9jdGF2aWFuOyBEbWl0cnkgVG9yb2tob3YNCj4gU3ViamVjdDogUmU6IFtSRkMgUEFUQ0hd
IFBNIC8gUnVudGltZTogcnVudGltZTogQWRkIHN5c2ZzIG9wdGlvbiBmb3IgZm9yY2luZyBydW50
aW1lIHN1c3BlbmQNCj4gDQo+IE9uIE1vbmRheSwgU2VwdGVtYmVyIDA3LCAyMDE1IDExOjQyOjQx
IFBNIElyaW5hIFRpcmRlYSB3cm90ZToNCj4gPiBBZGQgbmV3IG9wdGlvbiB0byBzeXNmcyBjb250
cm9sIGludGVyZmFjZSwgYWxsb3dpbmcgdGhlIHVzZXIgdG8gZm9yY2UNCj4gPiBzdXNwZW5kIHRo
ZSBkZXZpY2UuDQo+IA0KPiBIYWQgd2UgdGhvdWdodCB0aGlzIGhhZCBiZWVuIGEgZ29vZCBpZGVh
LCB3ZSdkIGhhdmUgYWRkZWQgdGhhdCB0aGluZyB0bw0KPiB0aGUgaW50ZXJmYWNlIGZyb20gdGhl
IHN0YXJ0Lg0KPiANCj4gVGhlIHByb2JsZW0gd2l0aCBpdCBpcyB0aGF0IHVzZXIgc3BhY2UgZ2Vu
ZXJhbGx5IGRvZXNuJ3Qga25vdyB3aGVuIGl0IGlzDQo+IHNhZmUgdG8gc3VzcGVuZCBhIGRldmlj
ZSwgc28gaXQgY2Fubm90IGZvcmNlIGFueXRoaW5nIGludG8gcnVudGltZSBzdXNwZW5kLg0KPiAN
Cg0KWWVzLCB0aGlzIGlzIGdlbmVyYWxseSB0cnVlLiANCg0KSG93ZXZlciwgaW4gdGhlIHNjZW5h
cmlvIEkgbWVudGlvbmVkIHRoaXMgaXMgZXhhY3RseSB3aGF0IGlzIGhhcHBlbmluZy4NCldoZW4g
dHVybmluZyBvZmYgdGhlIHNjcmVlbiBvZiBhIG1vYmlsZSBkZXZpY2UsIHRoZSB1c2VyIHNwYWNl
DQppcyB0aGUgb25lIHRoYXQgc3VzcGVuZHMgdGhlIGRldmljZXMgdGhhdCBhcmUgbm90IG5lZWRl
ZCBpbiBvcmRlciB0byBzYXZlIHBvd2VyDQoobGlrZSB0b3VjaHNjcmVlbnMpLiBFYWNoIHN1Y2gg
ZHJpdmVyIGV4cG9ydCBhbiBlbmFibGUvZGlzYWJsZSBhdHRyaWJ1dGUNCnRoYXQgY2FsbHMgdGhl
IHNhbWUgY29kZSBhcyByZXN1bWUvc3VzcGVuZCAoZS5nLiB0b3VjaHNjcmVlbiBkcml2ZXJzIGFk
czc4NDYsDQphZDc4NzcgYW5kIG1vc3QgQW5kcm9pZCBkcml2ZXJzIG5vdCBtZXJnZWQgdXBzdHJl
YW0pLiBUaGlzIGFkZHMgbW9yZQ0KY29tcGxleGl0eSB0byBldmVyeSBkcml2ZXIgYnkgYWRkaW5n
IG9uZSBtb3JlIGxvZ2ljYWwgcG93ZXIgc3RhdGUuDQpJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUg
YSBjb21tb24gaW50ZXJmYWNlIGluc3RlYWQgb2YgZG9pbmcgdGhpcyBpbg0KZXZlcnkgZHJpdmVy
Lg0KDQpJIG1pZ2h0IGhhdmUgbm90IHVzZWQgImZvcmNlZCIgaW4gdGhlIHByb3BlciB3YXkgaGVy
ZS4gV2hhdCBJIG1lYW4gYnkgaXQgaXMgdGhhdA0KdGhlIGRldmljZSBjYW4gYmUgcnVudGltZSBz
dXNwZW5kZWQgd2hpbGUgaWdub3JpbmcgdGhlIHJ1bnRpbWUgdXNhZ2UgY291bnQuDQoNCj4gPiBU
aGlzIGlzIHVzZWZ1bCBmb3IgZGV2aWNlcyB0aGF0IG5lZWQgdG8gYmUNCj4gPiBzdXNwZW5kZWQg
d2hlbiBjbG9zaW5nIHRoZSBsaWQgb2YgYSBsYXB0b3Agb3IgdGhlIHNjcmVlbiBvZiBhIG1vYmls
ZQ0KPiA+IGRldmljZSwgd2hpbGUgdXNlciBzcGFjZSBzdGlsbCBob2xkcyBvcGVuIGhhbmRsZXMg
dG8gaXQgYW5kIHRoZQ0KPiA+IHN5c3RlbSBkb2VzIG5vdCBlbnRlciBzeXN0ZW0gc3VzcGVuZC4N
Cj4gPg0KPiA+IEFkZCB0aGUgIm9mZiIgb3B0aW9uIHRvIHRoZSBzeXNmcyBjb250cm9sIHBvd2Vy
IGludGVyZmFjZSwgYWxvbmcgd2l0aA0KPiA+IHRoZSBhbHJlYWR5IHByZXNlbnQgIm9uIiBhbmQg
ImF1dG8iLiBXaGVuIHRoaXMgYXR0cmlidXRlIGlzIHNldCB0bw0KPiA+ICJvZmYiLCB0aGUgZGV2
aWNlIHdpbGwgYmUgZm9yY2Ugc3VzcGVuZGVkIGJ5IGNhbGxpbmcgaXRzIHJ1bnRpbWUNCj4gPiBz
dXNwZW5kIGNhbGxiYWNrIGFuZCBkaXNhYmxpbmcgcnVudGltZSBwb3dlciBtYW5hZ2VtZW50IHNv
IHRoYXQNCj4gPiBmdXJ0aGVyIGFjY2Vzc2VzIHRvIHRoZSBkZXZpY2Ugd2lsbCBub3QgY2hhbmdl
IHRoZSBhY3R1YWwgc3RhdGUuDQo+IA0KPiBBbmQgaG93IGlzIHVzZXIgc3BhY2Ugc3VwcG9zZWQg
dG8ga25vdyB0aGF0IGl0IGRvZXNuJ3QgYnJlYWsgdGhpbmdzDQo+IHRoaXMgd2F5Pw0KPiANCg0K
SW4gdGhpcyBpbXBsZW1lbnRhdGlvbiwgdXNlciBzcGFjZSBpcyBvbmx5IGFsbG93ZWQgdG8gY2hh
bmdlIHRoZSBzdGF0ZXMNCmJvdHRvbS11cCBpbiB0aGUgc3lzZnMgaGllcmFyY2h5IChpdCBjYW5u
b3QgZm9yY2Ugc3VzcGVuZCBhIGRldmljZSBpZiBpdA0KaGFzIGNoaWxkcmVuIHRoYXQgaGF2ZSBu
b3QgYmVlbiBzdXNwZW5kZWQgYnkgdXNlciBzcGFjZSkuDQoNCkFub3RoZXIgd2F5IHRvIGRvIHRo
aXMgaXMgdG8ga2VlcCBydW50aW1lIHBvd2VyIG1hbmFnZW1lbnQgZW5hYmxlZA0KYnV0IHRvIGZv
cmNlIHRoZSB1c2FnZSBjb3VudCB0byAwIHdoaWxlIHRoZSBkZXZpY2UgaXMgc2V0IHRvIHJ1bnRp
bWUgbW9kZQ0KIm9mZiIuDQoNCj4gPiBUaGUgZGV2aWNlIGNhbiBiZSByZXN1bWVkIGJ5IHNldHRp
bmcgdGhlIGF0dHJpYnV0ZSB0byAib24iIG9yICJhdXRvIi4NCj4gPiBUaGUgYmVoYXZpb3Igb2Yg
dGhlIGludGVyZmFjZSB3aGVuIHN3aXRjaGluZyBvbmx5IGJldHdlZW4gIm9uIg0KPiA+IGFuZCAi
YXV0byIgc3RhdGVzIHJlbWFpbnMgdW5jaGFuZ2VkLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTog
SXJpbmEgVGlyZGVhIDxpcmluYS50aXJkZWFAaW50ZWwuY29tPg0KPiA+IC0tLQ0KPiA+DQo+ID4g
SGksDQo+ID4NCj4gPiBUaGlzIGlzIGEgcHJvcG9zYWwgZm9yIHN1c3BlbmRpbmcgZGV2aWNlcyB3
aGVuIHRoZSBjbG9zaW5nIHRoZSBsaWQgb2YNCj4gPiBhIGxhcHRvcCBvciB0aGUgc2NyZWVuIG9m
IGEgbW9iaWxlIGRldmljZS4NCj4gPg0KPiA+IEkgYW0gdGVzdGluZyB0aGlzIHdpdGggYSBHb29k
aXggdG91Y2hzY3JlZW4gWzFdIGZvciBhbiBBbmRyb2lkIG1vYmlsZQ0KPiA+IGRldmljZS4gQW5k
cm9pZCBoYXMgYW4gdXNlciBzcGFjZSBsYXllciAocG93ZXIgSEFMKSB0aGF0IHdvdWxkIG5vcm1h
bGx5DQo+ID4gY2xvc2UgdGhlIHRvdWNoc2NyZWVuIHdoZW4gdGhlIHNjcmVlbiBpcyBjbG9zZWQu
IEFuZHJvaWQgdG91Y2hzY3JlZW4NCj4gPiBkcml2ZXJzIHVzdWFsbHkgcHJvdmlkZSBhIGN1c3Rv
bSBzeXNmcyBpbnRlcmZhY2UgdG8gYWxsb3cgdGhpcy4NCj4gPiBUaGlzIHdvdWxkIGJlIGJldHRl
ciBpbXBsZW1lbnRlZCBpbiBhIGNvbW1vbiBwbGFjZSwgdG8gYXZvaWQgY29kZQ0KPiA+IGR1cGxp
Y2F0aW9uIGFuZCB0byBzaW1wbGlmeSB0aGUgZHJpdmVyIGNvZGUgKGFzIHByZXZpb3VzbHkgZGlz
Y3Vzc2VkDQo+ID4gaW4gWzFdKS4NCj4gPg0KPiA+IEkga25vdyB0aGVyZSBhcmUgbW9yZSB3YXlz
IHRvIGltcGxlbWVudCB0aGlzLCBzbyBJIHdvdWxkIGFwcHJlY2lhdGUNCj4gPiB5b3VyIGZlZWRi
YWNrLg0KPiANCj4gU28gdGhlIGZlZWRiYWNrIGlzIHRoYXQgdGhpcyBpcyBub3QgZ29pbmcgdG8g
d29yayBpbiBnZW5lcmFsLiAgUGxlYXNlDQo+IHVzZSBhIGRpZmZlcmVudCBhcHByb2FjaC4NCj4g
DQoNCldvdWxkIGl0IHdvcmsgaWYgdGhpcyB3b3VsZCBiZSBhIGNhcGFiaWxpdHkgdGhhdCBpbmRp
dmlkdWFsIGRyaXZlcnMgbmVlZA0KdG8gZGVjbGFyZT8NCg0KSW4gdGhlIHByZXZpb3VzIGRpc2N1
c3Npb24gdGhyZWFkICwgdGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBvcHRpb25zDQptZW50aW9uZWQs
IGJ1dCBub25lIHNlZW1lZCB0byByZWFjaCBhIGNvbnNlbnN1cy4gWW91IG1lbnRpb25lZA0KYWRk
aW5nIGEgIm1vcmUgYWdncmVzc2l2ZSBydW50aW1lIFBNIG1vZGUiIFsxXS4gSSdtIG5vdCBzdXJl
IGhvdw0KdGhpcyB3b3VsZCB3b3JrIGV4Y2VwdCBmb3IgYWRkaW5nIGEgc3lzZnMgYXR0cmlidXRl
IHRoYXQgd291bGQgdHJpZ2dlcg0KYSBydW50aW1lIHN1c3BlbmQgd2hpbGUgaWdub3JpbmcgdXNh
Z2UgY291bnQuIFdvdWxkIHRoYXQgYmUgYQ0KYmV0dGVyIGRpcmVjdGlvbj8NCg0KVGhhbmsgeW91
LA0KSXJpbmENCg0KWzFdIGh0dHA6Ly9tYXJjLmluZm8vP2w9bGludXgtaW5wdXQmbT0xNDA1NjQ2
MjYzMDYzOTYmdz0yDQoNCj4gVGhhbmtzLA0KPiBSYWZhZWwNCj4gDQo+IC0tDQo+IFRvIHVuc3Vi
c2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1p
bnB1dCIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5l
bC5vcmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9t
YWpvcmRvbW8taW5mby5odG1sDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1220551 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:

> However, in the scenario I mentioned this is exactly what is happening.
> When turning off the screen of a mobile device, the user space

Would you explain why user space doesn't simply stop using those
devices, which in turn will make them idle? There are obvious cases
like keyboards or SCSI hosts where the kernel controls stuff, but could
you state where you expect this to be most useful?
Or why devices cannot be closed, e.g. you need to be sure settings
be not lost or is it something else?

> is the one that suspends the devices that are not needed in order to save power
> (like touchscreens). Each such driver export an enable/disable attribute
> that calls the same code as resume/suspend (e.g. touchscreen drivers ads7846,
> ad7877 and most Android drivers not merged upstream). This adds more
> complexity to every driver by adding one more logical power state.
> It would be good to have a common interface instead of doing this in
> every 

Now these are two distinct questions.

1. a common interface
2. a capability implemented in common code

It is important to keep that apart. I suppose if we want this at all
#1 is a given. #2 however may be impossible in a generic manner

> I might have not used "forced" in the proper way here. What I mean by it is that
> the device can be runtime suspended while ignoring the runtime usage count.

That is highly problematic. You'd need to audit the locking in every
driver. Right now elevating the count means that suspend()/resume()
cannot race with user space, as in the case of the system suspending
user space is frozen.

> In this implementation, user space is only allowed to change the states
> bottom-up in the sysfs hierarchy (it cannot force suspend a device if it
> has children that have not been suspended by user space).

That is obviously not enough. Take the worst case: we are flashing some
firmware. Or far more harmless: a key is has been pressed on a keyboard

> Would it work if this would be a capability that individual drivers need
> to declare?

For some drivers. But it needs support in the driver. Right now we can
make a device idle by calling close(). In fact we can benefit for
example in mice from this. But it needs support in the drivers.

> In the previous discussion thread , there were a couple of options
> mentioned, but none seemed to reach a consensus. You mentioned
> adding a "more aggressive runtime PM mode" [1]. I'm not sure how

That would have to be done on a per driver base.

> this would work except for adding a sysfs attribute that would trigger
> a runtime suspend while ignoring usage count. Would that be a
> better direction?

No. If we want this at all, we need a new callback to notify drivers
that user space is temporarily uninterested in a device. And the reverse
of course.
The power model is good. We must not assume that devices can be
suspended at will. If we do this at all, we ought to see it as giving
strong hints to drivers when a device can be considered idle.

	Regards
		Oliver


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

[toc] | [prev] | [next] | [standalone]

#1221084 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@suse.com> wrote:
> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:

[cut]

>> this would work except for adding a sysfs attribute that would trigger
>> a runtime suspend while ignoring usage count. Would that be a
>> better direction?
>
> No. If we want this at all, we need a new callback to notify drivers
> that user space is temporarily uninterested in a device. And the reverse
> of course.
> The power model is good. We must not assume that devices can be
> suspended at will. If we do this at all, we ought to see it as giving
> strong hints to drivers when a device can be considered idle.

This is a good summary in my view.

The only thing we can add, realistically, is an interface for user
space to "kick" drivers to check if the devices they handle may be
suspended at this point (or to run their ->runtime_idle callbacks
IOW).

That would be quite similar to autosuspend except that the "kick" will
come from user space rather than from a timer function in the kernel.

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

[toc] | [prev] | [next] | [standalone]

#1221120 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On 8 September 2015 at 22:56, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@suse.com> wrote:
>> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:
>
> [cut]
>
>>> this would work except for adding a sysfs attribute that would trigger
>>> a runtime suspend while ignoring usage count. Would that be a
>>> better direction?
>>
>> No. If we want this at all, we need a new callback to notify drivers
>> that user space is temporarily uninterested in a device. And the reverse
>> of course.
>> The power model is good. We must not assume that devices can be
>> suspended at will. If we do this at all, we ought to see it as giving
>> strong hints to drivers when a device can be considered idle.
>
> This is a good summary in my view.
>
> The only thing we can add, realistically, is an interface for user
> space to "kick" drivers to check if the devices they handle may be
> suspended at this point (or to run their ->runtime_idle callbacks
> IOW).
>
> That would be quite similar to autosuspend except that the "kick" will
> come from user space rather than from a timer function in the kernel.

Apologize for interrupting the discussion!

Unless I miss the point, I assumes the above is somewhat already
achievable via sysfs when changing the value of the auto-suspend
timeout, since it triggers a call to
pm_runtime_set_autosuspend_delay()...

Also, according to the discussion so far, it seems like we are on
agreement that we should really think twice when considering to extend
the sysfs interface for runtime PM.

From the change-log/description to $subject patch, I fail to
understand *why* the regular runtime PM *autosuspend* feature isn't
sufficient. Perhaps Irina can elaborate more on the use case, to help
me get a better understanding of the issue!?

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

[toc] | [prev] | [next] | [standalone]

#1221151 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

Hi,

On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 8 September 2015 at 22:56, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@suse.com> wrote:
>>> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:
>>
>> [cut]
>>
>>>> this would work except for adding a sysfs attribute that would trigger
>>>> a runtime suspend while ignoring usage count. Would that be a
>>>> better direction?
>>>
>>> No. If we want this at all, we need a new callback to notify drivers
>>> that user space is temporarily uninterested in a device. And the reverse
>>> of course.
>>> The power model is good. We must not assume that devices can be
>>> suspended at will. If we do this at all, we ought to see it as giving
>>> strong hints to drivers when a device can be considered idle.
>>
>> This is a good summary in my view.
>>
>> The only thing we can add, realistically, is an interface for user
>> space to "kick" drivers to check if the devices they handle may be
>> suspended at this point (or to run their ->runtime_idle callbacks
>> IOW).
>>
>> That would be quite similar to autosuspend except that the "kick" will
>> come from user space rather than from a timer function in the kernel.
>
> Apologize for interrupting the discussion!
>
> Unless I miss the point, I assumes the above is somewhat already
> achievable via sysfs when changing the value of the auto-suspend
> timeout, since it triggers a call to
> pm_runtime_set_autosuspend_delay()...

Well, from the initial comment in drivers/base/power/sysfs.c:

 *
 *    NOTE: The autosuspend_delay_ms attribute and the autosuspend_delay
 *    value are used only if the driver calls pm_runtime_use_autosuspend().
 *

Some drivers don't do that and they would be the primary target
audience for the new interface (if we agreed that it was useful after
all).

> Also, according to the discussion so far, it seems like we are on
> agreement that we should really think twice when considering to extend
> the sysfs interface for runtime PM.

That certainly is correct and not limited to runtime PM. :-)

> From the change-log/description to $subject patch, I fail to
> understand *why* the regular runtime PM *autosuspend* feature isn't
> sufficient. Perhaps Irina can elaborate more on the use case, to help
> me get a better understanding of the issue!?

My understanding is that the idea would be to trigger an attempt to
suspend via a specific event (eg. lid closes) rather then via an
inactivity timer.

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

[toc] | [prev] | [next] | [standalone]

#1221371 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, Sep 9, 2015 at 2:50 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> Hi,
>
> On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On 8 September 2015 at 22:56, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@suse.com> wrote:
> >>> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:
> >>
> >> [cut]
> >>
> >>>> this would work except for adding a sysfs attribute that would trigger
> >>>> a runtime suspend while ignoring usage count. Would that be a
> >>>> better direction?
> >>>
> >>> No. If we want this at all, we need a new callback to notify drivers
> >>> that user space is temporarily uninterested in a device. And the reverse
> >>> of course.
> >>> The power model is good. We must not assume that devices can be
> >>> suspended at will. If we do this at all, we ought to see it as giving
> >>> strong hints to drivers when a device can be considered idle.
> >>
> >> This is a good summary in my view.
> >>
> >> The only thing we can add, realistically, is an interface for user
> >> space to "kick" drivers to check if the devices they handle may be
> >> suspended at this point (or to run their ->runtime_idle callbacks
> >> IOW).
> >>
> >> That would be quite similar to autosuspend except that the "kick" will
> >> come from user space rather than from a timer function in the kernel.
> >
> > Apologize for interrupting the discussion!
> >
> > Unless I miss the point, I assumes the above is somewhat already
> > achievable via sysfs when changing the value of the auto-suspend
> > timeout, since it triggers a call to
> > pm_runtime_set_autosuspend_delay()...
>
> Well, from the initial comment in drivers/base/power/sysfs.c:
>
>  *
>  *    NOTE: The autosuspend_delay_ms attribute and the autosuspend_delay
>  *    value are used only if the driver calls pm_runtime_use_autosuspend().
>  *
>
> Some drivers don't do that and they would be the primary target
> audience for the new interface (if we agreed that it was useful after
> all).
>
> > Also, according to the discussion so far, it seems like we are on
> > agreement that we should really think twice when considering to extend
> > the sysfs interface for runtime PM.
>
> That certainly is correct and not limited to runtime PM. :-)
>
> > From the change-log/description to $subject patch, I fail to
> > understand *why* the regular runtime PM *autosuspend* feature isn't
> > sufficient. Perhaps Irina can elaborate more on the use case, to help
> > me get a better understanding of the issue!?
>
> My understanding is that the idea would be to trigger an attempt to
> suspend via a specific event (eg. lid closes) rather then via an
> inactivity timer.
>

The best example and actually the very specific problem we want to
solve is handling touchscreens on a phone / tablet. When the screen is
turned off, it is ideal to suspend the touchscreen for two reasons: to
lower the power consumption as much as possible and to prevent
interrupts to wake-up the CPU when the user touches the device, and
thus save even more power as we allow the CPU to stay in deep idle
states for longer periods.

Note that when the screen is turned-on again, we want to resume the
touchscreen so that it can send events again.

This is different then the lid closes examples, as in that case the
user can not generate new events and thus the usual autosuspend
feature is probably good enough (if the suspend power and autosuspend
power consumption is similar).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221395 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

Hi,

On Wed, Sep 9, 2015 at 1:13 PM, Octavian Purdila
<octavian.purdila@intel.com> wrote:
> On Wed, Sep 9, 2015 at 2:50 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>
>> Hi,
>>
>> On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> > On 8 September 2015 at 22:56, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> >> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@suse.com> wrote:
>> >>> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:
>> >>
>> >> [cut]
>> >>
>> >>>> this would work except for adding a sysfs attribute that would trigger
>> >>>> a runtime suspend while ignoring usage count. Would that be a
>> >>>> better direction?
>> >>>
>> >>> No. If we want this at all, we need a new callback to notify drivers
>> >>> that user space is temporarily uninterested in a device. And the reverse
>> >>> of course.
>> >>> The power model is good. We must not assume that devices can be
>> >>> suspended at will. If we do this at all, we ought to see it as giving
>> >>> strong hints to drivers when a device can be considered idle.
>> >>
>> >> This is a good summary in my view.
>> >>
>> >> The only thing we can add, realistically, is an interface for user
>> >> space to "kick" drivers to check if the devices they handle may be
>> >> suspended at this point (or to run their ->runtime_idle callbacks
>> >> IOW).
>> >>
>> >> That would be quite similar to autosuspend except that the "kick" will
>> >> come from user space rather than from a timer function in the kernel.
>> >
>> > Apologize for interrupting the discussion!
>> >
>> > Unless I miss the point, I assumes the above is somewhat already
>> > achievable via sysfs when changing the value of the auto-suspend
>> > timeout, since it triggers a call to
>> > pm_runtime_set_autosuspend_delay()...
>>
>> Well, from the initial comment in drivers/base/power/sysfs.c:
>>
>>  *
>>  *    NOTE: The autosuspend_delay_ms attribute and the autosuspend_delay
>>  *    value are used only if the driver calls pm_runtime_use_autosuspend().
>>  *
>>
>> Some drivers don't do that and they would be the primary target
>> audience for the new interface (if we agreed that it was useful after
>> all).
>>
>> > Also, according to the discussion so far, it seems like we are on
>> > agreement that we should really think twice when considering to extend
>> > the sysfs interface for runtime PM.
>>
>> That certainly is correct and not limited to runtime PM. :-)
>>
>> > From the change-log/description to $subject patch, I fail to
>> > understand *why* the regular runtime PM *autosuspend* feature isn't
>> > sufficient. Perhaps Irina can elaborate more on the use case, to help
>> > me get a better understanding of the issue!?
>>
>> My understanding is that the idea would be to trigger an attempt to
>> suspend via a specific event (eg. lid closes) rather then via an
>> inactivity timer.
>>
>
> The best example and actually the very specific problem we want to
> solve is handling touchscreens on a phone / tablet. When the screen is
> turned off, it is ideal to suspend the touchscreen for two reasons: to
> lower the power consumption as much as possible and to prevent
> interrupts to wake-up the CPU when the user touches the device, and
> thus save even more power as we allow the CPU to stay in deep idle
> states for longer periods.
>
> Note that when the screen is turned-on again, we want to resume the
> touchscreen so that it can send events again.

In fact, then, what you need seems to be the feature discussed by Alan
and me some time ago allowing remote wakeup do be disabled for runtime
PM from user space as that in combination with autosuspend should
address your use case.

> This is different then the lid closes examples, as in that case the
> user can not generate new events and thus the usual autosuspend
> feature is probably good enough (if the suspend power and autosuspend
> power consumption is similar).

Autosuspend just means checking the device state periodically and
suspending it if idle (not in use).  It doesn't affect the energy
consumption in the suspended state.

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

[toc] | [prev] | [next] | [standalone]

#1221478 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> > Note that when the screen is turned-on again, we want to resume the
> > touchscreen so that it can send events again.

Why is it impractical to close the fd for the touchscreen?
> 
> In fact, then, what you need seems to be the feature discussed by Alan
> and me some time ago allowing remote wakeup do be disabled for runtime
> PM from user space as that in combination with autosuspend should
> address your use case.

I'd doubt that. Suppose you put the phone into your pocket while
the device isn't suspended. The continuous stream of spurious events
will keep it awake.
The ability to disable remote wakeup is necessary but not sufficient.

	Regards
		Oliver


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

[toc] | [prev] | [next] | [standalone]

#1221518 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum <oneukum@suse.com> wrote:
> On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
>> > Note that when the screen is turned-on again, we want to resume the
>> > touchscreen so that it can send events again.
>
> Why is it impractical to close the fd for the touchscreen?
>

I am not sure, but I think it is this way due to historical reasons.
On Android devices early-suspend was used originally to save power
when the screen was turned-off but the device was not suspend. Later
Android moved to power HAL [1] and run-time PM for some devices,
however that is not sufficient for touchscreen.

i2c touchscreen devices usually have two low-power states: a deep
power state where event collection is disabled and the device needs to
be poked via i2c to restart collecting events and a shallow power
state where the device reduces the internal polling rate after it is
idle for some time. The latter it is usually implemented directly in
hardware. That means that you can't really implemented auto-suspend
with the deep power state, since the device can not resume itself.

To address this limitation, Android used early suspend (and then the
power HAL mechanism) where the upper layers signals when you can turn
on or off certain devices.

I have added Colin and Arve to this thread who maybe can answer this better.

>> In fact, then, what you need seems to be the feature discussed by Alan
>> and me some time ago allowing remote wakeup do be disabled for runtime
>> PM from user space as that in combination with autosuspend should
>> address your use case.
>
> I'd doubt that. Suppose you put the phone into your pocket while
> the device isn't suspended. The continuous stream of spurious events
> will keep it awake.

I agree.

> The ability to disable remote wakeup is necessary but not sufficient.
>

I don't know enough about remote wake-up, but do we even need to use
it for this kind of devices?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221676

On Wednesday, September 09, 2015 06:02:02 PM Octavian Purdila wrote:
> On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum <oneukum@suse.com> wrote:
> > On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> >> > Note that when the screen is turned-on again, we want to resume the
> >> > touchscreen so that it can send events again.
> >
> > Why is it impractical to close the fd for the touchscreen?
> >
> 
> I am not sure, but I think it is this way due to historical reasons.
> On Android devices early-suspend was used originally to save power
> when the screen was turned-off but the device was not suspend. Later
> Android moved to power HAL [1] and run-time PM for some devices,
> however that is not sufficient for touchscreen.
> 
> i2c touchscreen devices usually have two low-power states: a deep
> power state where event collection is disabled and the device needs to
> be poked via i2c to restart collecting events and a shallow power
> state where the device reduces the internal polling rate after it is
> idle for some time. The latter it is usually implemented directly in
> hardware. That means that you can't really implemented auto-suspend
> with the deep power state, since the device can not resume itself.
> 
> To address this limitation, Android used early suspend (and then the
> power HAL mechanism) where the upper layers signals when you can turn
> on or off certain devices.
> 
> I have added Colin and Arve to this thread who maybe can answer this better.
> 
> >> In fact, then, what you need seems to be the feature discussed by Alan
> >> and me some time ago allowing remote wakeup do be disabled for runtime
> >> PM from user space as that in combination with autosuspend should
> >> address your use case.
> >
> > I'd doubt that. Suppose you put the phone into your pocket while
> > the device isn't suspended. The continuous stream of spurious events
> > will keep it awake.

Why would they be regarded as spurious then?  They are just regular touch panel
events in that case, aren't they?

> I agree.
> 
> > The ability to disable remote wakeup is necessary but not sufficient.
> >
> 
> I don't know enough about remote wake-up, but do we even need to use
> it for this kind of devices?

Well, if the device is capable of generating wakeup events while suspended,
the current expected behavior is to do that, but of course that needs to
be enabled by the driver/bus type too.

Thanks,
Rafael

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

[toc] | [prev] | [next] | [standalone]

#1222068 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, 2015-09-09 at 22:25 +0200, Rafael J. Wysocki wrote:
> > >
> > > I'd doubt that. Suppose you put the phone into your pocket while
> > > the device isn't suspended. The continuous stream of spurious
> events
> > > will keep it awake.
> 
> Why would they be regarded as spurious then?  They are just regular
> touch panel
> events in that case, aren't they?

These events are not expected to be caused by the user's hand.

But it raises a design question; whose job it is to handle
such information?
It makes no sense to gather events from a touchscreen if you
suspect the phone is randomly rubbing at things or to take
video from a camera if you know that the lid is closed covering
the lens. I think we can agree to that.

The thing is that we handle all other availability in kernel
space. You can argue that user space has an agreed interface
(evdev, V4L or whatever) and it is the kernel's job to react
if it learns that a device becomes temporarily unavailable
and this is merely a question of adding an interface to the
kernel by which user space can feed such information to the
kernel.

	Regards
		Oliver



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

[toc] | [prev] | [next] | [standalone]

#1229254 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

> > >> In fact, then, what you need seems to be the feature discussed by Alan
> > >> and me some time ago allowing remote wakeup do be disabled for runtime
> > >> PM from user space as that in combination with autosuspend should
> > >> address your use case.
> > >
> > > I'd doubt that. Suppose you put the phone into your pocket while
> > > the device isn't suspended. The continuous stream of spurious events
> > > will keep it awake.
> 
> Why would they be regarded as spurious then?  They are just regular touch panel
> events in that case, aren't they?

From userspace... they are spurious. Userspace does not known that
your device is commonly placed into the pocket, and the events it sees
are not from user.

I have mainline X/mate running on n900 cellphone. And this means
battery life is in "2 hours" range.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221528 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:

> > The best example and actually the very specific problem we want to
> > solve is handling touchscreens on a phone / tablet. When the screen is
> > turned off, it is ideal to suspend the touchscreen for two reasons: to
> > lower the power consumption as much as possible and to prevent
> > interrupts to wake-up the CPU when the user touches the device, and
> > thus save even more power as we allow the CPU to stay in deep idle
> > states for longer periods.
> >
> > Note that when the screen is turned-on again, we want to resume the
> > touchscreen so that it can send events again.
> 
> In fact, then, what you need seems to be the feature discussed by Alan
> and me some time ago allowing remote wakeup do be disabled for runtime
> PM from user space as that in combination with autosuspend should
> address your use case.

That, plus they want the touchscreen to go into runtime suspend 
whenever the screen is off (was this not the main reason for the 
patch?).

It seems to me that it should be possible to arrange for this to happen 
simply by making userspace close the touchscreen device when the screen 
is turned off.  Or am I missing something?

Alan Stern

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

[toc] | [prev] | [next] | [standalone]

#1221688

On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote:
> On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
> 
> > > The best example and actually the very specific problem we want to
> > > solve is handling touchscreens on a phone / tablet. When the screen is
> > > turned off, it is ideal to suspend the touchscreen for two reasons: to
> > > lower the power consumption as much as possible and to prevent
> > > interrupts to wake-up the CPU when the user touches the device, and
> > > thus save even more power as we allow the CPU to stay in deep idle
> > > states for longer periods.
> > >
> > > Note that when the screen is turned-on again, we want to resume the
> > > touchscreen so that it can send events again.
> > 
> > In fact, then, what you need seems to be the feature discussed by Alan
> > and me some time ago allowing remote wakeup do be disabled for runtime
> > PM from user space as that in combination with autosuspend should
> > address your use case.
> 
> That, plus they want the touchscreen to go into runtime suspend 
> whenever the screen is off (was this not the main reason for the 
> patch?).

Right.

> It seems to me that it should be possible to arrange for this to happen 
> simply by making userspace close the touchscreen device when the screen 
> is turned off.  Or am I missing something?

Honestly, I don't know.

Octavian, Irina, any reasons why things can't be done as Alan is suggesting?

Thanks,
Rafael

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

[toc] | [prev] | [next] | [standalone]

#1221693 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, Sep 9, 2015 at 1:35 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote:
> > On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > > The best example and actually the very specific problem we want to
> > > > solve is handling touchscreens on a phone / tablet. When the screen is
> > > > turned off, it is ideal to suspend the touchscreen for two reasons: to
> > > > lower the power consumption as much as possible and to prevent
> > > > interrupts to wake-up the CPU when the user touches the device, and
> > > > thus save even more power as we allow the CPU to stay in deep idle
> > > > states for longer periods.
> > > >
> > > > Note that when the screen is turned-on again, we want to resume the
> > > > touchscreen so that it can send events again.
> > >
> > > In fact, then, what you need seems to be the feature discussed by Alan
> > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > PM from user space as that in combination with autosuspend should
> > > address your use case.
> >
> > That, plus they want the touchscreen to go into runtime suspend
> > whenever the screen is off (was this not the main reason for the
> > patch?).
>
> Right.
>
> > It seems to me that it should be possible to arrange for this to happen
> > simply by making userspace close the touchscreen device when the screen
> > is turned off.  Or am I missing something?
>
> Honestly, I don't know.
>
> Octavian, Irina, any reasons why things can't be done as Alan is suggesting?


Early Android used early suspend, which notified various kernel
drivers that the screen was turning off so they could go into low
power states.  That meant there was no reason to close the touchscreen
fd - the kernel already knew about the screen off event.  We then got
rid of the early suspend hack and moved everything into userspace
using the power HAL and sysfs files.  Getting rid of the touchscreen
sysfs files and closing the touchscreen on screen off was on the
nice-to-have list, but hasn't made it onto anybody's todo list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229261 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed 2015-09-09 11:20:25, Alan Stern wrote:
> On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
> 
> > > The best example and actually the very specific problem we want to
> > > solve is handling touchscreens on a phone / tablet. When the screen is
> > > turned off, it is ideal to suspend the touchscreen for two reasons: to
> > > lower the power consumption as much as possible and to prevent
> > > interrupts to wake-up the CPU when the user touches the device, and
> > > thus save even more power as we allow the CPU to stay in deep idle
> > > states for longer periods.
> > >
> > > Note that when the screen is turned-on again, we want to resume the
> > > touchscreen so that it can send events again.
> > 
> > In fact, then, what you need seems to be the feature discussed by Alan
> > and me some time ago allowing remote wakeup do be disabled for runtime
> > PM from user space as that in combination with autosuspend should
> > address your use case.
> 
> That, plus they want the touchscreen to go into runtime suspend 
> whenever the screen is off (was this not the main reason for the 
> patch?).
> 
> It seems to me that it should be possible to arrange for this to happen 
> simply by making userspace close the touchscreen device when the screen 
> is turned off.  Or am I missing something?

Well... that's not what existing userspace expects. Your X windows
server will not close the touchscreen.

..and it would be nice to have enough hardware abstraction in the
kernel so that X can be used on phones...
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229433 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Mon, 21 Sep 2015, Pavel Machek wrote:

> > > In fact, then, what you need seems to be the feature discussed by Alan
> > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > PM from user space as that in combination with autosuspend should
> > > address your use case.
> > 
> > That, plus they want the touchscreen to go into runtime suspend 
> > whenever the screen is off (was this not the main reason for the 
> > patch?).
> > 
> > It seems to me that it should be possible to arrange for this to happen 
> > simply by making userspace close the touchscreen device when the screen 
> > is turned off.  Or am I missing something?
> 
> Well... that's not what existing userspace expects. Your X windows
> server will not close the touchscreen.

Surely that's a userspace issue, rather than a kernel problem?  The X
server does have some notion of power management and power savings; why
not extend that notion to include touchscreens?

> ..and it would be nice to have enough hardware abstraction in the
> kernel so that X can be used on phones...

What -- not Wayland?!  :-)

Alan Stern

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

[toc] | [prev] | [next] | [standalone]

#1229531 — Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Pavel Machek wrote:
> 
> > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > > PM from user space as that in combination with autosuspend should
> > > > address your use case.
> > > 
> > > That, plus they want the touchscreen to go into runtime suspend 
> > > whenever the screen is off (was this not the main reason for the 
> > > patch?).
> > > 
> > > It seems to me that it should be possible to arrange for this to happen 
> > > simply by making userspace close the touchscreen device when the screen 
> > > is turned off.  Or am I missing something?
> > 
> > Well... that's not what existing userspace expects. Your X windows
> > server will not close the touchscreen.
> 
> Surely that's a userspace issue, rather than a kernel problem?  The X
> server does have some notion of power management and power savings; why
> not extend that notion to include touchscreens?

It is not really practical: there are many consumers of input events, if
we build infrastructure to control it and proxy all users through it,
why not have it in kernel? Plus, there are users of input events
directly in the kernel, such as legacy VT/keyboard, or Android/ChromeOS
cpufreq_interactive governor that monitors user activity and bumps up
CPU speed when user actively interacts with the device. They would keep
input devices active even though user might not be actually able to
use some input devices.

Thanks.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web