Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings
forked fromtorvalds/linux

Commit7f3fdd4

Browse files
committed
Merge tag 'pm-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management updates from Rafael Wysocki: "This includes some infrastructure changes in the PM core, mostly related to integration between runtime PM and system-wide suspend and hibernation, plus some driver changes depending on them and fixes for issues in that area which have become quite apparent recently. Also included are changes making more x86-based systems use the Low Power Sleep S0 _DSM interface by default, which turned out to be necessary to handle power button wakeups from suspend-to-idle on Surface Pro3. On the cpufreq front we have fixes and cleanups in the core, some new hardware support, driver updates and the removal of some unused code from the CPU cooling thermal driver. Apart from this, the Operating Performance Points (OPP) framework is prepared to be used with power domains in the future and there is a usual bunch of assorted fixes and cleanups. Specifics: - Define a PM driver flag allowing drivers to request that their devices be left in suspend after system-wide transitions to the working state if possible and add support for it to the PCI bus type and the ACPI PM domain (Rafael Wysocki). - Make the PM core carry out optimizations for devices with driver PM flags set in some cases and make a few drivers set those flags (Rafael Wysocki). - Fix and clean up wrapper routines allowing runtime PM device callbacks to be re-used for system-wide PM, change the generic power domains (genpd) framework to stop using those routines incorrectly and fix up a driver depending on that behavior of genpd (Rafael Wysocki, Ulf Hansson, Geert Uytterhoeven). - Fix and clean up the PM core's device wakeup framework and re-factor system-wide PM core code related to device wakeup (Rafael Wysocki, Ulf Hansson, Brian Norris). - Make more x86-based systems use the Low Power Sleep S0 _DSM interface by default (to fix power button wakeup from suspend-to-idle on Surface Pro3) and add a kernel command line switch to tell it to ignore the system sleep blacklist in the ACPI core (Rafael Wysocki). - Fix a race condition related to cpufreq governor module removal and clean up the governor management code in the cpufreq core (Rafael Wysocki). - Drop the unused generic code related to the handling of the static power energy usage model in the CPU cooling thermal driver along with the corresponding documentation (Viresh Kumar). - Add mt2712 support to the Mediatek cpufreq driver (Andrew-sh Cheng). - Add a new operating point to the imx6ul and imx6q cpufreq drivers and switch the latter to using clk_bulk_get() (Anson Huang, Dong Aisheng). - Add support for multiple regulators to the TI cpufreq driver along with a new DT binding related to that and clean up that driver somewhat (Dave Gerlach). - Fix a powernv cpufreq driver regression leading to incorrect CPU frequency reporting, fix that driver to deal with non-continguous P-states correctly and clean it up (Gautham Shenoy, Shilpasri Bhat). - Add support for frequency scaling on Armada 37xx SoCs through the generic DT cpufreq driver (Gregory CLEMENT). - Fix error code paths in the mvebu cpufreq driver (Gregory CLEMENT). - Fix a transition delay setting regression in the longhaul cpufreq driver (Viresh Kumar). - Add Skylake X (server) support to the intel_pstate cpufreq driver and clean up that driver somewhat (Srinivas Pandruvada). - Clean up the cpufreq statistics collection code (Viresh Kumar). - Drop cluster terminology and dependency on physical_package_id from the PSCI driver and drop dependency on arm_big_little from the SCPI cpufreq driver (Sudeep Holla). - Add support for system-wide suspend and resume to the RAPL power capping driver and drop a redundant semicolon from it (Zhen Han, Luis de Bethencourt). - Make SPI domain validation (in the SCSI SPI transport driver) and system-wide suspend mutually exclusive as they rely on the same underlying mechanism and cannot be carried out at the same time (Bart Van Assche). - Fix the computation of the amount of memory to preallocate in the hibernation core and clean up one function in there (Rainer Fiebig, Kyungsik Lee). - Prepare the Operating Performance Points (OPP) framework for being used with power domains and clean up one function in it (Viresh Kumar, Wei Yongjun). - Clean up the generic sysfs interface for device PM (Andy Shevchenko). - Fix several minor issues in power management frameworks and clean them up a bit (Arvind Yadav, Bjorn Andersson, Geert Uytterhoeven, Gustavo Silva, Julia Lawall, Luis de Bethencourt, Paul Gortmaker, Sergey Senozhatsky, gaurav jindal). - Make it easier to disable PM via Kconfig (Mark Brown). - Clean up the cpupower and intel_pstate_tracer utilities (Doug Smythies, Laura Abbott)"* tag 'pm-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (89 commits) PCI / PM: Remove spurious semicolon cpufreq: scpi: remove arm_big_little dependency drivers: psci: remove cluster terminology and dependency on physical_package_id powercap: intel_rapl: Fix trailing semicolon dmaengine: rcar-dmac: Make DMAC reinit during system resume explicit PM / runtime: Allow no callbacks in pm_runtime_force_suspend|resume() PM / hibernate: Drop unused parameter of enough_swap PM / runtime: Check ignore_children in pm_runtime_need_not_resume() PM / runtime: Rework pm_runtime_force_suspend/resume() PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume() cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin cpufreq: intel_pstate: Add Skylake servers support cpufreq: intel_pstate: Replace bxt_funcs with core_funcs platform/x86: surfacepro3: Support for wakeup from suspend-to-idle ACPI / PM: Use Low Power S0 Idle on more systems PM / wakeup: Print warn if device gets enabled as wakeup source during sleep PM / domains: Don't skip driver's ->suspend|resume_noirq() callbacks PM / core: Propagate wakeup_path status flag in __device_suspend_late() PM / core: Re-structure code for clearing the direct_complete flag powercap: add suspend and resume mechanism for SOC power limit ...
2 parents1c1f395 +ee43730 commit7f3fdd4

File tree

67 files changed

+2310
-1099
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

67 files changed

+2310
-1099
lines changed

‎Documentation/admin-guide/kernel-parameters.txt‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -223,7 +223,7 @@
223223

224224
acpi_sleep=[HW,ACPI] Sleep options
225225
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
226-
old_ordering, nonvs, sci_force_enable }
226+
old_ordering, nonvs, sci_force_enable, nobl }
227227
See Documentation/power/video.txt for information on
228228
s3_bios and s3_mode.
229229
s3_beep is for debugging; it makes the PC's speaker beep
@@ -239,6 +239,9 @@
239239
sci_force_enable causes the kernel to set SCI_EN directly
240240
on resume from S1/S3 (which is against the ACPI spec,
241241
but some broken systems don't work without it).
242+
nobl causes the internal blacklist of systems known to
243+
behave incorrectly in some ways with respect to system
244+
suspend and resume to be ignored (use wisely).
242245

243246
acpi_use_timer_override [HW,ACPI]
244247
Use timer override. For some broken Nvidia NF5 boards

‎Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt‎

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,3 +14,22 @@ following property before the previous one:
1414
Example:
1515

1616
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
17+
18+
19+
Power management
20+
----------------
21+
22+
For power management (particularly DVFS and AVS), the North Bridge
23+
Power Management component is needed:
24+
25+
Required properties:
26+
- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
27+
- reg : the register start and length for the North Bridge
28+
Power Management
29+
30+
Example:
31+
32+
nb_pm: syscon@14000 {
33+
compatible = "marvell,armada-3700-nb-pm", "syscon";
34+
reg = <0x14000 0x60>;
35+
}

‎Documentation/devicetree/bindings/opp/opp.txt‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,11 @@ Devices supporting OPPs must set their "operating-points-v2" property with
4545
phandle to a OPP table in their DT node. The OPP core will use this phandle to
4646
find the operating points for the device.
4747

48+
This can contain more than one phandle for power domain providers that provide
49+
multiple power domains. That is, one phandle for each power domain. If only one
50+
phandle is available, then the same OPP table will be used for all power domains
51+
provided by the power domain provider.
52+
4853
If required, this can be extended for SoC vendor specific bindings. Such bindings
4954
should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
5055
and should have a compatible description like: "operating-points-v2-<vendor>".
@@ -154,6 +159,14 @@ Optional properties:
154159

155160
- status: Marks the node enabled/disabled.
156161

162+
- required-opp: This contains phandle to an OPP node in another device's OPP
163+
table. It may contain an array of phandles, where each phandle points to an
164+
OPP of a different device. It should not contain multiple phandles to the OPP
165+
nodes in the same OPP table. This specifies the minimum required OPP of the
166+
device(s), whose OPP's phandle is present in this property, for the
167+
functioning of the current device at the current OPP (where this property is
168+
present).
169+
157170
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
158171

159172
/ {
Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
Texas Instruments OMAP compatible OPP supply description
2+
3+
OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
4+
contain data that can be used to adjust voltages programmed for some of their
5+
supplies for more efficient operation. This binding provides the information
6+
needed to read these values and use them to program the main regulator during
7+
an OPP transitions.
8+
9+
Also, some supplies may have an associated vbb-supply which is an Adaptive Body
10+
Bias regulator which much be transitioned in a specific sequence with regards
11+
to the vdd-supply and clk when making an OPP transition. By supplying two
12+
regulators to the device that will undergo OPP transitions we can make use
13+
of the multi regulator binding that is part of the OPP core described here [1]
14+
to describe both regulators needed by the platform.
15+
16+
[1] Documentation/devicetree/bindings/opp/opp.txt
17+
18+
Required Properties for Device Node:
19+
- vdd-supply: phandle to regulator controlling VDD supply
20+
- vbb-supply: phandle to regulator controlling Body Bias supply
21+
(Usually Adaptive Body Bias regulator)
22+
23+
Required Properties for opp-supply node:
24+
- compatible: Should be one of:
25+
"ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
26+
"ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
27+
along with VBB
28+
"ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
29+
but no VBB.
30+
- reg: Address and length of the efuse register set for the device (mandatory
31+
only for "ti,omap5-opp-supply")
32+
- ti,efuse-settings: An array of u32 tuple items providing information about
33+
optimized efuse configuration. Each item consists of the following:
34+
volt: voltage in uV - reference voltage (OPP voltage)
35+
efuse_offseet: efuse offset from reg where the optimized voltage is stored.
36+
- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
37+
38+
Example:
39+
40+
/* Device Node (CPU) */
41+
cpus {
42+
cpu0: cpu@0 {
43+
device_type = "cpu";
44+
45+
...
46+
47+
vdd-supply = <&vcc>;
48+
vbb-supply = <&abb_mpu>;
49+
};
50+
};
51+
52+
/* OMAP OPP Supply with Class0 registers */
53+
opp_supply_mpu: opp_supply@4a003b20 {
54+
compatible = "ti,omap5-opp-supply";
55+
reg = <0x4a003b20 0x8>;
56+
ti,efuse-settings = <
57+
/* uV offset */
58+
1060000 0x0
59+
1160000 0x4
60+
1210000 0x8
61+
>;
62+
ti,absolute-max-voltage-uv = <1500000>;
63+
};

‎Documentation/devicetree/bindings/power/power_domain.txt‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,12 @@ Optional properties:
4040
domain's idle states. In the absence of this property, the domain would be
4141
considered as capable of being powered-on or powered-off.
4242

43+
- operating-points-v2 : Phandles to the OPP tables of power domains provided by
44+
a power domain provider. If the provider provides a single power domain only
45+
or all the power domains provided by the provider have identical OPP tables,
46+
then this shall contain a single phandle. Refer to ../opp/opp.txt for more
47+
information.
48+
4349
Example:
4450

4551
power: power-controller@12340000 {
@@ -120,4 +126,63 @@ The node above defines a typical PM domain consumer device, which is located
120126
inside a PM domain with index 0 of a power controller represented by a node
121127
with the label "power".
122128

129+
Optional properties:
130+
- required-opp: This contains phandle to an OPP node in another device's OPP
131+
table. It may contain an array of phandles, where each phandle points to an
132+
OPP of a different device. It should not contain multiple phandles to the OPP
133+
nodes in the same OPP table. This specifies the minimum required OPP of the
134+
device(s), whose OPP's phandle is present in this property, for the
135+
functioning of the current device at the current OPP (where this property is
136+
present).
137+
138+
Example:
139+
- OPP table for domain provider that provides two domains.
140+
141+
domain0_opp_table: opp-table0 {
142+
compatible = "operating-points-v2";
143+
144+
domain0_opp_0: opp-1000000000 {
145+
opp-hz = /bits/ 64 <1000000000>;
146+
opp-microvolt = <975000 970000 985000>;
147+
};
148+
domain0_opp_1: opp-1100000000 {
149+
opp-hz = /bits/ 64 <1100000000>;
150+
opp-microvolt = <1000000 980000 1010000>;
151+
};
152+
};
153+
154+
domain1_opp_table: opp-table1 {
155+
compatible = "operating-points-v2";
156+
157+
domain1_opp_0: opp-1200000000 {
158+
opp-hz = /bits/ 64 <1200000000>;
159+
opp-microvolt = <975000 970000 985000>;
160+
};
161+
domain1_opp_1: opp-1300000000 {
162+
opp-hz = /bits/ 64 <1300000000>;
163+
opp-microvolt = <1000000 980000 1010000>;
164+
};
165+
};
166+
167+
power: power-controller@12340000 {
168+
compatible = "foo,power-controller";
169+
reg = <0x12340000 0x1000>;
170+
#power-domain-cells = <1>;
171+
operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
172+
};
173+
174+
leaky-device0@12350000 {
175+
compatible = "foo,i-leak-current";
176+
reg = <0x12350000 0x1000>;
177+
power-domains = <&power 0>;
178+
required-opp = <&domain0_opp_0>;
179+
};
180+
181+
leaky-device1@12350000 {
182+
compatible = "foo,i-leak-current";
183+
reg = <0x12350000 0x1000>;
184+
power-domains = <&power 1>;
185+
required-opp = <&domain1_opp_1>;
186+
};
187+
123188
[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt

‎Documentation/driver-api/pm/devices.rst‎

Lines changed: 44 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -777,17 +777,51 @@ The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in
777777
runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
778778
suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
779779
has been disabled for it, under the assumption that its state should not change
780-
after that point until the system-wide transition is over. If that happens, the
781-
driver's system-wide resume callbacks, if present, may still be invoked during
782-
the subsequent system-wide resume transition and the device's runtime power
783-
management status may be set to "active" before enabling runtime PM for it,
784-
so the driver must be prepared to cope with the invocation of its system-wide
785-
resume callbacks back-to-back with its ``->runtime_suspend`` one (without the
786-
intervening ``->runtime_resume`` and so on) and the final state of the device
787-
must reflect the "active" status for runtime PM in that case.
780+
after that point until the system-wide transition is over (the PM core itself
781+
does that for devices whose "noirq", "late" and "early" system-wide PM callbacks
782+
are executed directly by it). If that happens, the driver's system-wide resume
783+
callbacks, if present, may still be invoked during the subsequent system-wide
784+
resume transition and the device's runtime power management status may be set
785+
to "active" before enabling runtime PM for it, so the driver must be prepared to
786+
cope with the invocation of its system-wide resume callbacks back-to-back with
787+
its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
788+
so on) and the final state of the device must reflect the "active" runtime PM
789+
status in that case.
788790

789791
During system-wide resume from a sleep state it's easiest to put devices into
790792
the full-power state, as explained in:file:`Documentation/power/runtime_pm.txt`.
791-
Refer to that document for more information regarding this particular issue as
793+
[Refer to that document for more information regarding this particular issue as
792794
well as for information on the device runtime power management framework in
793-
general.
795+
general.]
796+
797+
However, it often is desirable to leave devices in suspend after system
798+
transitions to the working state, especially if those devices had been in
799+
runtime suspend before the preceding system-wide suspend (or analogous)
800+
transition. Device drivers can use the ``DPM_FLAG_LEAVE_SUSPENDED`` flag to
801+
indicate to the PM core (and middle-layer code) that they prefer the specific
802+
devices handled by them to be left suspended and they have no problems with
803+
skipping their system-wide resume callbacks for this reason. Whether or not the
804+
devices will actually be left in suspend may depend on their state before the
805+
given system suspend-resume cycle and on the type of the system transition under
806+
way. In particular, devices are not left suspended if that transition is a
807+
restore from hibernation, as device states are not guaranteed to be reflected
808+
by the information stored in the hibernation image in that case.
809+
810+
The middle-layer code involved in the handling of the device is expected to
811+
indicate to the PM core if the device may be left in suspend by setting its
812+
:c:member:`power.may_skip_resume` status bit which is checked by the PM core
813+
during the "noirq" phase of the preceding system-wide suspend (or analogous)
814+
transition. The middle layer is then responsible for handling the device as
815+
appropriate in its "noirq" resume callback, which is executed regardless of
816+
whether or not the device is left suspended, but the other resume callbacks
817+
(except for ``->complete``) will be skipped automatically by the PM core if the
818+
device really can be left in suspend.
819+
820+
For devices whose "noirq", "late" and "early" driver callbacks are invoked
821+
directly by the PM core, all of the system-wide resume callbacks are skipped if
822+
``DPM_FLAG_LEAVE_SUSPENDED`` is set and the device is in runtime suspend during
823+
the ``suspend_noirq`` (or analogous) phase or the transition under way is a
824+
proper system suspend (rather than anything related to hibernation) and the
825+
device's wakeup settings are suitable for runtime PM (that is, it cannot
826+
generate wakeup signals at all or it is allowed to wake up the system from
827+
sleep).

‎Documentation/power/pci.txt‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -994,6 +994,17 @@ into D0 going forward), but if it is in runtime suspend in pci_pm_thaw_noirq(),
994994
the function will set the power.direct_complete flag for it (to make the PM core
995995
skip the subsequent "thaw" callbacks for it) and return.
996996

997+
Setting the DPM_FLAG_LEAVE_SUSPENDED flag means that the driver prefers the
998+
device to be left in suspend after system-wide transitions to the working state.
999+
This flag is checked by the PM core, but the PCI bus type informs the PM core
1000+
which devices may be left in suspend from its perspective (that happens during
1001+
the "noirq" phase of system-wide suspend and analogous transitions) and next it
1002+
uses the dev_pm_may_skip_resume() helper to decide whether or not to return from
1003+
pci_pm_resume_noirq() early, as the PM core will skip the remaining resume
1004+
callbacks for the device during the transition under way and will set its
1005+
runtime PM status to "suspended" if dev_pm_may_skip_resume() returns "true" for
1006+
it.
1007+
9971008
3.2. Device Runtime Power Management
9981009
------------------------------------
9991010
In addition to providing device power management callbacks PCI device drivers

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp