summaryrefslogtreecommitdiffstats
path: root/Documentation/power
AgeCommit message (Collapse)Author
2011-11-04PM / Runtime: Automatically retry failed autosuspendsAlan Stern
Originally, the runtime PM core would send an idle notification whenever a suspend attempt failed. The idle callback routine could then schedule a delayed suspend for some time later. However this behavior was changed by commit f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle notification after failing suspend). No notifications were sent, and there was no clear mechanism to retry failed suspends. This caused problems for the usbhid driver, because it fails autosuspend attempts as long as a key is being held down. Therefore this patch (as1492) adds a mechanism for retrying failed autosuspends. If the callback routine updates the last_busy field so that the next autosuspend expiration time is in the future, the autosuspend will automatically be rescheduled. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Henrik Rydberg <rydberg@euromail.se> Cc: <stable@kernel.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-04PM / Sleep: Update freezer documentationSrivatsa S. Bhat
This patch: * Substitutes some obsolete references to kernel/power/process.c by kernel/freezer.c. * Mentions kernel/freezer.c as being part of the "freezer" code along with the rest of the files. * Fixes a trivial typo. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-01Merge branch 'for-linus' of git://opensource.wolfsonmicro.com/regulatorLinus Torvalds
* 'for-linus' of git://opensource.wolfsonmicro.com/regulator: (22 commits) regulator: Constify constraints name regulator: Fix possible nullpointer dereference in regulator_enable() regulator: gpio-regulator add dependency on GENERIC_GPIO regulator: Add module.h include to gpio-regulator regulator: Add driver for gpio-controlled regulators regulator: remove duplicate REG_CTRL2 defines in tps65023 regulator: Clarify documentation for regulator-regulator supplies regulator: Fix some bitrot in the machine driver documentation regulator: tps65023: Added support for the similiar TPS65020 chip regulator: tps65023: Setting correct core regulator for tps65021 regulator: tps65023: Set missing bit for update core-voltage regulator: tps65023: Fixes i2c configuration issues regulator: Add debugfs file showing the supply map table regulator: tps6586x: add SMx slew rate setting regulator: tps65023: Fixes i2c configuration issues regulator: tps6507x: Remove num_voltages array regulator: max8952: removed unused mutex. regulator: fix regulator/consumer.h kernel-doc warning regulator: Ensure enough enable time for max8649 regulator: 88pm8607: Fix off-by-one value range checking in the case of no id is matched ...
2011-10-25Merge branch 'pm-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm * 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits) PM / Clocks: Remove redundant NULL checks before kfree() PM / Documentation: Update docs about suspend and CPU hotplug ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist. ARM: mach-shmobile: sh7372 A4R support (v4) ARM: mach-shmobile: sh7372 A3SP support (v4) PM / Sleep: Mark devices involved in wakeup signaling during suspend PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image PM / Hibernate: Do not initialize static and extern variables to 0 PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too PM / Hibernate: Add resumedelay kernel param in addition to resumewait MAINTAINERS: Update linux-pm list address PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs PM / Hibernate: Add resumewait param to support MMC-like devices as resume file PM / Hibernate: Fix typo in a kerneldoc comment PM / Hibernate: Freeze kernel threads after preallocating memory PM: Update the policy on default wakeup settings PM / VT: Cleanup #if defined uglyness and fix compile error PM / Suspend: Off by one in pm_suspend() PM / Hibernate: Include storage keys in hibernation image on s390 ...
2011-10-22PM / Documentation: Update docs about suspend and CPU hotplugSrivatsa S. Bhat
Update the documentation about the interaction between the suspend (S3) call path and the CPU hotplug infrastructure. This patch focusses only on the activities of the freezer, cpu hotplug and the notifications involved. It outlines how regular CPU hotplug differs from the way it is invoked during suspend and also tries to explain the locking involved. In addition to that, it discusses the issue of microcode update during CPU hotplug operations. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-16PM / Hibernate: Freeze kernel threads after preallocating memoryRafael J. Wysocki
There is a problem with the current ordering of hibernate code which leads to deadlocks in some filesystems' memory shrinkers. Namely, some filesystems use freezable kernel threads that are inactive when the hibernate memory preallocation is carried out. Those same filesystems use memory shrinkers that may be triggered by the hibernate memory preallocation. If those memory shrinkers wait for the frozen kernel threads, the hibernate process deadlocks (this happens with XFS, for one example). Apparently, it is not technically viable to redesign the filesystems in question to avoid the situation described above, so the only possible solution of this issue is to defer the freezing of kernel threads until the hibernate memory preallocation is done, which is implemented by this change. Unfortunately, this requires the memory preallocation to be done before the "prepare" stage of device freeze, so after this change the only way drivers can allocate additional memory for their freeze routines in a clean way is to use PM notifiers. Reported-by: Christoph <cr2005@u-club.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-16PM: Update the policy on default wakeup settingsAlan Stern
This patch (as1485) documents a change to the kernel's default wakeup policy. Devices that forward wakeup requests between buses should be enabled for wakeup by default. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-16PM / Suspend: Add statistics debugfs file for suspend to RAMShuoX Liu
Record S3 failure time about each reason and the latest two failed devices' names in S3 progress. We can check it through 'suspend_stats' entry in debugfs. The motivation of the patch: We are enabling power features on Medfield. Comparing with PC/notebook, a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far more frequently. If it can't enter suspend-2-ram in time, the power might be used up soon. We often find sometimes, a device suspend fails. Then, system retries s3 over and over again. As display is off, testers and developers don't know what happens. Some testers and developers complain they don't know if system tries suspend-2-ram, and what device fails to suspend. They need such info for a quick check. The patch adds suspend_stats under debugfs for users to check suspend to RAM statistics quickly. If not using this patch, we have other methods to get info about what device fails. One is to turn on CONFIG_PM_DEBUG, but users would get too much info and testers need recompile the system. In addition, dynamic debug is another good tool to dump debug info. But it still doesn't match our utilization scenario closely. 1) user need write a user space parser to process the syslog output; 2) Our testing scenario is we leave the mobile for at least hours. Then, check its status. No serial console available during the testing. One is because console would be suspended, and the other is serial console connecting with spi or HSU devices would consume power. These devices are powered off at suspend-2-ram. Signed-off-by: ShuoX Liu <shuox.liu@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-16Merge branch 'pm-runtime' into pm-for-linusRafael J. Wysocki
* pm-runtime: PM / Runtime: Handle .runtime_suspend() failure correctly PM / Runtime: Fix kerneldoc comment for rpm_suspend() PM / Runtime: Update document about callbacks
2011-10-10PM / Runtime: Update document about callbacksMing Lei
Support for device power domains has been introduced in commit 9659cc0678b954f187290c6e8b247a673c5d37e1 (PM: Make system-wide PM and runtime PM treat subsystems consistently), also power domain callbacks will take precedence over subsystem ones from commit 4d27e9dcff00a6425d779b065ec8892e4f391661(PM: Make power domain callbacks take precedence over subsystem ones). So update part of "Device Runtime PM Callbacks" in Documentation/power/runtime_pm.txt. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-07Merge branch 'pm-qos' into pm-for-linusRafael J. Wysocki
* pm-qos: PM / QoS: Update Documentation for the pm_qos and dev_pm_qos frameworks PM / QoS: Add function dev_pm_qos_read_value() (v3) PM QoS: Add global notification mechanism for device constraints PM QoS: Implement per-device PM QoS constraints PM QoS: Generalize and export constraints management code PM QoS: Reorganize data structs PM QoS: Code reorganization PM QoS: Minor clean-ups PM QoS: Move and rename the implementation files
2011-10-07Merge branch 'pm-runtime' into pm-for-linusRafael J. Wysocki
* pm-runtime: PM / Tracing: build rpm-traces.c only if CONFIG_PM_RUNTIME is set PM / Runtime: Replace dev_dbg() with trace_rpm_*() PM / Runtime: Introduce trace points for tracing rpm_* functions PM / Runtime: Don't run callbacks under lock for power.irq_safe set USB: Add wakeup info to debugging messages PM / Runtime: pm_runtime_idle() can be called in atomic context PM / Runtime: Add macro to test for runtime PM events PM / Runtime: Add might_sleep() to runtime PM functions
2011-10-07regulator: Clarify documentation for regulator-regulator suppliesMark Brown
The mechanism used for connecting regulators together when one regulator supplies another wasn't clear as the names being used weren't really tied together well. Reported-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-07regulator: Fix some bitrot in the machine driver documentationMark Brown
The documentation for the machine driver was rather badly bitrotted, using pointers to struct device rather than dev_name() to hook up the consumers. Update to use dev_name(). Reported-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-04PM / QoS: Update Documentation for the pm_qos and dev_pm_qos frameworksJean Pihet
Update the documentation for the recently updated pm_qos API, kernel and user space. Add documentation for the per-device PM QoS (dev_pm_qos) framework API. Signed-off-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-09-27doc: fix broken referencesPaul Bolle
There are numerous broken references to Documentation files (in other Documentation files, in comments, etc.). These broken references are caused by typo's in the references, and by renames or removals of the Documentation files. Some broken references are simply odd. Fix these broken references, sometimes by dropping the irrelevant text they were part of. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-09-21PM / Runtime: pm_runtime_idle() can be called in atomic contextMing Lei
Add to pm_runtime_idle the list of functions that can be called in atomic context if pm_runtime_irq_safe() has been called for the device. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-25PM / Runtime: Correct documentation of pm_runtime_irq_safe()Rafael J. Wysocki
The description of pm_runtime_irq_safe() has to be updated to follow the code after commit 02b2677 (PM / Runtime: Allow _put_sync() from interrupts-disabled context). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com>
2011-08-14PM / Runtime: Add might_sleep() to runtime PM functionsColin Cross
Some of the entry points to pm runtime are not safe to call in atomic context unless pm_runtime_irq_safe() has been called. Inspecting the code, it is not immediately obvious that the functions sleep at all, as they run inside a spin_lock_irqsave, but under some conditions they can drop the lock and turn on irqs. If a driver incorrectly calls the pm_runtime apis, it can cause sleeping and irq processing when it expects to stay in atomic context. Add might_sleep_if to the majority of the __pm_runtime_* entry points to enforce correct usage. Add pm_runtime_put_sync_autosuspend to the list of functions that can be called in atomic context. Signed-off-by: Colin Cross <ccross@android.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-05PM / Runtime: Allow _put_sync() from interrupts-disabled contextKevin Hilman
Currently the use of pm_runtime_put_sync() is not safe from interrupts-disabled context because rpm_idle() will release the spinlock and enable interrupts for the idle callbacks. This enables interrupts during a time where interrupts were expected to be disabled, and can have strange side effects on drivers that expected interrupts to be disabled. This is not a bug since the documentation clearly states that only _put_sync_suspend() is safe in IRQ-safe mode. However, pm_runtime_put_sync() could be made safe when in IRQ-safe mode by releasing the spinlock but not re-enabling interrupts, which is what this patch aims to do. Problem was found when using some buggy drivers that set pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled context. Reported-by: Colin Cross <ccross@google.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-15Merge branch 'pm-runtime' into for-linusRafael J. Wysocki
* pm-runtime: OMAP: PM: disable idle on suspend for GPIO and UART OMAP: PM: omap_device: add API to disable idle on suspend OMAP: PM: omap_device: add system PM methods for PM domain handling OMAP: PM: omap_device: conditionally use PM domain runtime helpers PM / Runtime: Add new helper function: pm_runtime_status_suspended() PM / Runtime: Consistent utilization of deferred_resume PM / Runtime: Prevent runtime_resume from racing with probe PM / Runtime: Replace "run-time" with "runtime" in documentation PM / Runtime: Improve documentation of enable, disable and barrier PM: Limit race conditions between runtime PM and system sleep (v2) PCI / PM: Detect early wakeup in pci_pm_prepare() PM / Runtime: Return special error code if runtime PM is disabled PM / Runtime: Update documentation of interactions with system sleep
2011-07-15Merge branch 'pm-domains' into for-linusRafael J. Wysocki
* pm-domains: (33 commits) ARM / shmobile: Return -EBUSY from A4LC power off if A3RV is active PM / Domains: Take .power_off() error code into account ARM / shmobile: Use genpd_queue_power_off_work() ARM / shmobile: Use pm_genpd_poweroff_unused() PM / Domains: Introduce function to power off all unused PM domains PM / Domains: Queue up power off work only if it is not pending PM / Domains: Improve handling of wakeup devices during system suspend PM / Domains: Do not restore all devices on power off error PM / Domains: Allow callbacks to execute all runtime PM helpers PM / Domains: Do not execute device callbacks under locks PM / Domains: Make failing pm_genpd_prepare() clean up properly PM / Domains: Set device state to "active" during system resume ARM: mach-shmobile: sh7372 A3RV requires A4LC PM / Domains: Export pm_genpd_poweron() in header ARM: mach-shmobile: sh7372 late pm domain off ARM: mach-shmobile: Runtime PM late init callback ARM: mach-shmobile: sh7372 D4 support ARM: mach-shmobile: sh7372 A4MP support ARM: mach-shmobile: sh7372: make sure that fsi is peripheral of spu2 ARM: mach-shmobile: sh7372 A3SG support ...
2011-07-15PM / OPP: Introduce function to free cpufreq tableNishanth Menon
cpufreq table allocated by opp_init_cpufreq_table is better freed by OPP layer itself. This allows future modifications to the table handling to be transparent to the users. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-12PM / Runtime: Add new helper function: pm_runtime_status_suspended()Kevin Hilman
This boolean function simply returns whether or not the runtime status of the device is 'suspended'. Unlike pm_runtime_suspended(), this function returns the runtime status whether or not runtime PM for the device has been disabled or not. Also add entry to Documentation/power/runtime.txt Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-06PM / Runtime: Replace "run-time" with "runtime" in documentationRafael J. Wysocki
The runtime PM documentation and kerneldoc comments sometimes spell "runtime" with a dash (i.e. "run-time"). Replace all of those instances with "runtime" to make the naming consistent. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-06PM / Runtime: Improve documentation of enable, disable and barrierRafael J. Wysocki
The runtime PM documentation in Documentation/power/runtime_pm.txt doesn't say that pm_runtime_enable() and pm_runtime_disable() work by operating on power.disable_depth, which is wrong, because the possibility of nesting disables doesn't follow from the description of these functions. Also, there is no description of pm_runtime_barrier() at all in the document, which is confusing. Improve the documentation by fixing those issues. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-06PM: Limit race conditions between runtime PM and system sleep (v2)Rafael J. Wysocki
One of the roles of the PM core is to prevent different PM callbacks executed for the same device object from racing with each other. Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to succeed during system suspend) runtime PM callbacks may be executed concurrently with system suspend/resume callbacks for the same device. The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26 was that some subsystems and device drivers wanted to use runtime PM helpers, pm_runtime_suspend() and pm_runtime_put_sync() in particular, for carrying out the suspend of devices in their .suspend() callbacks. However, as it's been determined recently, there are multiple reasons not to do so, inlcuding: * The caller really doesn't control the runtime PM usage counters, because user space can access them through sysfs and effectively block runtime PM. That means using pm_runtime_suspend() or pm_runtime_get_sync() to suspend devices during system suspend may or may not work. * If a driver calls pm_runtime_suspend() from its .suspend() callback, it causes the subsystem's .runtime_suspend() callback to be executed, which leads to the call sequence: subsys->suspend(dev) driver->suspend(dev) pm_runtime_suspend(dev) subsys->runtime_suspend(dev) recursive from the subsystem's point of view. For some subsystems that may actually work (e.g. the platform bus type), but for some it will fail in a rather spectacular fashion (e.g. PCI). In each case it means a layering violation. * Both the subsystem and the driver can provide .suspend_noirq() callbacks for system suspend that can do whatever the .runtime_suspend() callbacks do just fine, so it really isn't necessary to call pm_runtime_suspend() during system suspend. * The runtime PM's handling of wakeup devices is usually different from the system suspend's one, so .runtime_suspend() may simply be inappropriate for system suspend. * System suspend is supposed to work even if CONFIG_PM_RUNTIME is unset. * The runtime PM workqueue is frozen before system suspend, so if whatever the driver is going to do during system suspend depends on it, that simply won't work. Still, there is a good reason to allow pm_runtime_resume() to succeed during system suspend and resume (for instance, some subsystems and device drivers may legitimately use it to ensure that their devices are in full-power states before suspending them). Moreover, there is no reason to prevent runtime PM callbacks from being executed in parallel with the system suspend/resume .prepare() and .complete() callbacks and the code removed by commit e8665002477f0278f84f898145b1f141ba26ee26 went too far in this respect. On the other hand, runtime PM callbacks, including .runtime_resume(), must not be executed during system suspend's "late" stage of suspending devices and during system resume's "early" device resume stage. Taking all of the above into consideration, make the PM core acquire a runtime PM reference to every device and resume it if there's a runtime PM resume request pending right before executing the subsystem-level .suspend() callback for it. Make the PM core drop references to all devices right after executing the subsystem-level .resume() callbacks for them. Additionally, make the PM core disable the runtime PM framework for all devices during system suspend, after executing the subsystem-level .suspend() callbacks for them, and enable the runtime PM framework for all devices during system resume, right before executing the subsystem-level .resume() callbacks for them. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-02PM / Runtime: Return special error code if runtime PM is disabledRafael J. Wysocki
Some callers of pm_runtime_get_sync() and other runtime PM helper functions, scsi_autopm_get_host() and scsi_autopm_get_device() in particular, need to distinguish error codes returned when runtime PM is disabled (i.e. power.disable_depth is nonzero for the given device) from error codes returned in other situations. For this reason, make the runtime PM helper functions return -EACCES when power.disable_depth is nonzero and ensure that this error code won't be returned by them in any other circumstances. Modify scsi_autopm_get_host() and scsi_autopm_get_device() to check the error code returned by pm_runtime_get_sync() and ignore -EACCES. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-02PM / Runtime: Update documentation of interactions with system sleepRafael J. Wysocki
The documents describing the interactions between runtime PM and system sleep generally refer to the model in which the system sleep state is entered through a global firmware or hardware operation. As a result, some recommendations given in there are not entirely suitable for systems in which this is not the case. Update the documentation to take the existence of those systems into account. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-07-02PM: Introduce generic "noirq" callback routines for subsystems (v2)Rafael J. Wysocki
Introduce generic "noirq" power management callback routines for subsystems in addition to the "regular" generic PM callback routines. The new routines will be used, among other things, for implementing system-wide PM transitions support for generic PM domains. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-02PM / Domains: Rename struct dev_power_domain to struct dev_pm_domainRafael J. Wysocki
The naming convention used by commit 7538e3db6e015e890825fbd9f86599b (PM: Add support for device power domains), which introduced the struct dev_power_domain type for representing device power domains, evidently confuses some developers who tend to think that objects of this type must correspond to "power domains" as defined by hardware, which is not the case. Namely, at the kernel level, a struct dev_power_domain object can represent arbitrary set of devices that are mutually dependent power management-wise and need not belong to one hardware power domain. To avoid that confusion, rename struct dev_power_domain to struct dev_pm_domain and rename the related pointers in struct device and struct pm_clk_notifier_block from pwr_domain to pm_domain. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-02PM / Runtime: Update documentation regarding driver removalRafael J. Wysocki
Commit e1866b33b1e89f077b7132daae3dfd9a594e9a1a (PM / Runtime: Rework runtime PM handling during driver removal) forgot to update the documentation in Documentation/power/runtime_pm.txt to match the new code in drivers/base/dd.c. Update that documentation to match the code it describes. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-07-02PM: Documentation: fix typo: pm_runtime_idle_sync() doesn't exist.Kevin Hilman
Replace reference to pm_runtime_idle_sync() in the driver core with pm_runtime_put_sync() which is used in the code. Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-21PM / Domains: Update documentationRafael J. Wysocki
Commit 4d27e9dcff00a6425d779b065ec8892e4f391661 (PM: Make power domain callbacks take precedence over subsystem ones) forgot to update the device power management documentation to take changes made by it into account. Correct that mistake. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-21PM: Update documentation regarding sysdevsRafael J. Wysocki
The part of Documentation/power/devices.txt regarding sysdevs is not valid any more after commit 2e711c04dbbf7a7732a3f7073b1fc285d12b369d (PM: Remove sysdev suspend, resume and shutdown operations), so remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-21PM / Runtime: Update doc: usage count no longer incremented across system PMKevin Hilman
Commit e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to succeed during system suspend) removed usage count increment across system PM. Update doc to reflect this. Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-05-27regulator: Remove supply_regulator_dev from machine configurationMark Brown
supply_regulator_dev (using a struct pointer) has been deprecated in favour of supply_regulator (using a regulator name) for quite a few releases now with a warning generated if it is used and there are no current in tree users so just remove the code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2011-05-17PM: Allow drivers to allocate memory from .prepare() callbacks safelyRafael J. Wysocki
If device drivers allocate substantial amounts of memory (above 1 MB) in their hibernate .freeze() callbacks (or in their legacy suspend callbcks during hibernation), the subsequent creation of hibernate image may fail due to the lack of memory. This is the case, because the drivers' .freeze() callbacks are executed after the hibernate memory preallocation has been carried out and the preallocated amount of memory may be too small to cover the new driver allocations. Unfortunately, the drivers' .prepare() callbacks also are executed after the hibernate memory preallocation has completed, so they are not suitable for allocating additional memory either. Thus the only way a driver can safely allocate memory during hibernation is to use a hibernate/suspend notifier. However, the notifiers are called before the freezing of user space and the drivers wanting to use them for allocating additional memory may not know how much memory needs to be allocated at that point. To let device drivers overcome this difficulty rework the hibernation sequence so that the memory preallocation is carried out after the drivers' .prepare() callbacks have been executed, so that the .prepare() callbacks can be used for allocating additional memory to be used by the drivers' .freeze() callbacks. Update documentation to match the new behavior of the code. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-15PM: Documentation/power/states.txt: fix repetitionAlexandre Courbot
Remove repetition of "called swsusp". Signed-off-by: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-03-15PM: Make system-wide PM and runtime PM treat subsystems consistentlyRafael J. Wysocki
The code handling system-wide power transitions (eg. suspend-to-RAM) can in theory execute callbacks provided by the device's bus type, device type and class in each phase of the power transition. In turn, the runtime PM core code only calls one of those callbacks at a time, preferring bus type callbacks to device type or class callbacks and device type callbacks to class callbacks. It seems reasonable to make them both behave in the same way in that respect. Moreover, even though a device may belong to two subsystems (eg. bus type and device class) simultaneously, in practice power management callbacks for system-wide power transitions are always provided by only one of them (ie. if the bus type callbacks are defined, the device class ones are not and vice versa). Thus it is possible to modify the code handling system-wide power transitions so that it follows the core runtime PM code (ie. treats the subsystem callbacks as mutually exclusive). On the other hand, the core runtime PM code will choose to execute, for example, a runtime suspend callback provided by the device type even if the bus type's struct dev_pm_ops object exists, but the runtime_suspend pointer in it happens to be NULL. This is confusing, because it may lead to the execution of callbacks from different subsystems during different operations (eg. the bus type suspend callback may be executed during runtime suspend of the device, while the device type callback will be executed during system suspend). Make all of the power management code treat subsystem callbacks in a consistent way, such that: (1) If the device's type is defined (eg. dev->type is not NULL) and its pm pointer is not NULL, the callbacks from dev->type->pm will be used. (2) If dev->type is NULL or dev->type->pm is NULL, but the device's class is defined (eg. dev->class is not NULL) and its pm pointer is not NULL, the callbacks from dev->class->pm will be used. (3) If dev->type is NULL or dev->type->pm is NULL and dev->class is NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm will be used provided that both dev->bus and dev->bus->pm are not NULL. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com> Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-15PM: Add support for device power domainsRafael J. Wysocki
The platform bus type is often used to handle Systems-on-a-Chip (SoC) where all devices are represented by objects of type struct platform_device. In those cases the same "platform" device driver may be used with multiple different system configurations, but the actions needed to put the devices it handles into a low-power state and back into the full-power state may depend on the design of the given SoC. The driver, however, cannot possibly include all the information necessary for the power management of its device on all the systems it is used with. Moreover, the device hierarchy in its current form also is not suitable for representing this kind of information. The patch below attempts to address this problem by introducing objects of type struct dev_power_domain that can be used for representing power domains within a SoC. Every struct dev_power_domain object provides a sets of device power management callbacks that can be used to perform what's needed for device power management in addition to the operations carried out by the device's driver and subsystem. Namely, if a struct dev_power_domain object is pointed to by the pwr_domain field in a struct device, the callbacks provided by its ops member will be executed in addition to the corresponding callbacks provided by the device's subsystem and driver during all power transitions. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-and-acked-by: Kevin Hilman <khilman@ti.com>
2011-03-15PM: Do not create wakeup sysfs files for devices that cannot wake upRafael J. Wysocki
Currently, wakeup sysfs attributes are created for all devices, regardless of whether or not they are wakeup-capable. This is excessive and complicates wakeup device identification from user space (i.e. to identify wakeup-capable devices user space has to read /sys/devices/.../power/wakeup for all devices and see if they are not empty). Fix this issue by avoiding to create wakeup sysfs files for devices that cannot wake up the system from sleep states (i.e. whose power.can_wakeup flags are unset during registration) and modify device_set_wakeup_capable() so that it adds (or removes) the relevant sysfs attributes if a device's wakeup capability status is changed. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-12-24PM: Fix references to basic-pm-debugging.txt in drivers-testing.txtJon Mason
basic-pm-debugging.txt is located in Documentation/power/ not Documents/power/. Change the references in Documentation/power/drivers-testing.txt to reflect the location. Signed-off-by: Jon Mason <jon.mason@exar.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-12-24PM / Runtime: Add synchronous runtime interface for interrupt handlers (v3)Alan Stern
This patch (as1431c) makes the synchronous runtime-PM interface suitable for use in interrupt handlers. Subsystems can call the new pm_runtime_irq_safe() function to tell the PM core that a device's runtime_suspend and runtime_resume callbacks should be invoked with interrupts disabled and the spinlock held. This permits the pm_runtime_get_sync() and the new pm_runtime_put_sync_suspend() routines to be called from within interrupt handlers. When a device is declared irq-safe in this way, the PM core increments the parent's usage count, so the parent will never be runtime suspended. This prevents difficult situations in which an irq-safe device can't resume because it is forced to wait for its non-irq-safe parent. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-12-16PM / Runtime: Fix pm_runtime_suspended()Rafael J. Wysocki
There are some situations (e.g. in __pm_generic_call()), where pm_runtime_suspended() is used to decide whether or not to execute a device's (system) ->suspend() callback. The callback is not executed if pm_runtime_suspended() returns true, but it does so for devices that don't even support runtime PM, because the power.disable_depth device field is ignored by it. This leads to problems (i.e. devices are not suspened when they should), so rework pm_runtime_suspended() so that it returns false if the device's power.disable_depth field is different from zero. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: stable@kernel.org
2010-11-11PM / OPP: Hide OPP configuration when SoCs do not provide an implementationMark Brown
Since the OPP API is only useful with an appropraite SoC-specific implementation there is no point in offering the ability to enable the API on general systems. Provide an ARCH_HAS OPP Kconfig symbol which masks out the option unless selected by an implementation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-17PM: Introduce library for device-specific OPPs (v7)Nishanth Menon
SoCs have a standard set of tuples consisting of frequency and voltage pairs that the device will support per voltage domain. These are called Operating Performance Points or OPPs. The actual definitions of OPP varies over silicon versions. For a specific domain, we can have a set of {frequency, voltage} pairs. As the kernel boots and more information is available, a default set of these are activated based on the precise nature of device. Further on operation, based on conditions prevailing in the system (such as temperature), some OPP availability may be temporarily controlled by the SoC frameworks. To implement an OPP, some sort of power management support is necessary hence this library depends on CONFIG_PM. Contributions include: Sanjeev Premi for the initial concept: http://patchwork.kernel.org/patch/50998/ Kevin Hilman for converting original design to device-based. Kevin Hilman and Paul Walmsey for cleaning up many of the function abstractions, improvements and data structure handling. Romit Dasgupta for using enums instead of opp pointers. Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and cleanups. Linus Walleij for recommending this layer be made generic for usage in other architectures beyond OMAP and ARM. Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for valuable improvements. Discussions and comments from: http://marc.info/?l=linux-omap&m=126033945313269&w=2 http://marc.info/?l=linux-omap&m=125482970102327&w=2 http://marc.info/?t=125809247500002&r=1&w=2 http://marc.info/?l=linux-omap&m=126025973426007&w=2 http://marc.info/?t=128152609200064&r=1&w=2 http://marc.info/?t=128468723000002&r=1&w=2 incorporated. v1: http://marc.info/?t=128468723000002&r=1&w=2 Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-17PM: Add sysfs attr for rechecking dev hash from PM traceJames Hogan
If the device which fails to resume is part of a loadable kernel module it won't be checked at startup against the magic number stored in the RTC. Add a read-only sysfs attribute /sys/power/pm_trace_dev_match which contains a list of newline separated devices (usually just the one) which currently match the last magic number. This allows the device which is failing to resume to be found after the modules are loaded again. Signed-off-by: James Hogan <james@albanarts.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-17PM / Runtime: Implement autosuspend supportAlan Stern
This patch (as1427) implements the "autosuspend" facility for runtime PM. A few new fields are added to the dev_pm_info structure and several new PM helper functions are defined, for telling the PM core whether or not a device uses autosuspend, for setting the autosuspend delay, and for marking periods of device activity. Drivers that do not want to use autosuspend can continue using the same helper functions as before; their behavior will not change. In addition, drivers supporting autosuspend can also call the old helper functions to get the old behavior. The details are all explained in Documentation/power/runtime_pm.txt and Documentation/ABI/testing/sysfs-devices-power. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>