Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1220389 > unrolled thread
| Started by | Irina Tirdea <irina.tirdea@intel.com> |
|---|---|
| First post | 2015-09-07 22:50 +0200 |
| Last post | 2015-09-09 16:40 +0200 |
| Articles | 20 on this page of 57 — 12 participants |
Back to article view | Back to linux.kernel
[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 Oliver Neukum <oneukum@suse.com> - 2015-09-22 14:10 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-22 16:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Oliver Neukum <oneukum@suse.de> - 2015-09-22 16:40 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-22 17:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Oliver Neukum <oneukum@suse.de> - 2015-09-23 05:10 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Octavian Purdila <octavian.purdila@intel.com> - 2015-09-23 09:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-23 17:00 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 02:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-25 16:40 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 21:50 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-25 23:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 23:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-26 00:40 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-26 17:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-27 15:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-27 16:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-28 15:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-28 16:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-28 22:10 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Alan Stern <stern@rowland.harvard.edu> - 2015-09-28 22:30 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Pavel Machek <pavel@ucw.cz> - 2015-10-04 17:20 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend Pavel Machek <pavel@ucw.cz> - 2015-09-27 19:10 +0200
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-28 15:20 +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 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-21 18:40 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbcid-3Gm-1@gated-at.bofh.it> |
| In reply to | #1229531 |
On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > 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. It sounds like you are suggesting there should be a general mechanism for userspace to tell the kernel (or the input core) to ignore all events from a particular input device -- or even from all input devices -- thereby allowing those devices to go to low power. I don't like to think of this as "forcing runtime suspend". It's more like telling the kernel that a device is no longer being used, so the natural runtime PM mechanism can put it in runtime suspend. Perhaps another way to think about it is that these input devices should not increment their runtime usage counter as part of the open routine; they should use something other than the number of open file references to indicate when they can go into runtime suspend. (I'm not sure what else they should use, though.) 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]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2015-09-21 19:00 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbcBB-43c-31@gated-at.bofh.it> |
| In reply to | #1229542 |
On Mon, Sep 21, 2015 at 12:34:56PM -0400, Alan Stern wrote: > On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > > 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. > > It sounds like you are suggesting there should be a general mechanism > for userspace to tell the kernel (or the input core) to ignore all > events from a particular input device -- or even from all input devices > -- thereby allowing those devices to go to low power. Yes. In ChromeOS we have a custim "inhibit" control that: 1. Tells input core to ignore all events form a given device 2. Allows driver to put device in low power mode if driver desires to do so. The driver can do it via runtime PM or on it's own. Usually on it's own since when using runtime PM userspace may disable it, which may not be desirable. I would love to have something generic instead of input-specific. > > I don't like to think of this as "forcing runtime suspend". It's more > like telling the kernel that a device is no longer being used, so the > natural runtime PM mechanism can put it in runtime suspend. I'd call it "accelerating" runtime suspend. Userspace tells the kernel that it intends not to use given device and kernel reacts accordingly. > > Perhaps another way to think about it is that these input devices > should not increment their runtime usage counter as part of the open > routine; they should use something other than the number of open file > references to indicate when they can go into runtime suspend. (I'm not > sure what else they should use, though.) I do not really want input specific support; as I mentioned before we have something like that in ChromeOS kernels but I was hesitant bringing it upstream as I believe it is not necessarily input device specific and I would love to have it implemented at device core level. 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-21 19:40 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbdeh-51N-1@gated-at.bofh.it> |
| In reply to | #1229569 |
On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > It sounds like you are suggesting there should be a general mechanism > > for userspace to tell the kernel (or the input core) to ignore all > > events from a particular input device -- or even from all input devices > > -- thereby allowing those devices to go to low power. > > Yes. In ChromeOS we have a custim "inhibit" control that: > > 1. Tells input core to ignore all events form a given device > 2. Allows driver to put device in low power mode if driver desires to do > so. The driver can do it via runtime PM or on it's own. Usually on it's > own since when using runtime PM userspace may disable it, which may not > be desirable. > > I would love to have something generic instead of input-specific. > > > > > I don't like to think of this as "forcing runtime suspend". It's more > > like telling the kernel that a device is no longer being used, so the > > natural runtime PM mechanism can put it in runtime suspend. > > I'd call it "accelerating" runtime suspend. Userspace tells the kernel > that it intends not to use given device and kernel reacts accordingly. Okay. > > Perhaps another way to think about it is that these input devices > > should not increment their runtime usage counter as part of the open > > routine; they should use something other than the number of open file > > references to indicate when they can go into runtime suspend. (I'm not > > sure what else they should use, though.) > > I do not really want input specific support; as I mentioned before we > have something like that in ChromeOS kernels but I was hesitant bringing > it upstream as I believe it is not necessarily input device specific and > I would love to have it implemented at device core level. That's not a bad idea. On the other hand, there must be lots of devices which would not be suitable for this. Disk drives, for instance. What happens if the "inhibit" control is turned on and the driver puts the device into runtime suspend, but then an I/O request arrives? If the I/O request originated from userspace, it means the user is violating the terms of the "inhibit" control. Should the request simply fail? What if the I/O request originated from somewhere in the kernel, not from the user? Or maybe the driver would want to carry out the request, overriding the "inhibit" control temporarily. Does it simply turn off the control, meaning that the device won't go back into runtime suspend until userspace turns the control on again? Or if the driver doesn't turn off the "inhibit" control, then how does it know when it can safely put the device back into runtime suspend? Qustions like these make me think that this mechanism is best suited for a kind of device that doesn't handle I/O requests. In other words, something that just reports events as they occur -- which is another way of describing an input device! 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]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2015-09-21 20:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbdHj-5Pr-1@gated-at.bofh.it> |
| In reply to | #1229594 |
On Mon, Sep 21, 2015 at 01:32:38PM -0400, Alan Stern wrote: > On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > > > It sounds like you are suggesting there should be a general mechanism > > > for userspace to tell the kernel (or the input core) to ignore all > > > events from a particular input device -- or even from all input devices > > > -- thereby allowing those devices to go to low power. > > > > Yes. In ChromeOS we have a custim "inhibit" control that: > > > > 1. Tells input core to ignore all events form a given device > > 2. Allows driver to put device in low power mode if driver desires to do > > so. The driver can do it via runtime PM or on it's own. Usually on it's > > own since when using runtime PM userspace may disable it, which may not > > be desirable. > > > > I would love to have something generic instead of input-specific. > > > > > > > > I don't like to think of this as "forcing runtime suspend". It's more > > > like telling the kernel that a device is no longer being used, so the > > > natural runtime PM mechanism can put it in runtime suspend. > > > > I'd call it "accelerating" runtime suspend. Userspace tells the kernel > > that it intends not to use given device and kernel reacts accordingly. > > Okay. > > > > Perhaps another way to think about it is that these input devices > > > should not increment their runtime usage counter as part of the open > > > routine; they should use something other than the number of open file > > > references to indicate when they can go into runtime suspend. (I'm not > > > sure what else they should use, though.) > > > > I do not really want input specific support; as I mentioned before we > > have something like that in ChromeOS kernels but I was hesitant bringing > > it upstream as I believe it is not necessarily input device specific and > > I would love to have it implemented at device core level. > > That's not a bad idea. On the other hand, there must be lots of > devices which would not be suitable for this. Disk drives, for > instance. Of course. > > What happens if the "inhibit" control is turned on and the driver puts > the device into runtime suspend, but then an I/O request arrives? > > If the I/O request originated from userspace, it means the > user is violating the terms of the "inhibit" control. Should > the request simply fail? What user? User that inhibited it or user that tried to use the device? > > What if the I/O request originated from somewhere in the > kernel, not from the user? I think we should treat in-kernel users as all other users. > > Or maybe the driver would want to carry out the request, > overriding the "inhibit" control temporarily. Does it simply > turn off the control, meaning that the device won't go back > into runtime suspend until userspace turns the control on > again? > > Or if the driver doesn't turn off the "inhibit" control, then > how does it know when it can safely put the device back into > runtime suspend? > > Qustions like these make me think that this mechanism is best suited > for a kind of device that doesn't handle I/O requests. In other words, > something that just reports events as they occur -- which is another > way of describing an input device! Or maybe IIO device. Or hwmon. Or something else. I think if we allow drivers (or subsystems) to opt in into this mechanism it will solve much of worries about disks and similar devices that indeed not very suitable for such mechanism. 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-21 22:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbfzs-8w4-15@gated-at.bofh.it> |
| In reply to | #1229625 |
On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > What happens if the "inhibit" control is turned on and the driver puts > > the device into runtime suspend, but then an I/O request arrives? > > > > If the I/O request originated from userspace, it means the > > user is violating the terms of the "inhibit" control. Should > > the request simply fail? > > What user? User that inhibited it or user that tried to use the device? Normally they would be the same. But even if they aren't, someone has violated the kernel interface: The first user told the kernel a particular device wasn't going to be used, and then the second user tried to use it. Of course, this issue doesn't arise for devices that merely report external events. > > What if the I/O request originated from somewhere in the > > kernel, not from the user? > > I think we should treat in-kernel users as all other users. > > > > > Or maybe the driver would want to carry out the request, > > overriding the "inhibit" control temporarily. Does it simply > > turn off the control, meaning that the device won't go back > > into runtime suspend until userspace turns the control on > > again? > > > > Or if the driver doesn't turn off the "inhibit" control, then > > how does it know when it can safely put the device back into > > runtime suspend? > > > > Qustions like these make me think that this mechanism is best suited > > for a kind of device that doesn't handle I/O requests. In other words, > > something that just reports events as they occur -- which is another > > way of describing an input device! > > Or maybe IIO device. Or hwmon. Or something else. I think if we allow > drivers (or subsystems) to opt in into this mechanism it will solve much > of worries about disks and similar devices that indeed not very suitable > for such mechanism. Should the mechanism really be per-device? Or would it be more useful to have a single "inhibit" setting that affected all the relevant devices at once? The runtime-PM "usage" value for these devices is a little tricky to calculate. It should be nonzero if there are any open files _and_ the device isn't "inhibited". I don't know the best way to represent that kind of condition in the runtime PM framework. 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]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2015-09-21 23:00 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbglQ-Z6-11@gated-at.bofh.it> |
| In reply to | #1229709 |
On Mon, Sep 21, 2015 at 04:02:01PM -0400, Alan Stern wrote: > On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > > > What happens if the "inhibit" control is turned on and the driver puts > > > the device into runtime suspend, but then an I/O request arrives? > > > > > > If the I/O request originated from userspace, it means the > > > user is violating the terms of the "inhibit" control. Should > > > the request simply fail? > > > > What user? User that inhibited it or user that tried to use the device? > > Normally they would be the same. But even if they aren't, someone has > violated the kernel interface: The first user told the kernel a > particular device wasn't going to be used, and then the second user > tried to use it. > > Of course, this issue doesn't arise for devices that merely report > external events. > > > > What if the I/O request originated from somewhere in the > > > kernel, not from the user? > > > > I think we should treat in-kernel users as all other users. > > > > > > > > Or maybe the driver would want to carry out the request, > > > overriding the "inhibit" control temporarily. Does it simply > > > turn off the control, meaning that the device won't go back > > > into runtime suspend until userspace turns the control on > > > again? > > > > > > Or if the driver doesn't turn off the "inhibit" control, then > > > how does it know when it can safely put the device back into > > > runtime suspend? > > > > > > Qustions like these make me think that this mechanism is best suited > > > for a kind of device that doesn't handle I/O requests. In other words, > > > something that just reports events as they occur -- which is another > > > way of describing an input device! > > > > Or maybe IIO device. Or hwmon. Or something else. I think if we allow > > drivers (or subsystems) to opt in into this mechanism it will solve much > > of worries about disks and similar devices that indeed not very suitable > > for such mechanism. > > Should the mechanism really be per-device? Or would it be more useful > to have a single "inhibit" setting that affected all the relevant > devices at once? Definitely per device. Consider your laptop with external monitor and keyboard connected. When you close the lid you want to inhibit internal keyboard, touchpad and touchscreen while leaving external keyboard and mouse working. That's just one scenario. 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]
| From | Oliver Neukum <oneukum@suse.com> |
|---|---|
| Date | 2015-09-22 14:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbuyu-4T3-3@gated-at.bofh.it> |
| In reply to | #1229709 |
On Mon, 2015-09-21 at 16:02 -0400, Alan Stern wrote: > On Mon, 21 Sep 2015, Dmitry Torokhov wrote: > > > > What happens if the "inhibit" control is turned on and the driver puts > > > the device into runtime suspend, but then an I/O request arrives? > > > > > > If the I/O request originated from userspace, it means the > > > user is violating the terms of the "inhibit" control. Should > > > the request simply fail? > > > > What user? User that inhibited it or user that tried to use the device? > > Normally they would be the same. But even if they aren't, someone has > violated the kernel interface: The first user told the kernel a > particular device wasn't going to be used, and then the second user > tried to use it. If we assume that user space speaks with a uniform voice on that issue, it can just as well close the device. It seems to me that declaring a device idle is a privileged operation. > Of course, this issue doesn't arise for devices that merely report > external events. Indeed. We can handle output to suspended devices by waking them. I don't see why this case is different. We are talking about input only. > The runtime-PM "usage" value for these devices is a little tricky to > calculate. It should be nonzero if there are any open files _and_ the > device isn't "inhibited". I don't know the best way to represent that > kind of condition in the runtime PM framework. Does that make sense in the generic framework at all? I still think that drivers should cease IO for input in such cases. That should involve a common callback, but no counter. 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-22 16:20 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbwAi-7K8-15@gated-at.bofh.it> |
| In reply to | #1230103 |
On Tue, 22 Sep 2015, Oliver Neukum wrote: > Indeed. We can handle output to suspended devices by waking them. > I don't see why this case is different. We are talking about input > only. > > > The runtime-PM "usage" value for these devices is a little tricky to > > calculate. It should be nonzero if there are any open files _and_ the > > device isn't "inhibited". I don't know the best way to represent that > > kind of condition in the runtime PM framework. > > Does that make sense in the generic framework at all? I still > think that drivers should cease IO for input in such cases. > That should involve a common callback, but no counter. I'm not sure I understand what you're saying. Are you suggesting that this "inhibit" mechanism should involve a new callback different from the existing runtime-PM callbacks? And when this new callback is invoked, drivers should cancel existing input requests (these devices are input-only) and go to low power? This would create a parallel runtime-PM mechanism which is independent of the existing one. Is that really a good idea? 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]
| From | Oliver Neukum <oneukum@suse.de> |
|---|---|
| Date | 2015-09-22 16:40 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbwTF-86z-55@gated-at.bofh.it> |
| In reply to | #1230250 |
On Tue, 2015-09-22 at 10:15 -0400, Alan Stern wrote: > On Tue, 22 Sep 2015, Oliver Neukum wrote: > > > Indeed. We can handle output to suspended devices by waking them. > > I don't see why this case is different. We are talking about input > > only. > > > > > The runtime-PM "usage" value for these devices is a little tricky to > > > calculate. It should be nonzero if there are any open files _and_ the > > > device isn't "inhibited". I don't know the best way to represent that > > > kind of condition in the runtime PM framework. > > > > Does that make sense in the generic framework at all? I still > > think that drivers should cease IO for input in such cases. > > That should involve a common callback, but no counter. > > I'm not sure I understand what you're saying. Are you suggesting that > this "inhibit" mechanism should involve a new callback different from Yes, there is no necessary relation to power management. If you put your phone into your pocket, you will want to inhibit the touchscreen even if that doesn't save power. > the existing runtime-PM callbacks? And when this new callback is > invoked, drivers should cancel existing input requests (these devices > are input-only) and go to low power? Cancel, yes, going to low power is a consequence which needn't bother the power subsystem. You need a callback. If there are spurious events, the current heuristics will keep devices awake. You must discard them anyway, as they are spurious. There's no point in transporting over the bus at all. We can cease IO for input. > This would create a parallel runtime-PM mechanism which is independent > of the existing one. Is that really a good idea? It isn't strictly PM. It helps PM to do a better job, but conceptually it is independent. 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-22 17:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbxG3-P2-35@gated-at.bofh.it> |
| In reply to | #1230286 |
On Tue, 22 Sep 2015, Oliver Neukum wrote: > > I'm not sure I understand what you're saying. Are you suggesting that > > this "inhibit" mechanism should involve a new callback different from > > Yes, there is no necessary relation to power management. If you put > your phone into your pocket, you will want to inhibit the touchscreen > even if that doesn't save power. > > > the existing runtime-PM callbacks? And when this new callback is > > invoked, drivers should cancel existing input requests (these devices > > are input-only) and go to low power? > > Cancel, yes, going to low power is a consequence which needn't bother > the power subsystem. Going to low power needn't involve the power subsystem? That sounds weird. > You need a callback. If there are spurious > events, the current heuristics will keep devices awake. > You must discard them anyway, as they are spurious. There's no point > in transporting over the bus at all. We can cease IO for input. > > > This would create a parallel runtime-PM mechanism which is independent > > of the existing one. Is that really a good idea? > > It isn't strictly PM. It helps PM to do a better job, but > conceptually it is independent. So my next question is: _How_ can this help PM to do a better job? That is, what are the mechanisms? One you have already stated: Lack of spurious events will help prevent unwanted wakeups (or unwanted failures to go to sleep). But Dmitry made a stronger claim: Inhibiting an input device should allow the device to go to low power. I would like to know how we can implement this cleanly. The most straightforward approach is to use runtime PM, but it's not obvious how this can be made to work with the current API. 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]
| From | Oliver Neukum <oneukum@suse.de> |
|---|---|
| Date | 2015-09-23 05:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbIBr-8lQ-5@gated-at.bofh.it> |
| In reply to | #1230329 |
On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote: > On Tue, 22 Sep 2015, Oliver Neukum wrote: > > > Cancel, yes, going to low power is a consequence which needn't bother > > the power subsystem. > > Going to low power needn't involve the power subsystem? That sounds > weird. Think of it like rfkill. It makes sense to suspend an rfkilled device. It still is the job of the driver to report that its device is idle. > > You need a callback. If there are spurious > > events, the current heuristics will keep devices awake. > > You must discard them anyway, as they are spurious. There's no point > > in transporting over the bus at all. We can cease IO for input. > > > > > This would create a parallel runtime-PM mechanism which is independent > > > of the existing one. Is that really a good idea? > > > > It isn't strictly PM. It helps PM to do a better job, but > > conceptually it is independent. > > So my next question is: _How_ can this help PM to do a better job? > That is, what are the mechanisms? "inhibit" -> driver stops input -> driver sets PM count to zero -> PM subsystem acts To go from the first to the second step a callback is needed > One you have already stated: Lack of spurious events will help prevent > unwanted wakeups (or unwanted failures to go to sleep). That too. We also save CPU cycles. > But Dmitry made a stronger claim: Inhibiting an input device should > allow the device to go to low power. I would like to know how we can > implement this cleanly. The most straightforward approach is to use > runtime PM, but it's not obvious how this can be made to work with the > current API. Yes, we can use the current API. The key is that you think of the mechanism as induced idleness, not forced suspend. We already have a perfectly working mechanism for suspending idle devices. 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]
| From | Octavian Purdila <octavian.purdila@intel.com> |
|---|---|
| Date | 2015-09-23 09:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbMF3-5Lu-5@gated-at.bofh.it> |
| In reply to | #1231118 |
On Wed, Sep 23, 2015 at 6:03 AM, Oliver Neukum <oneukum@suse.de> wrote: > > On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote: > > On Tue, 22 Sep 2015, Oliver Neukum wrote: > > > > > Cancel, yes, going to low power is a consequence which needn't bother > > > the power subsystem. > > > > Going to low power needn't involve the power subsystem? That sounds > > weird. > > Think of it like rfkill. It makes sense to suspend an rfkilled device. > It still is the job of the driver to report that its device is idle. > > > > You need a callback. If there are spurious > > > events, the current heuristics will keep devices awake. > > > You must discard them anyway, as they are spurious. There's no point > > > in transporting over the bus at all. We can cease IO for input. > > > > > > > This would create a parallel runtime-PM mechanism which is independent > > > > of the existing one. Is that really a good idea? > > > > > > It isn't strictly PM. It helps PM to do a better job, but > > > conceptually it is independent. > > > > So my next question is: _How_ can this help PM to do a better job? > > That is, what are the mechanisms? > > "inhibit" -> driver stops input -> driver sets PM count to zero > -> PM subsystem acts > > To go from the first to the second step a callback is needed > The IIO drivers use this model. The application keeps the fd open but there is a buffer enable switch to enable / disable input. Based on that trigger drivers use pm runtime put operations to induce PM idleness (and pm runtime get to wakeup the device). > > One you have already stated: Lack of spurious events will help prevent > > unwanted wakeups (or unwanted failures to go to sleep). > > That too. We also save CPU cycles. > > > But Dmitry made a stronger claim: Inhibiting an input device should > > allow the device to go to low power. I would like to know how we can > > implement this cleanly. The most straightforward approach is to use > > runtime PM, but it's not obvious how this can be made to work with the > > current API. > > Yes, we can use the current API. > The key is that you think of the mechanism as induced idleness, > not forced suspend. We already have a perfectly working mechanism > for suspending idle 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-23 17:00 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbTGx-7k3-9@gated-at.bofh.it> |
| In reply to | #1231118 |
On Wed, 23 Sep 2015, Oliver Neukum wrote:
> On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> >
> > > Cancel, yes, going to low power is a consequence which needn't bother
> > > the power subsystem.
> >
> > Going to low power needn't involve the power subsystem? That sounds
> > weird.
>
> Think of it like rfkill. It makes sense to suspend an rfkilled device.
> It still is the job of the driver to report that its device is idle.
Reporting that the device is idle _does_ involve the power subsystem.
But never mind...
> > So my next question is: _How_ can this help PM to do a better job?
> > That is, what are the mechanisms?
>
> "inhibit" -> driver stops input -> driver sets PM count to zero
> -> PM subsystem acts
Your third step here poses problems. There is no runtime-PM API a
driver or subsystem can use to set its usage counter to 0. All it can
do is increment or decrement the counter.
> To go from the first to the second step a callback is needed
>
> > One you have already stated: Lack of spurious events will help prevent
> > unwanted wakeups (or unwanted failures to go to sleep).
>
> That too. We also save CPU cycles.
>
> > But Dmitry made a stronger claim: Inhibiting an input device should
> > allow the device to go to low power. I would like to know how we can
> > implement this cleanly. The most straightforward approach is to use
> > runtime PM, but it's not obvious how this can be made to work with the
> > current API.
>
> Yes, we can use the current API.
> The key is that you think of the mechanism as induced idleness,
> not forced suspend. We already have a perfectly working mechanism
> for suspending idle devices.
After thinking some more about this, here's what I've got.
Let's talk about input-only devices being in an "idle" state or a
"running" state:
When the device is in the idle state, its driver does not
communicate with the device. In particular, the driver does
not monitor for events or report them to the rest of the
kernel. It is appropriate to put the device in runtime suspend
with remote wakeup disabled.
When the device is in the running state, its driver receives
event reports from the device and propagates them forward.
The subsystem/driver may choose to put the device in runtime
suspend between events with remote wakeup enabled (like we do
for USB keyboards if no LEDs are on) or it may choose to leave
the device at full power the whole time.
The idea is that a device is in the idle state whenever the open file
count is 0 _or_ it is "inhibited"; otherwise it is in the running
state.
I tried to come up with a way to do some of this work in a central
core. All I could think of was that the core should detect state
changes and inform the subsystem/driver when they occur. Everything
else (starting and stopping I/O, adjusting the runtime-PM usage
counter) would have to be done by the subsystem/driver.
The problem is that a core generally isn't aware of when a file
reference is opened or released. Only the driver is. Which means
there's nothing that the core can do here; the driver and subsystem
have to manage pretty much the whole thing. A simple example:
open()
{
mutex_lock(&dev->open_mutex);
if (dev->open_count++ == 0 && !dev->inhibited) {
pm_runtime_get_sync(dev);
start_io(dev);
}
mutex_unlock(&dev->open_mutex);
}
release()
{
mutex_lock(&dev->open_mutex);
if (--dev->open_count == 0 && !dev->inhibited) {
stop_io(dev);
pm_runtime_put(dev);
}
mutex_unlock(&dev->open_mutex);
}
inhibit()
{
mutex_lock(&dev->open_mutex);
dev->inhibited = true;
if (dev->open_count > 0) {
stop_io(dev);
pm_runtime_put(dev);
}
mutex_unlock(&dev->open_mutex);
}
uninhibit()
{
mutex_lock(&dev->open_mutex);
dev->inhibited = false;
if (dev->open_count > 0) {
pm_runtime_get_sync(dev);
start_io(dev);
}
mutex_unlock(&dev->open_mutex);
}
This doesn't leave much room for the PM core or anything else.
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]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-25 02:20 +0200 |
| Message-ID | <qcoU2-22j-5@gated-at.bofh.it> |
| In reply to | #1231490 |
On Wednesday, September 23, 2015 10:55:52 AM Alan Stern wrote:
> On Wed, 23 Sep 2015, Oliver Neukum wrote:
>
> > On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> > >
> > > > Cancel, yes, going to low power is a consequence which needn't bother
> > > > the power subsystem.
> > >
> > > Going to low power needn't involve the power subsystem? That sounds
> > > weird.
> >
> > Think of it like rfkill. It makes sense to suspend an rfkilled device.
> > It still is the job of the driver to report that its device is idle.
>
> Reporting that the device is idle _does_ involve the power subsystem.
> But never mind...
>
> > > So my next question is: _How_ can this help PM to do a better job?
> > > That is, what are the mechanisms?
> >
> > "inhibit" -> driver stops input -> driver sets PM count to zero
> > -> PM subsystem acts
>
> Your third step here poses problems. There is no runtime-PM API a
> driver or subsystem can use to set its usage counter to 0. All it can
> do is increment or decrement the counter.
>
> > To go from the first to the second step a callback is needed
> >
> > > One you have already stated: Lack of spurious events will help prevent
> > > unwanted wakeups (or unwanted failures to go to sleep).
> >
> > That too. We also save CPU cycles.
> >
> > > But Dmitry made a stronger claim: Inhibiting an input device should
> > > allow the device to go to low power. I would like to know how we can
> > > implement this cleanly. The most straightforward approach is to use
> > > runtime PM, but it's not obvious how this can be made to work with the
> > > current API.
> >
> > Yes, we can use the current API.
> > The key is that you think of the mechanism as induced idleness,
> > not forced suspend. We already have a perfectly working mechanism
> > for suspending idle devices.
>
> After thinking some more about this, here's what I've got.
>
> Let's talk about input-only devices being in an "idle" state or a
> "running" state:
>
> When the device is in the idle state, its driver does not
> communicate with the device. In particular, the driver does
> not monitor for events or report them to the rest of the
> kernel. It is appropriate to put the device in runtime suspend
> with remote wakeup disabled.
>
> When the device is in the running state, its driver receives
> event reports from the device and propagates them forward.
> The subsystem/driver may choose to put the device in runtime
> suspend between events with remote wakeup enabled (like we do
> for USB keyboards if no LEDs are on) or it may choose to leave
> the device at full power the whole time.
>
> The idea is that a device is in the idle state whenever the open file
> count is 0 _or_ it is "inhibited"; otherwise it is in the running
> state.
>
> I tried to come up with a way to do some of this work in a central
> core. All I could think of was that the core should detect state
> changes and inform the subsystem/driver when they occur. Everything
> else (starting and stopping I/O, adjusting the runtime-PM usage
> counter) would have to be done by the subsystem/driver.
>
> The problem is that a core generally isn't aware of when a file
> reference is opened or released. Only the driver is. Which means
> there's nothing that the core can do here; the driver and subsystem
> have to manage pretty much the whole thing. A simple example:
>
> open()
> {
> mutex_lock(&dev->open_mutex);
> if (dev->open_count++ == 0 && !dev->inhibited) {
> pm_runtime_get_sync(dev);
> start_io(dev);
> }
> mutex_unlock(&dev->open_mutex);
> }
>
> release()
> {
> mutex_lock(&dev->open_mutex);
> if (--dev->open_count == 0 && !dev->inhibited) {
> stop_io(dev);
> pm_runtime_put(dev);
> }
> mutex_unlock(&dev->open_mutex);
> }
>
> inhibit()
> {
> mutex_lock(&dev->open_mutex);
> dev->inhibited = true;
> if (dev->open_count > 0) {
> stop_io(dev);
> pm_runtime_put(dev);
> }
> mutex_unlock(&dev->open_mutex);
> }
>
> uninhibit()
> {
> mutex_lock(&dev->open_mutex);
> dev->inhibited = false;
> if (dev->open_count > 0) {
> pm_runtime_get_sync(dev);
> start_io(dev);
> }
> mutex_unlock(&dev->open_mutex);
> }
>
> This doesn't leave much room for the PM core or anything else.
We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup"
bit in struct dev_pm_info or something similar).
That is actually quite important, because (a) we can save energy but not
configuring the device to do remote wakeup in the first place and (b) that
may involve more than just the driver (for example, disabling PCI or ACPI
remote wakeup involves the bus type or similar).
So it looks like we need to be able to distinguish between "runtime suspend
with remote wakeup" and "runtime suspend without remote wakeup".
And if we do the latter, we may not even need the "inhibit" thing any more,
because suspended devices without that are not configured to do remote wakeup
cannot really signal anything in the majority of cases.
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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-25 16:40 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qcCki-4ao-13@gated-at.bofh.it> |
| In reply to | #1232502 |
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup" > bit in struct dev_pm_info or something similar). > > That is actually quite important, because (a) we can save energy but not > configuring the device to do remote wakeup in the first place and (b) that > may involve more than just the driver (for example, disabling PCI or ACPI > remote wakeup involves the bus type or similar). > > So it looks like we need to be able to distinguish between "runtime suspend > with remote wakeup" and "runtime suspend without remote wakeup". > > And if we do the latter, we may not even need the "inhibit" thing any more, > because suspended devices without that are not configured to do remote wakeup > cannot really signal anything in the majority of cases. That works only for drivers that use autosuspend to go to low power in between events. It doesn't work for drivers that remain at full power as long as the device file is open. That kind of driver does require an "inhibit" interface. 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]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-25 21:50 +0200 |
| Message-ID | <qcHah-2Fx-1@gated-at.bofh.it> |
| In reply to | #1232850 |
On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup" > > bit in struct dev_pm_info or something similar). > > > > That is actually quite important, because (a) we can save energy but not > > configuring the device to do remote wakeup in the first place and (b) that > > may involve more than just the driver (for example, disabling PCI or ACPI > > remote wakeup involves the bus type or similar). > > > > So it looks like we need to be able to distinguish between "runtime suspend > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > And if we do the latter, we may not even need the "inhibit" thing any more, > > because suspended devices without that are not configured to do remote wakeup > > cannot really signal anything in the majority of cases. > > That works only for drivers that use autosuspend to go to low power in > between events. It doesn't work for drivers that remain at full power > as long as the device file is open. That kind of driver does require > an "inhibit" interface. Or an interface allowing user space to trigger pm_request_idle() for them. So user space would change the "no remote wakeup" setting and then do the "try to suspend now" thing. 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-25 23:20 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qcIzo-4Ol-17@gated-at.bofh.it> |
| In reply to | #1233043 |
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > > > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup" > > > bit in struct dev_pm_info or something similar). > > > > > > That is actually quite important, because (a) we can save energy but not > > > configuring the device to do remote wakeup in the first place and (b) that > > > may involve more than just the driver (for example, disabling PCI or ACPI > > > remote wakeup involves the bus type or similar). > > > > > > So it looks like we need to be able to distinguish between "runtime suspend > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > And if we do the latter, we may not even need the "inhibit" thing any more, > > > because suspended devices without that are not configured to do remote wakeup > > > cannot really signal anything in the majority of cases. > > > > That works only for drivers that use autosuspend to go to low power in > > between events. It doesn't work for drivers that remain at full power > > as long as the device file is open. That kind of driver does require > > an "inhibit" interface. > > Or an interface allowing user space to trigger pm_request_idle() for them. > > So user space would change the "no remote wakeup" setting and then do the > "try to suspend now" thing. So something like: echo on >/sys/.../power/control (in case the device was already in runtime suspend with wakeups enabled) echo off >/sys/.../power/wakeup echo auto >/sys/.../power/control This should work. But it would require that the driver doesn't increment the usage counter when the device file is opened. I can imagine this might lead to trouble if you're dealing with hardware that doesn't support remote wakeup very well. The driver wouldn't be able to work around the hardware issue by incrementing the usage counter. In real life this might not be a serious issue. I don't know. 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]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-25 23:30 +0200 |
| Message-ID | <qcIJ4-50M-19@gated-at.bofh.it> |
| In reply to | #1233073 |
On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote: > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > > > > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup" > > > > bit in struct dev_pm_info or something similar). > > > > > > > > That is actually quite important, because (a) we can save energy but not > > > > configuring the device to do remote wakeup in the first place and (b) that > > > > may involve more than just the driver (for example, disabling PCI or ACPI > > > > remote wakeup involves the bus type or similar). > > > > > > > > So it looks like we need to be able to distinguish between "runtime suspend > > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > > > And if we do the latter, we may not even need the "inhibit" thing any more, > > > > because suspended devices without that are not configured to do remote wakeup > > > > cannot really signal anything in the majority of cases. > > > > > > That works only for drivers that use autosuspend to go to low power in > > > between events. It doesn't work for drivers that remain at full power > > > as long as the device file is open. That kind of driver does require > > > an "inhibit" interface. > > > > Or an interface allowing user space to trigger pm_request_idle() for them. > > > > So user space would change the "no remote wakeup" setting and then do the > > "try to suspend now" thing. > > So something like: > > echo on >/sys/.../power/control (in case the device was > already in runtime suspend with wakeups enabled) > echo off >/sys/.../power/wakeup > echo auto >/sys/.../power/control That, or there may be an additional value, say "aggressive", to write to the control file in which case it becomes just echo aggressive >/sys/.../power/control > > This should work. But it would require that the driver doesn't > increment the usage counter when the device file is opened. Right. > I can imagine this might lead to trouble if you're dealing with hardware that > doesn't support remote wakeup very well. The driver wouldn't be able > to work around the hardware issue by incrementing the usage counter. Or the "aggressive" mode wouldn't work for it. > In real life this might not be a serious issue. I don't know. Me neither. 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]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-26 00:40 +0200 |
| Message-ID | <qcJOO-6x2-9@gated-at.bofh.it> |
| In reply to | #1233075 |
On Friday, September 25, 2015 11:52:23 PM Rafael J. Wysocki wrote: > On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote: > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > > > > > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup" > > > > > bit in struct dev_pm_info or something similar). > > > > > > > > > > That is actually quite important, because (a) we can save energy but not > > > > > configuring the device to do remote wakeup in the first place and (b) that > > > > > may involve more than just the driver (for example, disabling PCI or ACPI > > > > > remote wakeup involves the bus type or similar). > > > > > > > > > > So it looks like we need to be able to distinguish between "runtime suspend > > > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > > > > > And if we do the latter, we may not even need the "inhibit" thing any more, > > > > > because suspended devices without that are not configured to do remote wakeup > > > > > cannot really signal anything in the majority of cases. > > > > > > > > That works only for drivers that use autosuspend to go to low power in > > > > between events. It doesn't work for drivers that remain at full power > > > > as long as the device file is open. That kind of driver does require > > > > an "inhibit" interface. > > > > > > Or an interface allowing user space to trigger pm_request_idle() for them. > > > > > > So user space would change the "no remote wakeup" setting and then do the > > > "try to suspend now" thing. > > > > So something like: > > > > echo on >/sys/.../power/control (in case the device was > > already in runtime suspend with wakeups enabled) > > echo off >/sys/.../power/wakeup > > echo auto >/sys/.../power/control > > That, or there may be an additional value, say "aggressive", to write to the > control file in which case it becomes just > > echo aggressive >/sys/.../power/control That said I suppose that the "off" value for the "wakeup" file might also be useful in some other cases, so it likely is a better 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-26 17:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qcZAd-3T8-11@gated-at.bofh.it> |
| In reply to | #1233098 |
On Sat, 26 Sep 2015, Rafael J. Wysocki wrote: > > > So something like: > > > > > > echo on >/sys/.../power/control (in case the device was > > > already in runtime suspend with wakeups enabled) > > > echo off >/sys/.../power/wakeup > > > echo auto >/sys/.../power/control Cases where the driver wants to avoid runtime suspend (while the device is active) because of bad wakeup support in the hardware can be handled easily enough. The runtime-idle or runtime-suspend callback routine can check whether wakeup == off; if it isn't then the callback should return -EBUSY. Thus the driver can prevent runtime suspend without any need to increment the usage counter. > > That, or there may be an additional value, say "aggressive", to write to the > > control file in which case it becomes just > > > > echo aggressive >/sys/.../power/control > > That said I suppose that the "off" value for the "wakeup" file might also be > useful in some other cases, so it likely is a better approach. We still need some sort of "inhibit" callback for cases where the driver doesn't want to go into runtime suspend but does want to turn off all I/O. Should this callback be triggered when the user writes "off" to power/wakeup, or when the user writes "inhibit" to power/control, or should there be a separate sysfs attribute? 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]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web