- 15 3月, 2011 9 次提交
-
-
由 Rafael 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: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NKevin Hilman <khilman@ti.com> Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rafael 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: NRafael J. Wysocki <rjw@sisk.pl> Tested-and-acked-by: NKevin Hilman <khilman@ti.com>
-
由 Rafael J. Wysocki 提交于
The dpm_prepare() function increments the runtime PM reference counters of all devices to prevent pm_runtime_suspend() from executing subsystem-level callbacks. However, this was supposed to guard against a specific race condition that cannot happen, because the power management workqueue is freezable, so pm_runtime_suspend() can only be called synchronously during system suspend and we can rely on subsystems and device drivers to avoid doing that unnecessarily. Make dpm_prepare() drop the runtime PM reference to each device after making sure that runtime resume is not pending for it. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NKevin Hilman <khilman@ti.com>
-
由 Rafael J. Wysocki 提交于
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be replaced with CONFIG_PM. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael 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: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Mandeep Singh Baines 提交于
printk()s without a priority level default to KERN_WARNING. To reduce noise at KERN_WARNING, this patch sets the priority level appriopriately for unleveled printks()s. This should be useful to folks that look at dmesg warnings closely. Changed these messages to pr_info(). Signed-off-by: NMandeep Singh Baines <msb@chromium.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Since pm_save_wakeup_count() has just been changed to clear events_check_enabled unconditionally before checking if there are any new wakeup events registered since the last read from /sys/power/wakeup_count, the detection of wakeup events during suspend may be disabled, after it's been enabled, by writing a "wrong" value back to /sys/power/wakeup_count. For this reason, it is not necessary to update events_check_enabled in pm_get_wakeup_count() any more. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
According to Documentation/ABI/testing/sysfs-power, the /sys/power/wakeup_count interface should only make the kernel react to wakeup events during suspend if the last write to it has been successful. However, if /sys/power/wakeup_count is written to two times in a row, where the first write is successful and the second is not, the kernel will still react to wakeup events during suspend due to a bug in pm_save_wakeup_count(). Fix the bug by making pm_save_wakeup_count() clear events_check_enabled unconditionally before checking if there are any new wakeup events registered since the previous read from /sys/power/wakeup_count. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The memory barrier in wakeup_source_deactivate() is supposed to prevent the callers of pm_wakeup_pending() and pm_get_wakeup_count() from seeing the new value of events_in_progress (0, in particular) and the old value of event_count at the same time. However, if wakeup_source_deactivate() is executed by CPU0 and, for instance, pm_wakeup_pending() is executed by CPU1, where both processors can reorder operations, the memory barrier in wakeup_source_deactivate() doesn't affect CPU1 which can reorder reads. In that case CPU1 may very well decide to fetch event_count before it's modified and events_in_progress after it's been updated, so pm_wakeup_pending() may fail to detect a wakeup event. This issue can be addressed by using a single atomic variable to store both events_in_progress and event_count, so that they can be updated together in a single atomic operation. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 26 1月, 2011 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1445) fixes a bug in the runtime PM core left over from the addition of the no_callbacks flag. If this flag is set then it is possible for rpm_suspend() to be called in_interrupt, so when releasing spinlocks it's important not to re-enable interrupts. To avoid an unnecessary save-and-restore of the interrupt flag, the patch also inlines a pm_request_idle() call. This fixes Bugzilla #27482. (The offending code was added in 2.6.37, so it's not necessary to apply this to any earlier stable kernels.) Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: Ntim blechmann <tim@klingt.org> CC: <stable@kernel.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 21 1月, 2011 1 次提交
-
-
由 David Rientjes 提交于
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option is used to configure any non-standard kernel with a much larger scope than only small devices. This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes references to the option throughout the kernel. A new CONFIG_EMBEDDED option is added that automatically selects CONFIG_EXPERT when enabled and can be used in the future to isolate options that should only be considered for embedded systems (RISC architectures, SLOB, etc). Calling the option "EXPERT" more accurately represents its intention: only expert users who understand the impact of the configuration changes they are making should enable it. Reviewed-by: NIngo Molnar <mingo@elte.hu> Acked-by: NDavid Woodhouse <david.woodhouse@intel.com> Signed-off-by: NDavid Rientjes <rientjes@google.com> Cc: Greg KH <gregkh@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jens Axboe <axboe@kernel.dk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robin Holt <holt@sgi.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 1月, 2011 1 次提交
-
-
由 David Rientjes 提交于
Add hugepage statistics to per-node sysfs meminfo Reviewed-by: NRik van Riel <riel@redhat.com> Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 1月, 2011 1 次提交
-
-
由 Stefan Achatz 提交于
Added dev_bin_attrs to struct class similar to existing dev_attrs. Signed-off-by: NStefan Achatz <erazor_de@users.sourceforge.net> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 24 12月, 2010 12 次提交
-
-
由 Rafael J. Wysocki 提交于
The __pm_generic_resume() function changes the given device's runtime PM status to RPM_ACTIVE if its driver's callback returns 0, but it only should do that if the rumtime PM is enabled for the device. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Use dev_name() wherever applicable in drivers/base/power/main.c. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The registration of a new parentless device during system suspend will not lead to any complications affecting the PM core (the device will be effectively seen after the subsequent resume has completed), so remove the code used for detection of such events. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The device power.status field is too complicated for its purpose (storing the information about whether or not the device is in the "active" state from the PM core's point of view), so replace it with a bit field and modify all of its users accordingly. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Since a separate list of devices is used to link devices that have completed each stage of suspend (or resume), it is not necessary to check dev->power.status in the core device resume routines any more. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Instead of keeping all devices in the same list during system suspend and resume, regardless of what suspend-resume callbacks have been executed for them already, use separate lists of devices that have had their ->prepare(), ->suspend() and ->suspend_noirq() callbacks executed. This will allow us to simplify the core device suspend and resume routines. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The compiler complains that calltime may be uninitialized in pm_noirq_op(), so add extra initialization for that variable to avoid the warning. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Before starting to suspend a device in __device_suspend() check if there's a request to abort the power transition and return -EBUSY in that case. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
To avoid confusion with the meaning and return value of pm_check_wakeup_events() replace it with pm_wakeup_pending() that will work the other way around (ie. return true when system-wide power transition should be aborted). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Currently dpm_prepare() returns error code if it finds that a device being suspended has a pending runtime resume request. However, it should not do that if the checking for wakeup events is not enabled. On the other hand, if the checking for wakeup events is enabled, it can return error when a wakeup event is detected, regardless of its source. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 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: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Aaro Koskinen 提交于
Commit 05aa55dd changed routines to succeed if the driver handler is not defined. Comments were not updated. Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 30 11月, 2010 1 次提交
-
-
由 Michael Ellerman 提交于
Document that device_rename() is not to be used by anything other than the network core. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 22 11月, 2010 1 次提交
-
-
由 Robert P. J. Day 提交于
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 18 11月, 2010 1 次提交
-
-
由 Kay Sievers 提交于
As classes and busses are pretty much the same thing, and we want to merge them together into a 'subsystem' in the future, let us share the same private data parts to make that merge easier. Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 11月, 2010 2 次提交
-
-
由 Brandon Philips 提交于
869dfc87 addded a long line and indented with spaces. Fix. Signed-off-by: NBrandon Philips <brandon@ifup.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rafael J. Wysocki 提交于
Holding dpm_list_mtx across late suspend and early resume of devices is problematic for the PCMCIA subsystem and doesn't allow device objects to be removed by late suspend and early resume driver callbacks. This appears to be overly restrictive, as drivers are generally allowed to remove device objects in other phases of suspend and resume. Therefore rework dpm_{suspend|resume}_noirq() so that they don't have to hold dpm_list_mtx all the time. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 02 11月, 2010 1 次提交
-
-
由 Uwe Kleine-König 提交于
"gadget", "through", "command", "maintain", "maintain", "controller", "address", "between", "initiali[zs]e", "instead", "function", "select", "already", "equal", "access", "management", "hierarchy", "registration", "interest", "relative", "memory", "offset", "already", Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 29 10月, 2010 2 次提交
-
-
由 Kevin Winchester 提交于
GCC version 4.5.1 gives the following warning: drivers/base/power/runtime.c: In function ‘rpm_check_suspend_allowed’: drivers/base/power/runtime.c:146:25: warning: comparison between ‘enum dpm_state’ and ‘enum rpm_status’ which seems to be a typo in that dev->power.runtime_status should be compared instead of dev->power.status. Signed-off-by: NKevin Winchester <kjwinchester@gmail.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 27 10月, 2010 1 次提交
-
-
由 Michael Rubin 提交于
For NUMA node systems it is important to have visibility in memory characteristics. Two of the /proc/vmstat values "nr_written" and "nr_dirtied" are added here. # cat /sys/devices/system/node/node20/vmstat nr_written 0 nr_dirtied 0 Signed-off-by: NMichael Rubin <mrubin@google.com> Reviewed-by: NWu Fengguang <fengguang.wu@intel.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 10月, 2010 6 次提交
-
-
由 Ming Lei 提交于
For device with no_callbacks flag set, its power lock and its parent's power lock may be held nestedly in rpm_resume, so we should take spin_lock_nested(lock, SINGLE_DEPTH_NESTING) to acquire parent power lock to avoid lockdep warning. Signed-off-by: NMing Lei <tom.leiming@gmail.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Mark Brown 提交于
Aid diagnostics by printing the error code from failed suspends, which doesn't otherwise seem to get displayed. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Nathan Fontenot 提交于
Add a section count property to the memory_block struct to track the number of memory sections that have been added/removed from a memory block. This allows us to know when the last memory section of a memory block has been removed so we can remove the memory block. Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com> Reviewed-by: NRobin Holt <holt@sgi.com> Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Nathan Fontenot 提交于
Add a new mutex for use in adding and removing of memory blocks. This is needed to avoid any race conditions in which the same memory block could be added and removed at the same time. Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com> Reviewed-by: NRobin Holt <holt@sgi.com> Reviewed-By: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Nathan Fontenot 提交于
Move the find_memory_block() routine up to avoid needing a forward declaration in subsequent patches. Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com> Reviewed-by: NRobin Holt <holt@sgi.com> Reviewed-By: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Robin Holt 提交于
Modify link_mem_sections() to pass in the previous mem_block as a hint to locating the next mem_block. Since they are typically added in order this results in a massive saving in time during boot of a very large system. For example, on a 16TB x86_64 machine, it reduced the total time spent linking all node's memory sections from 1 hour, 27 minutes to 46 seconds. Signed-off-by: NRobin Holt <holt@sgi.com> To: Gary Hade <garyhade@us.ibm.com> To: Badari Pulavarty <pbadari@us.ibm.com> To: Ingo Molnar <mingo@elte.hu> Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-