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 | 17 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 3 of 3 — ← Prev page 1 2 [3]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-27 15:20 +0200 |
| Message-ID | <qdk1Y-8ek-15@gated-at.bofh.it> |
| In reply to | #1233215 |
On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote: > 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. Right. > > > 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? My first thought is that if there is a separate attribute, then it only actually makes sense for devices that generate input events, while the "off" thing may be generally useful in principle (eg. it may indicate to disable PME for the device to the PCI layer etc). OTOH, the additional "inhibit" attribute may only be exposed if the corresponding callback is present, so I'm not really sure. Question is, though, what's the use case for turning off I/O when we don't go into runtime suspend. After all, runtime suspend need not mean putting the device into any kind of low-power state and the "off" thing may very well be defined to mean that all input is discarded if the device is runtime-suspended and the device is not configured to do remote wakeup then. 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-27 16:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qdl7H-1k0-7@gated-at.bofh.it> |
| In reply to | #1233660 |
On Sun, 27 Sep 2015, Rafael J. Wysocki wrote: > On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote: > > 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 > > 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? > > My first thought is that if there is a separate attribute, then it only actually > makes sense for devices that generate input events, while the "off" thing may > be generally useful in principle (eg. it may indicate to disable PME for the > device to the PCI layer etc). I'm not sure how much sense that distinction makes. It seems to me the only time you want to ignore potential wakeup events is if you want to ignore _all_ input. Which is basically what "inhibit" means. This suggests we forget about power/wakeup == "off" and introduce an "inhibit" attribute instead. > OTOH, the additional "inhibit" attribute may only be exposed if the corresponding > callback is present, so I'm not really sure. It could be a separate attribute, or it could be a new entry for power/control. Come to think of it, a separate attribute might be better. Otherwise we would lose track of whether runtime suspend was permitted (the "on" vs. "auto" distinction) when the device was inhibited. I can imagine someone might want to forbid runtime suspend but still inhibit a device. However, I agree that there's no point registering a separate attribute or accepting a write of "inhibit" to power/control if there's no corresponding callback. > Question is, though, what's the use case for turning off I/O when we don't > go into runtime suspend. After all, runtime suspend need not mean putting > the device into any kind of low-power state and the "off" thing may very > well be defined to mean that all input is discarded if the device is > runtime-suspended and the device is not configured to do remote wakeup > then. Well, I suppose there might be a driver that supports inhibit but doesn't support runtime PM, unlikely as that seems. Or the driver might support both but the user might leave power/control == "on" while inhibiting the 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 | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-28 15:20 +0200 |
| Message-ID | <qdGvv-6My-3@gated-at.bofh.it> |
| In reply to | #1233677 |
On Sunday, September 27, 2015 10:27:25 AM Alan Stern wrote: > On Sun, 27 Sep 2015, Rafael J. Wysocki wrote: > > > On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote: > > > 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 > > > > 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? > > > > My first thought is that if there is a separate attribute, then it only actually > > makes sense for devices that generate input events, while the "off" thing may > > be generally useful in principle (eg. it may indicate to disable PME for the > > device to the PCI layer etc). > > I'm not sure how much sense that distinction makes. It seems to me the > only time you want to ignore potential wakeup events is if you want to > ignore _all_ input. Which is basically what "inhibit" means. The other case I had in mind is specific to the PCI layer and might be better served by adding an "ignore PME" flag to PCI devices. > This suggests we forget about power/wakeup == "off" and introduce an > "inhibit" attribute instead. If we do that, can it still be regarded as a PM attribute? And what about the corresponding callback? Should that be a PM callback or a general one? > > OTOH, the additional "inhibit" attribute may only be exposed if the corresponding > > callback is present, so I'm not really sure. > > It could be a separate attribute, or it could be a new entry for > power/control. Come to think of it, a separate attribute might be > better. Otherwise we would lose track of whether runtime suspend was > permitted (the "on" vs. "auto" distinction) when the device was > inhibited. I can imagine someone might want to forbid runtime suspend > but still inhibit a device. > > However, I agree that there's no point registering a separate attribute > or accepting a write of "inhibit" to power/control if there's no > corresponding callback. > > > Question is, though, what's the use case for turning off I/O when we don't > > go into runtime suspend. After all, runtime suspend need not mean putting > > the device into any kind of low-power state and the "off" thing may very > > well be defined to mean that all input is discarded if the device is > > runtime-suspended and the device is not configured to do remote wakeup > > then. > > Well, I suppose there might be a driver that supports inhibit but > doesn't support runtime PM, unlikely as that seems. Or the driver > might support both but the user might leave power/control == "on" while > inhibiting the device. That sounds like a general rather than PM-related mechanism then. I guess we need a real use case for that last thing or it will be rather difficult to convince Greg to accept the patch. :-) 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-28 16:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qdHBh-21o-37@gated-at.bofh.it> |
| In reply to | #1234140 |
On Mon, 28 Sep 2015, Rafael J. Wysocki wrote: > > This suggests we forget about power/wakeup == "off" and introduce an > > "inhibit" attribute instead. > > If we do that, can it still be regarded as a PM attribute? Why not? Consider this: Is there any reason to support inhibit when CONFIG_PM is disabled? I can't come up with any. > And what about the corresponding callback? Should that be a PM callback or > a general one? Well, if "inhibit" is a PM attribute then the callback should be a PM callback. :-) > > > Question is, though, what's the use case for turning off I/O when we don't > > > go into runtime suspend. After all, runtime suspend need not mean putting > > > the device into any kind of low-power state and the "off" thing may very > > > well be defined to mean that all input is discarded if the device is > > > runtime-suspended and the device is not configured to do remote wakeup > > > then. > > > > Well, I suppose there might be a driver that supports inhibit but > > doesn't support runtime PM, unlikely as that seems. Or the driver > > might support both but the user might leave power/control == "on" while > > inhibiting the device. > > That sounds like a general rather than PM-related mechanism then. I don't follow your reasoning. > I guess we need a real use case for that last thing or it will be rather > difficult to convince Greg to accept the patch. :-) The hard part is to come up with a design that Greg agrees with. If the design is okay, there's no reason not to accept the patch. One of the questions amounts to this: Do we want to allow situations where input is inhibited but the user prevents the device from going into runtime suspend by setting power/control = "on"? If the answer is Yes then "inhibit" should be a separate attribute. Otherwise, we can just let "inhibit" be another setting in power/control. Another question is: Do we want to make it easy for drivers to support inhibit while still incrementing their PM usage counter every time the device file is opened? If we do then inhibit must be considered separate from runtime suspend, because a device _can't_ go directly into runtime suspend when the usage counter is > 1. If we don't then we will most likely have to change the runtime-PM support in some drivers before they can implement inhibit. 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-28 22:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qdMUj-1fb-35@gated-at.bofh.it> |
| In reply to | #1234209 |
Hi Alan, On Mon, Sep 28, 2015 at 4:29 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Mon, 28 Sep 2015, Rafael J. Wysocki wrote: > >> > This suggests we forget about power/wakeup == "off" and introduce an >> > "inhibit" attribute instead. >> >> If we do that, can it still be regarded as a PM attribute? > > Why not? Consider this: Is there any reason to support inhibit when > CONFIG_PM is disabled? I can't come up with any. Well, the "I don't want any input from you now, because the phone is going into a pocket" case? It isn't stticlty dependent on PM. >> And what about the corresponding callback? Should that be a PM callback or >> a general one? > > Well, if "inhibit" is a PM attribute then the callback should be a PM > callback. :-) > >> > > Question is, though, what's the use case for turning off I/O when we don't >> > > go into runtime suspend. After all, runtime suspend need not mean putting >> > > the device into any kind of low-power state and the "off" thing may very >> > > well be defined to mean that all input is discarded if the device is >> > > runtime-suspended and the device is not configured to do remote wakeup >> > > then. >> > >> > Well, I suppose there might be a driver that supports inhibit but >> > doesn't support runtime PM, unlikely as that seems. Or the driver >> > might support both but the user might leave power/control == "on" while >> > inhibiting the device. >> >> That sounds like a general rather than PM-related mechanism then. > > I don't follow your reasoning. Support for "inhibit" and lack of runtime PM support means that the feature has nothing to do with PM any more AFAICS. That's why I think it may be regarded by more than just PM. It should make runtime PM behave in a specific way if supported, but then it should work withot it too, shouldn't it? >> I guess we need a real use case for that last thing or it will be rather >> difficult to convince Greg to accept the patch. :-) > > The hard part is to come up with a design that Greg agrees with. If > the design is okay, there's no reason not to accept the patch. > > One of the questions amounts to this: Do we want to allow situations > where input is inhibited but the user prevents the device from going > into runtime suspend by setting power/control = "on"? If the answer is > Yes then "inhibit" should be a separate attribute. Otherwise, we can > just let "inhibit" be another setting in power/control. I think that the answer really is "yes" in general as long as it makes sense to discard input without closing the device. My understanding of "inhibit" would be "discard all input including any wakeup events from now on". It would be quite natural for runtime suspend to trigger if that is set (unless disabled or not supported, of course), but I don't think that this should be a requirement. > Another question is: Do we want to make it easy for drivers to support > inhibit while still incrementing their PM usage counter every time the > device file is opened? If we do then inhibit must be considered > separate from runtime suspend, because a device _can't_ go directly > into runtime suspend when the usage counter is > 1. If we don't then > we will most likely have to change the runtime-PM support in some > drivers before they can implement inhibit. My opinion is that "inhibit" should affect PM, but should not require PM to function (there's no technical reason for that). 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-28 22:30 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qdNdE-1FC-17@gated-at.bofh.it> |
| In reply to | #1234412 |
On Mon, 28 Sep 2015, Rafael J. Wysocki wrote: > Hi Alan, > > On Mon, Sep 28, 2015 at 4:29 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Mon, 28 Sep 2015, Rafael J. Wysocki wrote: > > > >> > This suggests we forget about power/wakeup == "off" and introduce an > >> > "inhibit" attribute instead. > >> > >> If we do that, can it still be regarded as a PM attribute? > > > > Why not? Consider this: Is there any reason to support inhibit when > > CONFIG_PM is disabled? I can't come up with any. > > Well, the "I don't want any input from you now, because the phone is > going into a pocket" case? But who would make a phone without CONFIG_PM? If you're sufficiently unconcerned about power usage that you turn off CONFIG_PM, then you probably don't care about getting excess input events either. > It isn't stticlty dependent on PM. No, not strictly. But it is closely enough related that people shouldn't mind if it becomes part of the PM code. > >> > Well, I suppose there might be a driver that supports inhibit but > >> > doesn't support runtime PM, unlikely as that seems. Or the driver > >> > might support both but the user might leave power/control == "on" while > >> > inhibiting the device. > >> > >> That sounds like a general rather than PM-related mechanism then. > > > > I don't follow your reasoning. > > Support for "inhibit" and lack of runtime PM support means that the > feature has nothing to do with PM any more AFAICS. My example above referred to support in a single driver, not support in the system as a whole. By the same reasoning, since some drivers support system sleep but not runtime PM, system sleep must have nothing to do with PM. :-) > That's why I think it may be regarded by more than just PM. It should > make runtime PM behave in a specific way if supported, but then it > should work withot it too, shouldn't it? If you want inhibit to be part of the device core rather than the PM core, that's okay with me. > My opinion is that "inhibit" should affect PM, but should not require > PM to function (there's no technical reason for that). All right. Then a design should be straightforward. 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 | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2015-10-04 17:20 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qfTeW-44S-9@gated-at.bofh.it> |
| In reply to | #1234425 |
Hi! > > > > > >> > This suggests we forget about power/wakeup == "off" and introduce an > > >> > "inhibit" attribute instead. > > >> > > >> If we do that, can it still be regarded as a PM attribute? > > > > > > Why not? Consider this: Is there any reason to support inhibit when > > > CONFIG_PM is disabled? I can't come up with any. > > > > Well, the "I don't want any input from you now, because the phone is > > going into a pocket" case? > > But who would make a phone without CONFIG_PM? If you're sufficiently > unconcerned about power usage that you turn off CONFIG_PM, then you > probably don't care about getting excess input events either. Well.. .excess input events means that your phone now sends (meaningful, thanks to advanced predictions) messages to your friends... Better not do that. 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 | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2015-09-27 19:10 +0200 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Message-ID | <qdnCz-4YT-21@gated-at.bofh.it> |
| In reply to | #1233660 |
Hi! > > > > 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? > > My first thought is that if there is a separate attribute, then it only actually > makes sense for devices that generate input events, while the "off" thing may > be generally useful in principle (eg. it may indicate to disable PME for the > device to the PCI layer etc). > > OTOH, the additional "inhibit" attribute may only be exposed if the corresponding > callback is present, so I'm not really sure. > > Question is, though, what's the use case for turning off I/O when we don't > go into runtime suspend. After all, runtime suspend need not mean putting Well... In "cellphone goes to pocket" case, you want to turn off I/O even if the touchscreen can not support runtime suspend. See parents in the thread for explanation. Pavel -- 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-28 15:20 +0200 |
| Message-ID | <qdGvw-6My-27@gated-at.bofh.it> |
| In reply to | #1233711 |
On Sunday, September 27, 2015 07:02:17 PM Pavel Machek wrote: > Hi! Hi, > > > > > 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? > > > > My first thought is that if there is a separate attribute, then it only actually > > makes sense for devices that generate input events, while the "off" thing may > > be generally useful in principle (eg. it may indicate to disable PME for the > > device to the PCI layer etc). > > > > OTOH, the additional "inhibit" attribute may only be exposed if the corresponding > > callback is present, so I'm not really sure. > > > > Question is, though, what's the use case for turning off I/O when we don't > > go into runtime suspend. After all, runtime suspend need not mean putting > > Well... In "cellphone goes to pocket" case, you want to turn off I/O even if > the touchscreen can not support runtime suspend. > > See parents in the thread for explanation. You seem to be confusing the ability to go into low-power states with supporting runtime PM. The latter by no means requires the former. Also "cellphone goes to pocket" is really two different cases. One is when the user indicated "I'm not going to use the phone going forward" somehow (like by pressing a screen-off button) and one is when (s)he didn't. In the second case we really have no reason to discard any input and in the first one we may as well go straight for runtime suspend (or even for system suspend for that matter). 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 | 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 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web