Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1234140
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| Date | 2015-09-28 15:20 +0200 |
| Message-ID | <qdGvv-6My-3@gated-at.bofh.it> (permalink) |
| References | <qdl7H-1k0-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web