- 11 11月, 2016 1 次提交
-
-
由 Brian Norris 提交于
Consider two devices, A and B, where B is a child of A, and B utilizes asynchronous suspend (it does not matter whether A is sync or async). If B fails to suspend_noirq() or suspend_late(), or is interrupted by a wakeup (pm_wakeup_pending()), then it aborts and sets the async_error variable. However, device A does not (immediately) check the async_error variable; it may continue to run its own suspend_noirq()/suspend_late() callback. This is bad. We can resolve this problem by doing our error and wakeup checking (particularly, for the async_error flag) after waiting for children to suspend, instead of before. This also helps align the logic for the noirq and late suspend cases with the logic in __device_suspend(). It's easy to observe this erroneous behavior by, for example, forcing a device to sleep a bit in its suspend_noirq() (to ensure the parent is waiting for the child to complete), then return an error, and watch the parent suspend_noirq() still get called. (Or similarly, fake a wakeup event at the right (or is it wrong?) time.) Fixes: de377b39 (PM / sleep: Asynchronous threads for suspend_late) Fixes: 28b6fd6e (PM / sleep: Asynchronous threads for suspend_noirq) Reported-by: NJeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 5月, 2016 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Grygorii Strashko reports: The PM runtime will be left disabled for the device if its .suspend_late() callback fails and async suspend is not allowed for this device. In this case device will not be added in dpm_late_early_list and dpm_resume_early() will ignore this device, as result PM runtime will be disabled for it forever (side effect: after 8 subsequent failures for the same device the PM runtime will be reenabled due to disable_depth overflow). To fix this problem, add devices to dpm_late_early_list regardless of whether or not device_suspend_late() returns errors for them. That will ensure failures in there to be handled consistently for all devices regardless of their async suspend/resume status. Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com> Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: All applicable <stable@vger.kernel.org>
-
- 28 4月, 2016 1 次提交
-
-
由 Thierry Reding 提交于
Commit 32e8d689 (PM / sleep: trace_device_pm_callback coverage in dpm_prepare/complete) removed all users of this variable but forgot to remove the variable itself. Signed-off-by: NThierry Reding <treding@nvidia.com> [ rjw: Subject ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 1月, 2016 1 次提交
-
-
由 Tomeu Vizoso 提交于
If a suitable prepare callback cannot be found for a given device and its driver has no PM callbacks at all, assume that it can go direct to complete when the system goes to sleep. The reason for this is that there's lots of devices in a system that do no PM at all and there's no reason for them to prevent their ancestors to do direct_complete if they can support it. Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 11月, 2015 1 次提交
-
-
由 Strashko, Grygorii 提交于
It is unsafe [1] if probing of devices will happen during suspend or hibernation and system behavior will be unpredictable in this case. So, let's prohibit device's probing in dpm_prepare() and defer their probing instead. The normal behavior will be restored in dpm_complete(). This patch introduces new DD core APIs: device_block_probing() It will disable probing of devices and defer their probes instead. device_unblock_probing() It will restore normal behavior and trigger re-probing of deferred devices. [1] https://lkml.org/lkml/2015/9/11/554Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 7月, 2015 1 次提交
-
-
由 Alan Stern 提交于
Don't unset the direct_complete flag on devices that have runtime PM disabled, if they are runtime suspended. This is needed because otherwise ancestor devices wouldn't be able to do direct_complete without adding runtime PM support to all its descendants. Also removes pm_runtime_suspended_if_enabled() because it's now unused. Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 6月, 2015 1 次提交
-
-
由 Todd E Brandt 提交于
Move the trace_device_pm_callback locations for dpm_prepare and dpm_complete to encompass the attempt to capture the device mutex prior to callback. This is needed by analyze_suspend to identify gaps in the trace output caused by the delay in locking the mutex for a device. Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 5月, 2015 1 次提交
-
-
由 Tony Lindgren 提交于
Turns out we can automate the handling for the device_may_wakeup() quite a bit by using the kernel wakeup source list as suggested by Rafael J. Wysocki <rjw@rjwysocki.net>. And as some hardware has separate dedicated wake-up interrupt in addition to the IO interrupt, we can automate the handling by adding a generic threaded interrupt handler that just calls the device PM runtime to wake up the device. This allows dropping code from device drivers as we currently are doing it in multiple ways, and often wrong. For most drivers, we should be able to drop the following boilerplate code from runtime_suspend and runtime_resume functions: ... device_init_wakeup(dev, true); ... if (device_may_wakeup(dev)) enable_irq_wake(irq); ... if (device_may_wakeup(dev)) disable_irq_wake(irq); ... device_init_wakeup(dev, false); ... We can replace it with just the following init and exit time code: ... device_init_wakeup(dev, true); dev_pm_set_wake_irq(dev, irq); ... dev_pm_clear_wake_irq(dev); device_init_wakeup(dev, false); ... And for hardware with dedicated wake-up interrupts: ... device_init_wakeup(dev, true); dev_pm_set_dedicated_wake_irq(dev, irq); ... dev_pm_clear_wake_irq(dev); device_init_wakeup(dev, false); ... Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 3月, 2015 1 次提交
-
-
由 Zhonghui Fu 提交于
Occasionally, the system can't come back up after suspend/resume due to problems of device suspending phase. This patch make PM_TRACE infrastructure cover device suspending phase of suspend/resume process, and the information in RTC can tell developers which device suspending function make system hang. Signed-off-by: NZhonghui Fu <zhonghui.fu@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 10月, 2014 1 次提交
-
-
由 Imre Deak 提交于
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: de377b39 (PM / sleep: Asynchronous threads for suspend_late) Signed-off-by: NImre Deak <imre.deak@intel.com> Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 10月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 29 7月, 2014 1 次提交
-
-
由 Randy Dunlap 提交于
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: NRandy Dunlap <rdunlap@infradead.org> Acked-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 11 6月, 2014 1 次提交
-
-
由 Todd E Brandt 提交于
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: NTodd Brandt <todd.e.brandt@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 6月, 2014 1 次提交
-
-
由 Todd E Brandt 提交于
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: NTodd Brandt <todd.e.brandt@intel.com> Acked-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 5月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu>
-
- 06 3月, 2014 1 次提交
-
-
由 Viresh Kumar 提交于
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: NLan Tianyu <tianyu.lan@intel.com> Reported-by: NJinhyuk Choi <jinchoi@broadcom.com> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 2月, 2014 5 次提交
-
-
由 Liu, Chuansheng 提交于
In analogy with commits 5af84b82 and 97df8c12, using asynchronous threads can improve the overall suspend_late time significantly. This patch is for suspend_late phase. Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Liu, Chuansheng 提交于
In analogy with commits 5af84b82 and 97df8c12, using asynchronous threads can improve the overall suspend_noirq time significantly. This patch is for suspend_noirq phase. Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Liu, Chuansheng 提交于
In analogy with commits 5af84b82 and 97df8c12, using asynchronous threads can improve the overall resume_early time significantly. This patch is for resume_early phase. Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Liu, Chuansheng 提交于
In analogy with commits 5af84b82 and 97df8c12, 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: NChuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Liu, Chuansheng 提交于
The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 12月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 5a87182a (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: 5a87182a (cpufreq: suspend governors on system suspend/hibernate) Reported-by: NBjørn Mork <bjorn@mork.no> Reported-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 11月, 2013 1 次提交
-
-
由 Viresh Kumar 提交于
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: NLan Tianyu <tianyu.lan@intel.com> Reported-by: NJinhyuk Choi <jinchoi@broadcom.com> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog, minor cleanups] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 11月, 2013 1 次提交
-
-
由 Wolfram Sang 提交于
Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 11月, 2013 1 次提交
-
-
由 Ulf Hansson 提交于
If a device prepare callback for some reason would fail, the PM core prevented the device from going inactive forever. In this case, to reverse the pm_runtime_get_noresume() we invokes the asyncronous pm_runtime_put(), thus restoring the usage count. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 10月, 2013 1 次提交
-
-
由 Benoit Goby 提交于
Rather than hard-lock the kernel, dump the suspend/resume thread stack and panic() to capture a message in pstore when a driver takes too long to suspend/resume. Default suspend/resume watchdog timeout is set to 12 seconds to be longer than the usbhid 10 second timeout, but could be changed at compile time. Exclude from the watchdog the time spent waiting for children that are resumed asynchronously and time every device, whether or not they resumed synchronously. This patch is targeted for mobile devices where a suspend/resume lockup could cause a system reboot. Information about failing device can be retrieved in subsequent boot session by mounting pstore and inspecting the log. Laptops with EFI-enabled pstore could also benefit from this feature. The hardware watchdog timer is likely suspended during this time and couldn't be relied upon. The soft-lockup detector would eventually tell that tasks are not scheduled, but would provide little context as to why. The patch hence uses system timer and assumes it is still active while the devices are suspended/resumed. This feature can be enabled/disabled during kernel configuration. This change is based on earlier work by San Mehat. Signed-off-by: NBenoit Goby <benoit@android.com> Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 27 7月, 2013 1 次提交
-
-
由 Shuah Khan 提交于
A new trace event is added to PM events to print the time it takes to suspend and resume a device. It generates trace messages that include device, driver, parent information in addition to the type of PM ops invoked as well as the PM event and error status from the PM ops. Example trace below: bash-2239 [000] .... 290.883035: device_pm_report_time: backlight acpi_video0 parent=0000:00:02.0 state=freeze ops=class nsecs=332 err=0 bash-2239 [000] .... 290.883041: device_pm_report_time: rfkill rf kill3 parent=phy0 state=freeze ops=legacy class nsecs=216 err=0 bash-2239 [001] .... 290.973892: device_pm_report_time: ieee80211 phy0 parent=0000:01:00.0 state=freeze ops=legacy class nsecs=90846477 err=0 bash-2239 [001] .... 293.660129: device_pm_report_time: ieee80211 phy0 parent=0000:01:00.0 state=restore ops=legacy class nsecs=101295162 err=0 bash-2239 [001] .... 293.660147: device_pm_report_time: rfkill rfkill3 parent=phy0 state=restore ops=legacy class nsecs=1804 err=0 bash-2239 [001] .... 293.660157: device_pm_report_time: backlight acpi_video0 parent=0000:00:02.0 state=restore ops=class nsecs=757 err=0 Signed-off-by: NShuah Khan <shuah.kh@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 4月, 2013 1 次提交
-
-
由 Ulf Hansson 提交于
Use the asyncronous runtime PM API when returning the runtime reference for the device after the system resume is completed. By using the asyncronous runtime PM API we don't have to wait for each an every device to become idle|suspended. Instead we can move on and handle the next device in queue. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 3月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Device PM QoS sysfs attributes, if present during device removal, are removed from within device_pm_remove(), which is too late, since dpm_sysfs_remove() has already removed the whole attribute group they belonged to. However, moving the removal of those attributes to dpm_sysfs_remove() alone is not sufficient, because in theory they still can be re-added right after being removed by it (the device's driver is still bound to it at that point). For this reason, move the entire desctruction of device PM QoS constraints to dpm_sysfs_remove() and make it prevent any new constraints from being added after it has run. Also, move the initialization of the power.qos field in struct device to device_pm_init_common() and drop the no longer needed dev_pm_qos_constraints_init(). Reported-by: NSasha Levin <sasha.levin@oracle.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, the PM core disables runtime PM for all devices right after executing subsystem/driver .suspend() callbacks for them and re-enables it right before executing subsystem/driver .resume() callbacks for them. This may lead to problems when there are two devices such that the .suspend() callback executed for one of them depends on runtime PM working for the other. In that case, if runtime PM has already been disabled for the second device, the first one's .suspend() won't work correctly (and analogously for resume). To make those issues go away, make the PM core disable runtime PM for devices right before executing subsystem/driver .suspend_late() callbacks for them and enable runtime PM for them right after executing subsystem/driver .resume_early() callbacks for them. This way the potential conflitcs between .suspend_late()/.resume_early() and their runtime PM counterparts are still prevented from happening, but the subtle ordering issues related to disabling/enabling runtime PM for devices during system suspend/resume are much easier to avoid. Reported-and-tested-by: NJan-Matthias Braun <jan_braun@gmx.net> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com> Cc: 3.4+ <stable@vger.kernel.org>
-
- 20 9月, 2012 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1591) moves the pm_runtime_get_noresume() and pm_runtime_put_sync() calls from __device_suspend() and device_resume() to device_prepare() and device_complete() in the PM core. The reason for doing this is to make sure that parent devices remain at full power (i.e., don't go into runtime suspend) while their children are being resumed from a system sleep. The PCI core already contained equivalent code to serve the same purpose. The patch removes the duplicated code, since it is no longer needed. One of the comments from the PCI core gets moved into the PM core, and a second comment is added to explain whe the _get_noresume and _put_sync calls are present. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 19 9月, 2012 1 次提交
-
-
由 Feng Hong 提交于
When dpm_suspend_noirq fail, state is PMSG_SUSPEND, should change to PMSG_RESUME when dpm_resume_early is called Signed-off-by: NFeng Hong <hongfeng@marvell.com> Signed-off-by: NRaul Xiong <xjian@marvell.com> Signed-off-by: NNeil Zhang <zhangwm@marvell.com> Cc: stable@vger.kernel.org Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 04 9月, 2012 2 次提交
-
-
由 Rafael J. Wysocki 提交于
The syscore device PM flag is used to mark the devices (belonging to a PM domain) that should never be turned off, except for the system core (syscore) suspend/hibernation and resume stages. That flag is stored in the device's struct pm_subsys_data object whose address is available from struct device. However, in some situations it may be convenient to set that flag before the device is added to a PM domain, so it is better to move it directly to the "power" member of struct device. Then, it can be checked by the routines in drivers/base/power/runtime.c and drivers/base/power/main.c, which is more straightforward. This also reduces the number of dev_gpd_data() invocations in the generic PM domains framework, so the overhead related to the syscore flag is slightly smaller. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NMagnus Damm <damm@opensource.se>
-
由 Rafael J. Wysocki 提交于
Make the device power management initialization more straightforward by moving the initialization of common (i.e. used by both runtime PM and system suspend) fields to a separate routine. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 17 8月, 2012 1 次提交
-
-
由 Ming Lei 提交于
dpm_list and its pm lock provide a good way to iterate all devices in system. Except this way, there is no other easy way to iterate devices in system. firmware loader need to cache firmware images for devices before system sleep, so introduce the function to meet its demand. Reported-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NMing Lei <ming.lei@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 7月, 2012 2 次提交
-
-
由 Colin Cross 提交于
Commit cf579dfb (PM / Sleep: Introduce "late suspend" and "early resume" of devices) introduced a bug where suspend_late handlers would be called, but if dpm_suspend_noirq returned an error the early_resume handlers would never be called. All devices would end up on the dpm_late_early_list, and would never be resumed again. Fix it by calling dpm_resume_early when dpm_suspend_noirq returns an error. Signed-off-by: NColin Cross <ccross@android.com> Cc: stable@vger.kernel.org Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Sachin Kamat 提交于
Fix the following sparse warnings: drivers/base/power/main.c:48:1: warning: symbol 'dpm_prepared_list' was not declared. Should it be static? drivers/base/power/main.c:49:1: warning: symbol 'dpm_suspended_list' was not declared. Should it be static? drivers/base/power/main.c:50:1: warning: symbol 'dpm_late_early_list' was not declared. Should it be static? drivers/base/power/main.c:51:1: warning: symbol 'dpm_noirq_list' was not declared. Should it be static? Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 11 7月, 2012 1 次提交
-
-
由 Preeti U Murthy 提交于
On certain bios, resume hangs if cpus are allowed to enter idle states during suspend [1]. This was fixed in apci idle driver [2].But intel_idle driver does not have this fix. Thus instead of replicating the fix in both the idle drivers, or in more platform specific idle drivers if needed, the more general cpuidle infrastructure could handle this. A suspend callback in cpuidle_driver could handle this fix. But a cpuidle_driver provides only basic functionalities like platform idle state detection capability and mechanisms to support entry and exit into CPU idle states. All other cpuidle functions are found in the cpuidle generic infrastructure for good reason that all cpuidle drivers, irrepective of their platforms will support these functions. One option therefore would be to register a suspend callback in cpuidle which handles this fix. This could be called through a PM_SUSPEND_PREPARE notifier. But this is too generic a notfier for a driver to handle. Also, ideally the job of cpuidle is not to handle side effects of suspend. It should expose the interfaces which "handle cpuidle 'during' suspend" or any other operation, which the subsystems call during that respective operation. The fix demands that during suspend, no cpus should be allowed to enter deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle ensures that. Not just that it also kicks all the cpus which are already in idle out of their idle states which was being done during cpu hotplug through a CPU_DYING_FROZEN callbacks. Now the question arises about when during suspend should cpuidle_uninstall_idle_handler() be called. Since we are dealing with drivers it seems best to call this function during dpm_suspend(). Delaying the call till dpm_suspend_noirq() does no harm, as long as it is before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg operations. In dpm_suspend_noirq(), it would be wise to place this call before suspend_device_irqs() to avoid ugly interactions with the same. Ananlogously, during resume. References: [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075. [2] http://marc.info/?l=linux-pm&m=133958534231884&w=2Reported-and-tested-by: NDave Hansen <dave@linux.vnet.ibm.com> Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com> Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 01 7月, 2012 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Change the behavior of the newly introduced /sys/power/pm_print_times attribute so that its initial value depends on initcall_debug, but setting it to 0 will cause device suspend/resume times not to be printed, even if initcall_debug has been set. This way, the people who use initcall_debug for reasons other than PM debugging will be able to switch the suspend/resume times printing off, if need be. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sameer Nanda 提交于
Added a new knob called /sys/power/pm_print_times. Setting it to 1 enables printing of time taken by devices to suspend and resume. Setting it to 0 disables this printing (unless overridden by initcall_debug kernel command line option). Signed-off-by: NSameer Nanda <snanda@chromium.org> Acked-by: NGreg KH <gregkh@linuxfoundation.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-