kernel/linux.git/drivers/base/power/main.c, branch v4.0.8

PM / Sleep: fix async suspend_late/freeze_late error handling

2014-10-27T17:42:26+00:00

If an asynchronous suspend_late or freeze_late callback fails during the SUSPEND, FREEZE or QUIESCE phases, we don't propagate the corresponding error correctly, in effect ignoring the error and continuing the suspend-to-ram/hibernation. During suspend-to-ram this could leave some devices without a valid saved context, leading to a failure to reinitialize them during resume. During hibernation this could leave some devices active interfeering with the creation / restoration of the hibernation image. Also this could leave the corresponding devices without a valid saved context and failure to reinitialize them during resume. Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late) Signed-off-by: Imre Deak Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki

PM / sleep: Export dpm_suspend_late/noirq() and dpm_resume_early/noirq()

2014-09-30T19:05:59+00:00

Subsequent change sets will add platform-related operations between dpm_suspend_late() and dpm_suspend_noirq() as well as between dpm_resume_noirq() and dpm_resume_early() in suspend_enter(), so export these functions for suspend_enter() to be able to call them separately and split the invocations of dpm_suspend_end() and dpm_resume_start() in there accordingly. Signed-off-by: Rafael J. Wysocki

PM / sleep: fix kernel-doc warnings in drivers/base/power/main.c

2014-07-28T23:32:50+00:00

Fix kernel-doc warnings in drivers/base/power/main.c: Warning(..//drivers/base/power/main.c:473): No description found for parameter 'async' Warning(..//drivers/base/power/main.c:601): No description found for parameter 'async' Warning(..//drivers/base/power/main.c:1012): No description found for parameter 'async' Warning(..//drivers/base/power/main.c:1151): No description found for parameter 'async' Warning(..//drivers/base/power/main.c:1305): No description found for parameter 'info' Signed-off-by: Randy Dunlap Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki

PM / sleep: trace events for device PM callbacks

2014-06-11T00:16:48+00:00

Adds two trace events which supply the same info that initcall_debug provides, but via ftrace instead of dmesg. The existing initcall_debug calls require the pm_print_times_enabled var to be set (either via sysfs or via the kernel cmd line). The new trace events provide all the same info as the initcall_debug prints but with less overhead, and also with coverage of device prepare and complete device callbacks. These events replace the device_pm_report_time event (which has been removed). device_pm_callback_start is called first and provides the device and callback info. device_pm_callback_end is called after with the device name and error info. The time and pid are gathered from the trace data headers. Signed-off-by: Todd Brandt Signed-off-by: Rafael J. Wysocki

PM / sleep: trace events for suspend/resume

2014-06-06T22:18:07+00:00

Adds trace events that give finer resolution into suspend/resume. These events are graphed in the timelines generated by the analyze_suspend.py script. They represent large areas of time consumed that are typical to suspend and resume. The event is triggered by calling the function "trace_suspend_resume" with three arguments: a string (the name of the event to be displayed in the timeline), an integer (case specific number, such as the power state or cpu number), and a boolean (where true is used to denote the start of the timeline event, and false to denote the end). The suspend_resume trace event reproduces the data that the machine_suspend trace event did, so the latter has been removed. Signed-off-by: Todd Brandt Acked-by: Steven Rostedt Signed-off-by: Rafael J. Wysocki

PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily

2014-05-16T21:15:44+00:00

Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to resume all runtime-suspended devices during system suspend, mostly because those devices may need to be reprogrammed due to different wakeup settings for system sleep and for runtime PM. For some devices, though, it's OK to remain in runtime suspend throughout a complete system suspend/resume cycle (if the device was in runtime suspend at the start of the cycle). We would like to do this whenever possible, to avoid the overhead of extra power-up and power-down events. However, problems may arise because the device's descendants may require it to be at full power at various points during the cycle. Therefore the most straightforward way to do this safely is if the device and all its descendants can remain runtime suspended until the complete stage of system resume. To this end, introduce a new device PM flag, power.direct_complete and modify the PM core to use that flag as follows. If the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. It will then check if the system power transition in progress is a suspend (and not hibernation in particular) and if the device is, indeed, runtime-suspended. In that case, the PM core will set the device's power.direct_complete flag. Otherwise it will clear power.direct_complete for the device and it also will later clear it for the device's parent (if there's one). Next, the PM core will not invoke the ->suspend() ->suspend_late(), ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume() callbacks for all devices having power.direct_complete set. It will invoke their ->complete() callbacks, however, and those callbacks are then responsible for resuming the devices as appropriate, if necessary. For example, in some cases they may need to queue up runtime resume requests for the devices using pm_request_resume(). Changelog partly based on an Alan Stern's description of the idea (http://marc.info/?l=linux-pm&m=139940466625569&w=2). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern

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