Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1230103 > unrolled thread
| Started by | Oliver Neukum <oneukum@suse.com> |
|---|---|
| First post | 2015-09-22 14:10 +0200 |
| Last post | 2015-09-28 15:20 +0200 |
| Articles | 3 on this page of 23 — 7 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 2 of 2 — ← Prev page 1 [2]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2015-10-04 17:20 +0200 |
| 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 |
| 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 |
| Subject | Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend |
| 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] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web