Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1715980
| From | Lukas Wunner <lukas@wunner.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states |
| Date | 2017-08-20 20:30 +0200 |
| Message-ID | <ugD90-22z-9@gated-at.bofh.it> (permalink) |
| References | <ugB7b-Nn-3@gated-at.bofh.it> <ugB7b-Nn-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sun, Aug 20, 2017 at 06:05:05PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Reorganize the power management part of admin-guide by adding a > description of major power management strategies supported by the > kernel (system-wide and working-state power management) to it and > dividing the rest of the material into the system-wide PM and > working-state PM chapters. > > On top of that, add a description of system sleep states to the > system-wide PM chapter. Found no typos and no factual inaccuracies, the only thing that irritated me a bit was the part about "working state" power management: > +The other strategy, referred to as the > +:doc:`working-state power management <working-state>`, is based on adjusting the > +power states of individual hardware components of the system, as needed, in the > +working state. In consequence, if this strategy is in use, the working state > +of the system usually does not correspond to any particular physical > +configuration of it, but can be treated as a metastate covering a range of > +different power states of the system in which the individual components of it > +can be either ``active`` (in use) or ``inactive`` (idle). If they are active, > +they have to be in power states allowing them to process data and to be accessed > +by software. In turn, if they are inactive, they are expected to be in > +low-power states in which they may not be accessible. > + > +If all of the system components are active, the system as a whole is regarded as > +``runtime active`` and that situation typically corresponds to the maximum power > +draw (or maximum energy usage) of it. If all of them are inactive, the system > +as a whole is regarded as ``runtime idle`` which may be very close to a sleep The code uses the terms pm_runtime_active() and pm_runtime_suspended(), not "runtime idle". Taking the ->runtime_idle callback as guidance, "runtime idle" would mean that a component is runtime active, but idling and could thus be transitioned to runtime suspended state. However above it says that if it's idle, it's already "in low-power states and may not be accessible". For someone reading this it may be difficult to reconcile it with the terminology used in the code. Otherwise, Reviewed-by: Lukas Wunner <lukas@wunner.de> Thanks, Lukas
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-20 18:20 +0200
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states Lukas Wunner <lukas@wunner.de> - 2017-08-20 20:30 +0200
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states "Rafael J. Wysocki" <rafael@kernel.org> - 2017-08-21 03:00 +0200
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states Markus Heiser <markus.heiser@darmarit.de> - 2017-08-21 12:00 +0200
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states "Rafael J. Wysocki" <rafael@kernel.org> - 2017-08-21 14:00 +0200
[PATCH v2 1/2] PM: docs: Describe high-level PM strategies and sleep states "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-21 15:30 +0200
csiph-web