linux.git/drivers/base/power/main.c, branch v3.15

Merge branch 'pm-cpufreq'

2014-03-20T12:26:12+00:00

* pm-cpufreq: (30 commits)
  intel_pstate: Set core to min P state during core offline
  cpufreq: Add stop CPU callback to cpufreq_driver interface
  cpufreq: Remove unnecessary braces
  cpufreq: Fix checkpatch errors and warnings
  cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs
  cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}
  cpufreq: Do not allow ->setpolicy drivers to provide ->target
  cpufreq: arm_big_little: set 'physical_cluster' for each CPU
  cpufreq: arm_big_little: make vexpress driver depend on bL core driver
  cpufreq: SPEAr: Instantiate as platform_driver
  cpufreq: Remove unnecessary variable/parameter 'frozen'
  cpufreq: Remove cpufreq_generic_exit()
  cpufreq: add 'freq_table' in struct cpufreq_policy
  cpufreq: Reformat printk() statements
  cpufreq: Tegra: Use cpufreq_generic_suspend()
  cpufreq: s5pv210: Use cpufreq_generic_suspend()
  cpufreq: exynos: Use cpufreq_generic_suspend()
  cpufreq: Implement cpufreq_generic_suspend()
  cpufreq: suspend governors on system suspend/hibernate
  cpufreq: move call to __find_governor() to cpufreq_init_policy()
  ...

cpufreq: suspend governors on system suspend/hibernate

2014-03-06T14:04:12+00:00

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where the
tunables configuration for clusters/sockets with non-boot CPUs was
lost after system suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last CPU for that policy
which caused the tunables memory to be freed.

This is fixed by preventing any governor operations from being
carried out between the device suspend and device resume stages of
system suspend and resume, respectively.

We could have added these callbacks at dpm_{suspend|resume}_noirq()
level, but there is an additional problem that the majority of I/O
devices is already suspended at that point and if cpufreq drivers
want to change the frequency before suspending, then that not be
possible on some platforms (which depend on peripherals like i2c,
regulators, etc).

Reported-and-tested-by: Lan Tianyu 
Reported-by: Jinhyuk Choi 
Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

PM / sleep: Asynchronous threads for suspend_late

2014-02-20T00:30:09+00:00

In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_late
time significantly.

This patch is for suspend_late phase.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Rafael J. Wysocki

PM / sleep: Asynchronous threads for suspend_noirq

2014-02-20T00:30:09+00:00

In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_noirq
time significantly.

This patch is for suspend_noirq phase.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Rafael J. Wysocki

PM / sleep: Asynchronous threads for resume_early

2014-02-20T00:30:09+00:00

In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_early
time significantly.

This patch is for resume_early phase.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Rafael J. Wysocki

PM / sleep: Asynchronous threads for resume_noirq

2014-02-20T00:30:09+00:00

In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_noirq time
significantly.

One typical case is:
In resume_noirq phase and for the PCI devices, the function
pci_pm_resume_noirq() will be called, and there is one d3_delay
(10ms) at least.

With the way of asynchronous threads, we just need wait d3_delay
time once in parallel for each calling, which saves much time to
resume quickly.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Rafael J. Wysocki

PM / sleep: Two flags for async suspend_noirq and suspend_late

2014-02-20T00:30:08+00:00

The patch is a helper adding two new flags for implementing
async threads for suspend_noirq and suspend_late.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Rafael J. Wysocki

Revert "cpufreq: suspend governors on system suspend/hibernate"

2013-12-08T00:04:17+00:00

Commit 5a87182aa21d (cpufreq: suspend governors on system
suspend/hibernate) causes hibernation problems to happen on
Bjørn Mork's and Paul Bolle's systems, so revert it.

Fixes: 5a87182aa21d (cpufreq: suspend governors on system suspend/hibernate)
Reported-by: Bjørn Mork 
Reported-by: Paul Bolle 
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-cpuidle' and 'pm-cpufreq'

2013-12-06T01:17:59+00:00

* pm-cpuidle:
  cpuidle: Check for dev before deregistering it.
  intel_idle: Fixed C6 state on Avoton/Rangeley processors

* pm-cpufreq:
  cpufreq: fix garbage kobjects on errors during suspend/resume
  cpufreq: suspend governors on system suspend/hibernate

cpufreq: suspend governors on system suspend/hibernate

2013-11-28T13:47:31+00:00

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}_noirq()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found anr issue where
tunables configuration for clusters/sockets with non-boot CPUs was
getting lost after suspend/resume, as we were notifying governors
with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that
policy and so deallocating memory for tunables. This is fixed by
this patch as we don't allow any operation on governors after
device suspend and before device resume now.

Reported-and-tested-by: Lan Tianyu 
Reported-by: Jinhyuk Choi 
Signed-off-by: Viresh Kumar 
[rjw: Changelog, minor cleanups]
Signed-off-by: Rafael J. Wysocki