Skip to content

Commit c7c66c0

Browse files
torvaldstorvalds
committed
Merge tag 'pm-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management updates for 3.4 from Rafael Wysocki: "Assorted extensions and fixes including: * Introduction of early/late suspend/hibernation device callbacks. * Generic PM domains extensions and fixes. * devfreq updates from Axel Lin and MyungJoo Ham. * Device PM QoS updates. * Fixes of concurrency problems with wakeup sources. * System suspend and hibernation fixes." * tag 'pm-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (43 commits) PM / Domains: Check domain status during hibernation restore of devices PM / devfreq: add relation of recommended frequency. PM / shmobile: Make MTU2 driver use pm_genpd_dev_always_on() PM / shmobile: Make CMT driver use pm_genpd_dev_always_on() PM / shmobile: Make TMU driver use pm_genpd_dev_always_on() PM / Domains: Introduce "always on" device flag PM / Domains: Fix hibernation restore of devices, v2 PM / Domains: Fix handling of wakeup devices during system resume sh_mmcif / PM: Use PM QoS latency constraint tmio_mmc / PM: Use PM QoS latency constraint PM / QoS: Make it possible to expose PM QoS latency constraints PM / Sleep: JBD and JBD2 missing set_freezable() PM / Domains: Fix include for PM_GENERIC_DOMAINS=n case PM / Freezer: Remove references to TIF_FREEZE in comments PM / Sleep: Add more wakeup source initialization routines PM / Hibernate: Enable usermodehelpers in hibernate() error path PM / Sleep: Make __pm_stay_awake() delete wakeup source timers PM / Sleep: Fix race conditions related to wakeup source timer function PM / Sleep: Fix possible infinite loop during wakeup source destruction PM / Hibernate: print physical addresses consistently with other parts of kernel ...
2 parents 9f39383 + 98e8bda commit c7c66c0

Some content is hidden

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

53 files changed

+1452
-611
lines changed

‎Documentation/ABI/testing/sysfs-devices-power

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -165,3 +165,21 @@ Description:
165165

166166
Not all drivers support this attribute. If it isn't supported,
167167
attempts to read or write it will yield I/O errors.
168+
169+
What: /sys/devices/.../power/pm_qos_latency_us
170+
Date: March 2012
171+
Contact: Rafael J. Wysocki <rjw@sisk.pl>
172+
Description:
173+
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
174+
contains the PM QoS resume latency limit for the given device,
175+
which is the maximum allowed time it can take to resume the
176+
device, after it has been suspended at run time, from a resume
177+
request to the moment the device will be ready to process I/O,
178+
in microseconds. If it is equal to 0, however, this means that
179+
the PM QoS resume latency may be arbitrary.
180+
181+
Not all drivers support this attribute. If it isn't supported,
182+
it is not present.
183+
184+
This attribute has no effect on system-wide suspend/resume and
185+
hibernation.

‎Documentation/devicetree/bindings/arm/exynos/power_domain.txt

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
* Samsung Exynos Power Domains
2+
3+
Exynos processors include support for multiple power domains which are used
4+
to gate power to one or more peripherals on the processor.
5+
6+
Required Properties:
7+
- compatiable: should be one of the following.
8+
* samsung,exynos4210-pd - for exynos4210 type power domain.
9+
- reg: physical base address of the controller and length of memory mapped
10+
region.
11+
12+
Optional Properties:
13+
- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
14+
state during boot and remains to be turned-off until explicitly turned-on.
15+
16+
Example:
17+
18+
lcd0: power-domain-lcd0 {
19+
compatible = "samsung,exynos4210-pd";
20+
reg = <0x10023C00 0x10>;
21+
};

‎Documentation/power/devices.txt

Lines changed: 61 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -96,6 +96,12 @@ struct dev_pm_ops {
9696
int (*thaw)(struct device *dev);
9797
int (*poweroff)(struct device *dev);
9898
int (*restore)(struct device *dev);
99+
int (*suspend_late)(struct device *dev);
100+
int (*resume_early)(struct device *dev);
101+
int (*freeze_late)(struct device *dev);
102+
int (*thaw_early)(struct device *dev);
103+
int (*poweroff_late)(struct device *dev);
104+
int (*restore_early)(struct device *dev);
99105
int (*suspend_noirq)(struct device *dev);
100106
int (*resume_noirq)(struct device *dev);
101107
int (*freeze_noirq)(struct device *dev);
@@ -305,7 +311,7 @@ Entering System Suspend
305311
-----------------------
306312
When the system goes into the standby or memory sleep state, the phases are:
307313

308-
prepare, suspend, suspend_noirq.
314+
prepare, suspend, suspend_late, suspend_noirq.
309315

310316
1. The prepare phase is meant to prevent races by preventing new devices
311317
from being registered; the PM core would never know that all the
@@ -324,7 +330,12 @@ When the system goes into the standby or memory sleep state, the phases are:
324330
appropriate low-power state, depending on the bus type the device is on,
325331
and they may enable wakeup events.
326332

327-
3. The suspend_noirq phase occurs after IRQ handlers have been disabled,
333+
3 For a number of devices it is convenient to split suspend into the
334+
"quiesce device" and "save device state" phases, in which cases
335+
suspend_late is meant to do the latter. It is always executed after
336+
runtime power management has been disabled for all devices.
337+
338+
4. The suspend_noirq phase occurs after IRQ handlers have been disabled,
328339
which means that the driver's interrupt handler will not be called while
329340
the callback method is running. The methods should save the values of
330341
the device's registers that weren't saved previously and finally put the
@@ -359,7 +370,7 @@ Leaving System Suspend
359370
----------------------
360371
When resuming from standby or memory sleep, the phases are:
361372

362-
resume_noirq, resume, complete.
373+
resume_noirq, resume_early, resume, complete.
363374

364375
1. The resume_noirq callback methods should perform any actions needed
365376
before the driver's interrupt handlers are invoked. This generally
@@ -375,14 +386,18 @@ When resuming from standby or memory sleep, the phases are:
375386
device driver's ->pm.resume_noirq() method to perform device-specific
376387
actions.
377388

378-
2. The resume methods should bring the the device back to its operating
389+
2. The resume_early methods should prepare devices for the execution of
390+
the resume methods. This generally involves undoing the actions of the
391+
preceding suspend_late phase.
392+
393+
3 The resume methods should bring the the device back to its operating
379394
state, so that it can perform normal I/O. This generally involves
380395
undoing the actions of the suspend phase.
381396

382-
3. The complete phase uses only a bus callback. The method should undo the
383-
actions of the prepare phase. Note, however, that new children may be
384-
registered below the device as soon as the resume callbacks occur; it's
385-
not necessary to wait until the complete phase.
397+
4. The complete phase should undo the actions of the prepare phase. Note,
398+
however, that new children may be registered below the device as soon as
399+
the resume callbacks occur; it's not necessary to wait until the
400+
complete phase.
386401

387402
At the end of these phases, drivers should be as functional as they were before
388403
suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are
@@ -429,8 +444,8 @@ an image of the system memory while everything is stable, reactivate all
429444
devices (thaw), write the image to permanent storage, and finally shut down the
430445
system (poweroff). The phases used to accomplish this are:
431446

432-
prepare, freeze, freeze_noirq, thaw_noirq, thaw, complete,
433-
prepare, poweroff, poweroff_noirq
447+
prepare, freeze, freeze_late, freeze_noirq, thaw_noirq, thaw_early,
448+
thaw, complete, prepare, poweroff, poweroff_late, poweroff_noirq
434449

435450
1. The prepare phase is discussed in the "Entering System Suspend" section
436451
above.
@@ -441,40 +456,51 @@ system (poweroff). The phases used to accomplish this are:
441456
save time it's best not to do so. Also, the device should not be
442457
prepared to generate wakeup events.
443458

444-
3. The freeze_noirq phase is analogous to the suspend_noirq phase discussed
459+
3. The freeze_late phase is analogous to the suspend_late phase described
460+
above, except that the device should not be put in a low-power state and
461+
should not be allowed to generate wakeup events by it.
462+
463+
4. The freeze_noirq phase is analogous to the suspend_noirq phase discussed
445464
above, except again that the device should not be put in a low-power
446465
state and should not be allowed to generate wakeup events.
447466

448467
At this point the system image is created. All devices should be inactive and
449468
the contents of memory should remain undisturbed while this happens, so that the
450469
image forms an atomic snapshot of the system state.
451470

452-
4. The thaw_noirq phase is analogous to the resume_noirq phase discussed
471+
5. The thaw_noirq phase is analogous to the resume_noirq phase discussed
453472
above. The main difference is that its methods can assume the device is
454473
in the same state as at the end of the freeze_noirq phase.
455474

456-
5. The thaw phase is analogous to the resume phase discussed above. Its
475+
6. The thaw_early phase is analogous to the resume_early phase described
476+
above. Its methods should undo the actions of the preceding
477+
freeze_late, if necessary.
478+
479+
7. The thaw phase is analogous to the resume phase discussed above. Its
457480
methods should bring the device back to an operating state, so that it
458481
can be used for saving the image if necessary.
459482

460-
6. The complete phase is discussed in the "Leaving System Suspend" section
483+
8. The complete phase is discussed in the "Leaving System Suspend" section
461484
above.
462485

463486
At this point the system image is saved, and the devices then need to be
464487
prepared for the upcoming system shutdown. This is much like suspending them
465488
before putting the system into the standby or memory sleep state, and the phases
466489
are similar.
467490

468-
7. The prepare phase is discussed above.
491+
9. The prepare phase is discussed above.
492+
493+
10. The poweroff phase is analogous to the suspend phase.
469494

470-
8. The poweroff phase is analogous to the suspend phase.
495+
11. The poweroff_late phase is analogous to the suspend_late phase.
471496

472-
9. The poweroff_noirq phase is analogous to the suspend_noirq phase.
497+
12. The poweroff_noirq phase is analogous to the suspend_noirq phase.
473498

474-
The poweroff and poweroff_noirq callbacks should do essentially the same things
475-
as the suspend and suspend_noirq callbacks. The only notable difference is that
476-
they need not store the device register values, because the registers should
477-
already have been stored during the freeze or freeze_noirq phases.
499+
The poweroff, poweroff_late and poweroff_noirq callbacks should do essentially
500+
the same things as the suspend, suspend_late and suspend_noirq callbacks,
501+
respectively. The only notable difference is that they need not store the
502+
device register values, because the registers should already have been stored
503+
during the freeze, freeze_late or freeze_noirq phases.
478504

479505

480506
Leaving Hibernation
@@ -518,22 +544,25 @@ To achieve this, the image kernel must restore the devices' pre-hibernation
518544
functionality. The operation is much like waking up from the memory sleep
519545
state, although it involves different phases:
520546

521-
restore_noirq, restore, complete
547+
restore_noirq, restore_early, restore, complete
522548

523549
1. The restore_noirq phase is analogous to the resume_noirq phase.
524550

525-
2. The restore phase is analogous to the resume phase.
551+
2. The restore_early phase is analogous to the resume_early phase.
552+
553+
3. The restore phase is analogous to the resume phase.
526554

527-
3. The complete phase is discussed above.
555+
4. The complete phase is discussed above.
528556

529-
The main difference from resume[_noirq] is that restore[_noirq] must assume the
530-
device has been accessed and reconfigured by the boot loader or the boot kernel.
531-
Consequently the state of the device may be different from the state remembered
532-
from the freeze and freeze_noirq phases. The device may even need to be reset
533-
and completely re-initialized. In many cases this difference doesn't matter, so
534-
the resume[_noirq] and restore[_norq] method pointers can be set to the same
535-
routines. Nevertheless, different callback pointers are used in case there is a
536-
situation where it actually matters.
557+
The main difference from resume[_early|_noirq] is that restore[_early|_noirq]
558+
must assume the device has been accessed and reconfigured by the boot loader or
559+
the boot kernel. Consequently the state of the device may be different from the
560+
state remembered from the freeze, freeze_late and freeze_noirq phases. The
561+
device may even need to be reset and completely re-initialized. In many cases
562+
this difference doesn't matter, so the resume[_early|_noirq] and
563+
restore[_early|_norq] method pointers can be set to the same routines.
564+
Nevertheless, different callback pointers are used in case there is a situation
565+
where it actually does matter.
537566

538567

539568
Device Power Management Domains

‎Documentation/power/freezing-of-tasks.txt

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -63,6 +63,27 @@ devices have been reinitialized, the function thaw_processes() is called in
6363
order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
6464
have been frozen leave __refrigerator() and continue running.
6565

66+
67+
Rationale behind the functions dealing with freezing and thawing of tasks:
68+
-------------------------------------------------------------------------
69+
70+
freeze_processes():
71+
- freezes only userspace tasks
72+
73+
freeze_kernel_threads():
74+
- freezes all tasks (including kernel threads) because we can't freeze
75+
kernel threads without freezing userspace tasks
76+
77+
thaw_kernel_threads():
78+
- thaws only kernel threads; this is particularly useful if we need to do
79+
anything special in between thawing of kernel threads and thawing of
80+
userspace tasks, or if we want to postpone the thawing of userspace tasks
81+
82+
thaw_processes():
83+
- thaws all tasks (including kernel threads) because we can't thaw userspace
84+
tasks without thawing kernel threads
85+
86+
6687
III. Which kernel threads are freezable?
6788

6889
Kernel threads are not freezable by default. However, a kernel thread may clear

‎arch/arm/mach-exynos/Kconfig

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,7 @@ config CPU_EXYNOS4210
3434
select ARM_CPU_SUSPEND if PM
3535
select S5P_PM if PM
3636
select S5P_SLEEP if PM
37+
select PM_GENERIC_DOMAINS
3738
help
3839
Enable EXYNOS4210 CPU support
3940

@@ -74,11 +75,6 @@ config EXYNOS4_SETUP_FIMD0
7475
help
7576
Common setup code for FIMD0.
7677

77-
config EXYNOS4_DEV_PD
78-
bool
79-
help
80-
Compile in platform device definitions for Power Domain
81-
8278
config EXYNOS4_DEV_SYSMMU
8379
bool
8480
help
@@ -195,7 +191,6 @@ config MACH_SMDKV310
195191
select EXYNOS4_DEV_AHCI
196192
select SAMSUNG_DEV_KEYPAD
197193
select EXYNOS4_DEV_DMA
198-
select EXYNOS4_DEV_PD
199194
select SAMSUNG_DEV_PWM
200195
select EXYNOS4_DEV_USB_OHCI
201196
select EXYNOS4_DEV_SYSMMU
@@ -243,7 +238,6 @@ config MACH_UNIVERSAL_C210
243238
select S5P_DEV_ONENAND
244239
select S5P_DEV_TV
245240
select EXYNOS4_DEV_DMA
246-
select EXYNOS4_DEV_PD
247241
select EXYNOS4_SETUP_FIMD0
248242
select EXYNOS4_SETUP_I2C1
249243
select EXYNOS4_SETUP_I2C3
@@ -277,7 +271,6 @@ config MACH_NURI
277271
select S5P_DEV_USB_EHCI
278272
select S5P_SETUP_MIPIPHY
279273
select EXYNOS4_DEV_DMA
280-
select EXYNOS4_DEV_PD
281274
select EXYNOS4_SETUP_FIMC
282275
select EXYNOS4_SETUP_FIMD0
283276
select EXYNOS4_SETUP_I2C1
@@ -310,7 +303,6 @@ config MACH_ORIGEN
310303
select SAMSUNG_DEV_BACKLIGHT
311304
select SAMSUNG_DEV_PWM
312305
select EXYNOS4_DEV_DMA
313-
select EXYNOS4_DEV_PD
314306
select EXYNOS4_DEV_USB_OHCI
315307
select EXYNOS4_SETUP_FIMD0
316308
select EXYNOS4_SETUP_SDHCI

‎arch/arm/mach-exynos/Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@ obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
1717
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
1818

1919
obj-$(CONFIG_PM) += pm.o
20+
obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
2021
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
2122

2223
obj-$(CONFIG_ARCH_EXYNOS4) += pmu.o
@@ -45,7 +46,6 @@ obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
4546

4647
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
4748
obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
48-
obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
4949
obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
5050
obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
5151
obj-$(CONFIG_EXYNOS4_DEV_DMA) += dma.o

0 commit comments

Comments
 (0)