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 | 14 on this page of 34 — 11 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 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 2 — ← Prev page 1 [2]
| 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 | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2015-09-21 22:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qbfSO-rd-5@gated-at.bofh.it> |
| In reply to | #1229433 |
On Mon 2015-09-21 10:38:46, 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? Well... once upon a time, it was kernel job to mask differences between different hardware platforms. In a way, the hardware is "buggy" -- if your mouse clicked randomly when you were not holding it in your hand it would be buggy... and it would be nice for kernel to fix that "bug". 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]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-08 16:50 +0200 |
| Subject | RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6snD-7de-17@gated-at.bofh.it> |
| In reply to | #1220438 |
On Tue, 8 Sep 2015, Tirdea, Irina wrote: > 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 > 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? > > Thank you, > Irina > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 Purely as a matter of interest, in that email Rafael also mentioned that he and I had discussed a way to disable remote wakeup during runtime suspend. Oddly enough, the method we decided upon was to add an "off" option to /sys/.../power/control. :-) It would not put the device into runtime suspend immediately, like you are proposing. Instead it would mean the same as the "auto" mode, except that remote wakeup should be disabled during runtime suspend. We never got around to implementing this, however. 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-08 16:50 +0200 |
| Message-ID | <q6snE-7de-37@gated-at.bofh.it> |
| In reply to | #1220895 |
On Tuesday, September 08, 2015 10:44:04 AM Alan Stern wrote: > On Tue, 8 Sep 2015, Tirdea, Irina wrote: > > > 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 > > 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? > > > > Thank you, > > Irina > > > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 > > Purely as a matter of interest, in that email Rafael also mentioned > that he and I had discussed a way to disable remote wakeup during > runtime suspend. Oddly enough, the method we decided upon was to add > an "off" option to /sys/.../power/control. :-) Wasn't that /sys/devices/.../power/wakeup rather? > It would not put the device into runtime suspend immediately, like you > are proposing. Instead it would mean the same as the "auto" mode, > except that remote wakeup should be disabled during runtime suspend. > > We never got around to implementing this, however. I don't think this is what we discussed then really. There is a fundamental problem with forcing things into runtime suspend from user space, because that may happen in a wrong time. In other words, the kernel can't guarantee that the device would actually be able to go into runtime suspend when requested. 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-08 17:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6sGZ-7Px-7@gated-at.bofh.it> |
| In reply to | #1220900 |
On Tue, 8 Sep 2015, Rafael J. Wysocki wrote: > > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 > > > > Purely as a matter of interest, in that email Rafael also mentioned > > that he and I had discussed a way to disable remote wakeup during > > runtime suspend. Oddly enough, the method we decided upon was to add > > an "off" option to /sys/.../power/control. :-) > > Wasn't that /sys/devices/.../power/wakeup rather? Not the way I remember. Of course, it's possible that we misunderstood each other at the time. > > It would not put the device into runtime suspend immediately, like you > > are proposing. Instead it would mean the same as the "auto" mode, > > except that remote wakeup should be disabled during runtime suspend. > > > > We never got around to implementing this, however. > > I don't think this is what we discussed then really. > > There is a fundamental problem with forcing things into runtime suspend > from user space, because that may happen in a wrong time. In other words, > the kernel can't guarantee that the device would actually be able to go > into runtime suspend when requested. Exactly. What we discussed at LinuxCon wasn't forcing things into runtime suspend; it was disabling remote wakeup during runtime suspend. And even though the topic was quite different from Irina's proposal, we ended up settling on the same API (according to my recollection). 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" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-08 22:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6xGH-6yx-21@gated-at.bofh.it> |
| In reply to | #1220912 |
Hi, On Tue, Sep 8, 2015 at 5:00 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Tue, 8 Sep 2015, Rafael J. Wysocki wrote: > >> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 >> > >> > Purely as a matter of interest, in that email Rafael also mentioned >> > that he and I had discussed a way to disable remote wakeup during >> > runtime suspend. Oddly enough, the method we decided upon was to add >> > an "off" option to /sys/.../power/control. :-) >> >> Wasn't that /sys/devices/.../power/wakeup rather? > > Not the way I remember. Of course, it's possible that we misunderstood > each other at the time. > >> > It would not put the device into runtime suspend immediately, like you >> > are proposing. Instead it would mean the same as the "auto" mode, >> > except that remote wakeup should be disabled during runtime suspend. >> > >> > We never got around to implementing this, however. >> >> I don't think this is what we discussed then really. >> >> There is a fundamental problem with forcing things into runtime suspend >> from user space, because that may happen in a wrong time. In other words, >> the kernel can't guarantee that the device would actually be able to go >> into runtime suspend when requested. > > Exactly. What we discussed at LinuxCon wasn't forcing things into > runtime suspend; it was disabling remote wakeup during runtime suspend. > > And even though the topic was quite different from Irina's proposal, we > ended up settling on the same API (according to my recollection). So I remember that differently. My idea was to add a third value to /sys/devices/.../power/wakeup (in addition to "disabled" and "enabled") so user space can indicate that remote wakeup should not be enabled for runtime suspend for the device (since there's no way to indicate that today). I don't see how /sys/devices/.../power/control might help here to be honest. 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-09 17:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6PtW-717-61@gated-at.bofh.it> |
| In reply to | #1221070 |
On Tue, 8 Sep 2015, Rafael J. Wysocki wrote: > Hi, > > On Tue, Sep 8, 2015 at 5:00 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Tue, 8 Sep 2015, Rafael J. Wysocki wrote: > > > >> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 > >> > > >> > Purely as a matter of interest, in that email Rafael also mentioned > >> > that he and I had discussed a way to disable remote wakeup during > >> > runtime suspend. Oddly enough, the method we decided upon was to add > >> > an "off" option to /sys/.../power/control. :-) > >> > >> Wasn't that /sys/devices/.../power/wakeup rather? > > > > Not the way I remember. Of course, it's possible that we misunderstood > > each other at the time. > > > >> > It would not put the device into runtime suspend immediately, like you > >> > are proposing. Instead it would mean the same as the "auto" mode, > >> > except that remote wakeup should be disabled during runtime suspend. > >> > > >> > We never got around to implementing this, however. > >> > >> I don't think this is what we discussed then really. > >> > >> There is a fundamental problem with forcing things into runtime suspend > >> from user space, because that may happen in a wrong time. In other words, > >> the kernel can't guarantee that the device would actually be able to go > >> into runtime suspend when requested. > > > > Exactly. What we discussed at LinuxCon wasn't forcing things into > > runtime suspend; it was disabling remote wakeup during runtime suspend. > > > > And even though the topic was quite different from Irina's proposal, we > > ended up settling on the same API (according to my recollection). > > So I remember that differently. > > My idea was to add a third value to /sys/devices/.../power/wakeup (in > addition to "disabled" and "enabled") so user space can indicate that > remote wakeup should not be enabled for runtime suspend for the device > (since there's no way to indicate that today). I don't see how > /sys/devices/.../power/control might help here to be honest. You're right, that does make more sense than what I was thinking. My memory must have gotten messed up. RAM corruption, no doubt... I think I need an EDAC brain. :-) 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.com> |
|---|---|
| Date | 2015-09-09 08:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6H3k-3e8-9@gated-at.bofh.it> |
| In reply to | #1220895 |
On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote: > It would not put the device into runtime suspend immediately, like you > are proposing. Instead it would mean the same as the "auto" mode, > except that remote wakeup should be disabled during runtime suspend. Hi, this proposal is incomplete. If you don't want remote wakeup you imply that input is no longer needed or possible. If that is already known, we can just as well inform the driver, so that it can cease IO for input. Yet that is not necessarily the only scenario. For example if you run a screensaver, you might not care for where the user touches the screen, but the event as such is valuable. 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-09 16:40 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <q6OHw-5QY-9@gated-at.bofh.it> |
| In reply to | #1221269 |
On Wed, 9 Sep 2015, Oliver Neukum wrote: > On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote: > > It would not put the device into runtime suspend immediately, like you > > are proposing. Instead it would mean the same as the "auto" mode, > > except that remote wakeup should be disabled during runtime suspend. > > Hi, > > this proposal is incomplete. If you don't want remote wakeup you > imply that input is no longer needed or possible. If that is > already known, we can just as well inform the driver, so that > it can cease IO for input. Like I said, it was never implemented. For that reason, it was never completely fleshed out. > Yet that is not necessarily the only scenario. For example > if you run a screensaver, you might not care for where the > user touches the screen, but the event as such is valuable. I suspect it's not worth the effort to distinguish between getting an event with all the details and merely knowing that an event occurred. 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] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web