21 Jun, 2013

1 commit

  • Commit a938da06 introduced a useful little log message to tell
    users/debuggers which wakeup source aborted a suspend. However,
    this message is only printed if the abort happens during the
    in-kernel suspend path (after writing /sys/power/state).

    The full specification of the /sys/power/wakeup_count facility
    allows user-space power managers to double-check if wakeups have
    already happened before it actually tries to suspend (e.g. while it
    was running user-space pre-suspend hooks), by writing the last known
    wakeup_count value to /sys/power/wakeup_count. This patch changes
    the sysfs handler for that node to also print said log message if
    that write fails, so that we can figure out the offending wakeup
    source for both kinds of suspend aborts.

    Signed-off-by: Julius Werner
    Signed-off-by: Rafael J. Wysocki

    Julius Werner
     

10 Feb, 2013

1 commit

  • PM_SUSPEND_FREEZE state is a general state that
    does not need any platform specific support, it equals
    frozen processes + suspended devices + idle processors.

    Compared with PM_SUSPEND_MEMORY,
    PM_SUSPEND_FREEZE saves less power
    because the system is still in a running state.
    PM_SUSPEND_FREEZE has less resume latency because it does not
    touch BIOS, and the processors are in idle state.

    Compared with RTPM/idle,
    PM_SUSPEND_FREEZE saves more power as
    1. the processor has longer sleep time because processes are frozen.
    The deeper c-state the processor supports, more power saving we can get.
    2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
    more power saving from the devices that does not have good RTPM support.

    This state is useful for
    1) platforms that do not have STR, or have a broken STR.
    2) platforms that have an extremely low power idle state,
    which can be used to replace STR.

    The following describes how PM_SUSPEND_FREEZE state works.
    1. echo freeze > /sys/power/state
    2. the processes are frozen.
    3. all the devices are suspended.
    4. all the processors are blocked by a wait queue
    5. all the processors idles and enters (Deep) c-state.
    6. an interrupt fires.
    7. a processor is woken up and handles the irq.
    8. if it is a general event,
    a) the irq handler runs and quites.
    b) goto step 4.
    9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
    a) the irq handler runs and activate the wakeup source
    b) wakeup_source_activate() notifies the wait queue.
    c) system starts resuming from PM_SUSPEND_FREEZE
    10. all the devices are resumed.
    11. all the processes are unfrozen.
    12. system is back to working.

    Known Issue:
    The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
    from the previous suspend state.
    Take ACPI platform for example, there are some GPEs that only enabled
    when the system is in sleep state, to wake the system backk from S3/S4.
    But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
    This means we may lose some wake event.
    But on the other hand, as we do not disable all the Interrupts during
    PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
    not available for S3/S4.

    The patches has been tested on an old Sony laptop, and here are the results:

    Average Power:
    1. RPTM/idle for half an hour:
    14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
    2. Freeze for half an hour:
    11W, 10.4W, 9.4W, 11.3W 10.5W
    3. RTPM/idle for three hours:
    11.6W
    4. Freeze for three hours:
    10W
    5. Suspend to Memory:
    0.5~0.9W

    Average Resume Latency:
    1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
    Less than 0.2s
    2. Freeze: (From pressing power button to screen back)
    2.50s
    3. Suspend to Memory: (From pressing power button to screen back)
    4.33s

    >From the results, we can see that all the platforms should benefit from
    this patch, even if it does not have Low Power S0.

    Signed-off-by: Zhang Rui
    Signed-off-by: Rafael J. Wysocki

    Zhang Rui
     

01 Jul, 2012

1 commit

  • 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: Rafael J. Wysocki
    Reviewed-by: Srivatsa S. Bhat
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

02 May, 2012

2 commits

  • Android uses one wakelock statistics that is only necessary for
    opportunistic sleep. Namely, the prevent_suspend_time field
    accumulates the total time the given wakelock has been locked
    while "automatic suspend" was enabled. Add an analogous field,
    prevent_sleep_time, to wakeup sources and make it behave in a similar
    way.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     
  • Introduce a mechanism by which the kernel can trigger global
    transitions to a sleep state chosen by user space if there are no
    active wakeup sources.

    It consists of a new sysfs attribute, /sys/power/autosleep, that
    can be written one of the strings returned by reads from
    /sys/power/state, an ordered workqueue and a work item carrying out
    the "suspend" operations. If a string representing the system's
    sleep state is written to /sys/power/autosleep, the work item
    triggering transitions to that state is queued up and it requeues
    itself after every execution until user space writes "off" to
    /sys/power/autosleep.

    That work item enables the detection of wakeup events using the
    functions already defined in drivers/base/power/wakeup.c (with one
    small modification) and calls either pm_suspend(), or hibernate() to
    put the system into a sleep state. If a wakeup event is reported
    while the transition is in progress, it will abort the transition and
    the "system suspend" work item will be queued up again.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Greg Kroah-Hartman
    Reviewed-by: NeilBrown

    Rafael J. Wysocki
     

18 Feb, 2012

1 commit

  • Since suspend_stats_update() is only called from pm_suspend(),
    move its code directly into that function and remove the static
    inline definition from include/linux/suspend.h. Clean_up
    pm_suspend() in the process.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Srivatsa S. Bhat

    Rafael J. Wysocki
     

10 Feb, 2012

1 commit


30 Jan, 2012

1 commit

  • The current device suspend/resume phases during system-wide power
    transitions appear to be insufficient for some platforms that want
    to use the same callback routines for saving device states and
    related operations during runtime suspend/resume as well as during
    system suspend/resume. In principle, they could point their
    .suspend_noirq() and .resume_noirq() to the same callback routines
    as their .runtime_suspend() and .runtime_resume(), respectively,
    but at least some of them require device interrupts to be enabled
    while the code in those routines is running.

    It also makes sense to have device suspend-resume callbacks that will
    be executed with runtime PM disabled and with device interrupts
    enabled in case someone needs to run some special code in that
    context during system-wide power transitions.

    Apart from this, .suspend_noirq() and .resume_noirq() were introduced
    as a workaround for drivers using shared interrupts and failing to
    prevent their interrupt handlers from accessing suspended hardware.
    It appears to be better not to use them for other porposes, or we may
    have to deal with some serious confusion (which seems to be happening
    already).

    For the above reasons, introduce new device suspend/resume phases,
    "late suspend" and "early resume" (and analogously for hibernation)
    whose callback will be executed with runtime PM disabled and with
    device interrupts enabled and whose callback pointers generally may
    point to runtime suspend/resume routines.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Mark Brown
    Reviewed-by: Kevin Hilman

    Rafael J. Wysocki
     

20 Jan, 2012

1 commit

  • Commit 33e638b, "PM / Sleep: Use the freezer_count() functions in
    [un]lock_system_sleep() APIs" introduced an undesirable change in the
    behaviour of unlock_system_sleep() since freezer_count() internally calls
    try_to_freeze() - which we don't need in unlock_system_sleep().

    And commit bcda53f, "PM / Sleep: Replace mutex_[un]lock(&pm_mutex) with
    [un]lock_system_sleep()" made these APIs wide-spread. This caused a
    regression in suspend-to-disk where snapshot_read() and snapshot_write()
    were getting frozen due to the try_to_freeze embedded in
    unlock_system_sleep(), since these functions were invoked when the freezing
    condition was still in effect.

    Fix this by rewriting unlock_system_sleep() by open-coding freezer_count()
    and dropping the try_to_freeze() part. Not only will this fix the
    regression but this will also ensure that the API only does what it is
    intended to do, and nothing more, under the hood.

    While at it, make the code more correct and robust by ensuring that the
    PF_FREEZER_SKIP flag gets cleared with pm_mutex held, to avoid a race with
    the freezer.

    Also, to be on the safer side, open-code freezer_do_not_count() as well
    (inside lock_system_sleep()), to ensure that any unrelated modification to
    freezer[_do_not]_count() does not break things again!

    Reported-and-tested-by: Rafael J. Wysocki
    Signed-off-by: Srivatsa S. Bhat
    Acked-by: Tejun Heo
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     

09 Dec, 2011

2 commits

  • The [un]lock_system_sleep() APIs were originally introduced to mutually
    exclude memory hotplug and hibernation.

    Directly using mutex_lock(&pm_mutex) to achieve mutual exclusion with
    suspend or hibernation code can lead to freezing failures. However, the
    APIs [un]lock_system_sleep() can be safely used to achieve the same,
    without causing freezing failures.

    So, since it would be beneficial to modify all the existing users of
    mutex_lock(&pm_mutex) (in all parts of the kernel), so that they use these
    safe APIs intead, make these APIs generic by removing the restriction that
    they work only when CONFIG_HIBERNATE_CALLBACKS is set. Moreover, that
    restriction didn't buy us anything anyway.

    Suggested-by: Tejun Heo
    Signed-off-by: Srivatsa S. Bhat
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     
  • Now that freezer_count() and freezer_do_not_count() don't have the restriction
    that they are effective only when called by userspace processes, use
    them in lock_system_sleep() and unlock_system_sleep() instead of open-coding
    their parts.

    Signed-off-by: Srivatsa S. Bhat
    Acked-by: Tejun Heo
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     

24 Nov, 2011

1 commit

  • The lock_system_sleep() function is used in the memory hotplug code at
    several places in order to implement mutual exclusion with hibernation.
    However, this function tries to acquire the 'pm_mutex' lock using
    mutex_lock() and hence blocks in TASK_UNINTERRUPTIBLE state if it doesn't
    get the lock. This would lead to task freezing failures and hence
    hibernation failure as a consequence, even though the hibernation call path
    successfully acquired the lock.

    But it is to be noted that, since this task tries to acquire pm_mutex, if it
    blocks due to this, we are *100% sure* that this task is not going to run
    as long as hibernation sequence is in progress, since hibernation releases
    'pm_mutex' only at the very end, when everything is done.
    And this means, this task is going to be anyway blocked for much more longer
    than what the freezer intends to achieve; which means, freezing and thawing
    doesn't really make any difference to this task!

    So, to fix freezing failures, we just ask the freezer to skip freezing this
    task, since it is already "frozen enough".

    But instead of calling freezer_do_not_count() and freezer_count() as it is,
    we use only the relevant parts of those functions, because restrictions
    such as 'the task should be a userspace one' etc., might not be relevant in
    this scenario.

    Signed-off-by: Srivatsa S. Bhat
    Acked-by: Tejun Heo
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     

17 Oct, 2011

3 commits

  • Introduce the config option CONFIG_VT_CONSOLE_SLEEP in order to cleanup
    the #if defined ugliness for the vt suspend support functions. Note that
    CONFIG_VT_CONSOLE is already dependant on CONFIG_VT.

    The function pm_set_vt_switch is actually dependant on CONFIG_VT and not
    CONFIG_PM_SLEEP. This fixes a compile error when CONFIG_PM_SLEEP is
    not set:

    drivers/tty/vt/vt_ioctl.c:1794: error: redefinition of 'pm_set_vt_switch'
    include/linux/suspend.h:17: error: previous definition of 'pm_set_vt_switch' was here

    Also, remove the incorrect path from the comment in console.c.

    [rjw: Replaced #if defined() with #ifdef in suspend.h.]

    Signed-off-by: H Hartley Sweeten
    Acked-by: Arnd Bergmann
    Signed-off-by: Rafael J. Wysocki

    H Hartley Sweeten
     
  • For s390 there is one additional byte associated with each page,
    the storage key. This byte contains the referenced and changed
    bits and needs to be included into the hibernation image.
    If the storage keys are not restored to their previous state all
    original pages would appear to be dirty. This can cause
    inconsistencies e.g. with read-only filesystems.

    Signed-off-by: Martin Schwidefsky
    Signed-off-by: Rafael J. Wysocki

    Martin Schwidefsky
     
  • 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
    Signed-off-by: Rafael J. Wysocki

    ShuoX Liu
     

26 Jul, 2011

1 commit


16 Jul, 2011

1 commit

  • A system or a device may need to control suspend/wakeup events. It may
    want to wakeup the system after a predefined amount of time or at a
    predefined event decided while entering suspend for polling or delayed
    work. Then, it may want to enter suspend again if its predefined wakeup
    condition is the only wakeup reason and there is no outstanding events;
    thus, it does not wakeup the userspace unnecessary or unnecessary
    devices and keeps suspended as long as possible (saving the power).

    Enabling a system to wakeup after a specified time can be easily
    achieved by using RTC. However, to enter suspend again immediately
    without invoking userland and unrelated devices, we need additional
    features in the suspend framework.

    Such need comes from:

    1. Monitoring a critical device status without interrupts that can
    wakeup the system. (in-suspend polling)
    An example is ambient temperature monitoring that needs to shut down
    the system or a specific device function if it is too hot or cold. The
    temperature of a specific device may be needed to be monitored as well;
    e.g., a charger monitors battery temperature in order to stop charging
    if overheated.

    2. Execute critical "delayed work" at suspend.
    A driver or a system/board may have a delayed work (or any similar
    things) that it wants to execute at the requested time.
    For example, some chargers want to check the battery voltage some
    time (e.g., 30 seconds) after the battery is fully charged and the
    charger has stopped. Then, the charger restarts charging if the voltage
    has dropped more than a threshold, which is smaller than "restart-charger"
    voltage, which is a threshold to restart charging regardless of the
    time passed.

    This patch allows to add "suspend_again" callback at struct
    platform_suspend_ops and let the "suspend_again" callback return true if
    the system is required to enter suspend again after the current instance
    of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
    syscore is not done because: a) suspend_again feature is usually under
    platform-wise decision and controls the behavior of the whole platform
    and b) There are very limited devices related to the usage cases of
    suspend_again; chargers and temperature sensors are mentioned so far.

    With suspend_again callback registered at struct platform_suspend_ops
    suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
    platform, the suspend framework tries to enter suspend again by
    looping suspend_enter() if suspend_again has returned true and there has
    been no errors in the suspending sequence or pending wakeups (by
    pm_wakeup_pending).

    Tested at Exynos4-NURI.

    [rjw: Fixed up kerneldoc comment for suspend_enter().]

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Acked-by: Pavel Machek
    Signed-off-by: Rafael J. Wysocki

    MyungJoo Ham
     

12 Apr, 2011

1 commit

  • Xen save/restore is going to use hibernate device callbacks for
    quiescing devices and putting them back to normal operations and it
    would need to select CONFIG_HIBERNATION for this purpose. However,
    that also would cause the hibernate interfaces for user space to be
    enabled, which might confuse user space, because the Xen kernels
    don't support hibernation. Moreover, it would be wasteful, as it
    would make the Xen kernels include a substantial amount of code that
    they would never use.

    To address this issue introduce new power management Kconfig option
    CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
    that is necessary for the hibernate device callbacks to work and make
    CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to
    select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
    hibernate code along with it.

    Signed-off-by: Rafael J. Wysocki
    Tested-by: Shriram Rajagopalan

    Rafael J. Wysocki
     

14 Jan, 2011

2 commits

  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (59 commits)
    ACPI / PM: Fix build problems for !CONFIG_ACPI related to NVS rework
    ACPI: fix resource check message
    ACPI / Battery: Update information on info notification and resume
    ACPI: Drop device flag wake_capable
    ACPI: Always check if _PRW is present before trying to evaluate it
    ACPI / PM: Check status of power resources under mutexes
    ACPI / PM: Rename acpi_power_off_device()
    ACPI / PM: Drop acpi_power_nocheck
    ACPI / PM: Drop acpi_bus_get_power()
    Platform / x86: Make fujitsu_laptop use acpi_bus_update_power()
    ACPI / Fan: Rework the handling of power resources
    ACPI / PM: Register power resource devices as soon as they are needed
    ACPI / PM: Register acpi_power_driver early
    ACPI / PM: Add function for updating device power state consistently
    ACPI / PM: Add function for device power state initialization
    ACPI / PM: Introduce __acpi_bus_get_power()
    ACPI / PM: Introduce function for refcounting device power resources
    ACPI / PM: Add functions for manipulating lists of power resources
    ACPI / PM: Prevent acpi_power_get_inferred_state() from making changes
    ACPICA: Update version to 20101209
    ...

    Linus Torvalds
     
  • * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (43 commits)
    Documentation/trace/events.txt: Remove obsolete sched_signal_send.
    writeback: fix global_dirty_limits comment runtime -> real-time
    ppc: fix comment typo singal -> signal
    drivers: fix comment typo diable -> disable.
    m68k: fix comment typo diable -> disable.
    wireless: comment typo fix diable -> disable.
    media: comment typo fix diable -> disable.
    remove doc for obsolete dynamic-printk kernel-parameter
    remove extraneous 'is' from Documentation/iostats.txt
    Fix spelling milisec -> ms in snd_ps3 module parameter description
    Fix spelling mistakes in comments
    Revert conflicting V4L changes
    i7core_edac: fix typos in comments
    mm/rmap.c: fix comment
    sound, ca0106: Fix assignment to 'channel'.
    hrtimer: fix a typo in comment
    init/Kconfig: fix typo
    anon_inodes: fix wrong function name in comment
    fix comment typos concerning "consistent"
    poll: fix a typo in comment
    ...

    Fix up trivial conflicts in:
    - drivers/net/wireless/iwlwifi/iwl-core.c (moved to iwl-legacy.c)
    - fs/ext4/ext4.h

    Also fix missed 'diabled' typo in drivers/net/bnx2x/bnx2x.h while at it.

    Linus Torvalds
     

07 Jan, 2011

2 commits


24 Dec, 2010

1 commit


16 Nov, 2010

2 commits

  • While at it, fix two checkpatch errors.
    Several non-const struct instances constified by this patch were added after
    the introduction of platform_suspend_ops in checkpatch.pl's list of "should
    be const" structs (79404849e90a41ea2109bd0e2f7c7164b0c4ce73).

    Patch against mainline.
    Inspired by hunks of the grsecurity patch, updated for newer kernels.

    Signed-off-by: Lionel Debroux
    Acked-by: Ingo Molnar
    Signed-off-by: Jiri Kosina

    Lionel Debroux
     
  • Patch against mainline.

    Changes since v1: added one hunk; no longer adding "const" qualifier to
    pointers in platform_hibernation_ops after seeing
    b4144e4f6e3b448d322095ca08af393682a69e33.

    Signed-off-by: Jiri Kosina

    Lionel Debroux
     

17 Oct, 2010

2 commits

  • If there is a wakeup event during the freezing of tasks, suspend or
    hibernation will fail anyway. Since try_to_freeze_tasks() can take
    up to 20 seconds to complete or fail, aborting it as soon as a wakeup
    event is detected improves the worst case wakeup latency.

    Based on a patch from Arve Hjønnevåg.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek

    Rafael J. Wysocki
     
  • Introduce struct wakeup_source for representing system wakeup sources
    within the kernel and for collecting statistics related to them.
    Make the recently introduced helper functions pm_wakeup_event(),
    pm_stay_awake() and pm_relax() use struct wakeup_source objects
    internally, so that wakeup statistics associated with wakeup devices
    can be collected and reported in a consistent way (the definition of
    pm_relax() is changed, which is harmless, because this function is
    not called directly by anyone yet). Introduce new wakeup-related
    sysfs device attributes in /sys/devices/.../power for reporting the
    device wakeup statistics.

    Change the global wakeup events counters event_count and
    events_in_progress into atomic variables, so that it is not necessary
    to acquire a global spinlock in pm_wakeup_event(), pm_stay_awake()
    and pm_relax(), which should allow us to avoid lock contention in
    these functions on SMP systems with many wakeup devices.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

19 Jul, 2010

2 commits

  • The ACPI suspend code calls suspend_nvs_free() at a wrong place,
    which may lead to a memory leak if there's an error executing
    acpi_pm_prepare(), because acpi_pm_finish() will not be called in
    that case. However, the root cause of this problem is the
    apparently confusing ordering of calls in suspend error paths that
    needs to be fixed.

    In addition to that, fix a typo in a label name in suspend.c.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Len Brown

    Rafael J. Wysocki
     
  • One of the arguments during the suspend blockers discussion was that
    the mainline kernel didn't contain any mechanisms making it possible
    to avoid races between wakeup and system suspend.

    Generally, there are two problems in that area. First, if a wakeup
    event occurs exactly when /sys/power/state is being written to, it
    may be delivered to user space right before the freezer kicks in, so
    the user space consumer of the event may not be able to process it
    before the system is suspended. Second, if a wakeup event occurs
    after user space has been frozen, it is not generally guaranteed that
    the ongoing transition of the system into a sleep state will be
    aborted.

    To address these issues introduce a new global sysfs attribute,
    /sys/power/wakeup_count, associated with a running counter of wakeup
    events and three helper functions, pm_stay_awake(), pm_relax(), and
    pm_wakeup_event(), that may be used by kernel subsystems to control
    the behavior of this attribute and to request the PM core to abort
    system transitions into a sleep state already in progress.

    The /sys/power/wakeup_count file may be read from or written to by
    user space. Reads will always succeed (unless interrupted by a
    signal) and return the current value of the wakeup events counter.
    Writes, however, will only succeed if the written number is equal to
    the current value of the wakeup events counter. If a write is
    successful, it will cause the kernel to save the current value of the
    wakeup events counter and to abort the subsequent system transition
    into a sleep state if any wakeup events are reported after the write
    has returned.

    [The assumption is that before writing to /sys/power/state user space
    will first read from /sys/power/wakeup_count. Next, user space
    consumers of wakeup events will have a chance to acknowledge or
    veto the upcoming system transition to a sleep state. Finally, if
    the transition is allowed to proceed, /sys/power/wakeup_count will
    be written to and if that succeeds, /sys/power/state will be written
    to as well. Still, if any wakeup events are reported to the PM core
    by kernel subsystems after that point, the transition will be
    aborted.]

    Additionally, put a wakeup events counter into struct dev_pm_info and
    make these per-device wakeup event counters available via sysfs,
    so that it's possible to check the activity of various wakeup event
    sources within the kernel.

    To illustrate how subsystems can use pm_wakeup_event(), make the
    low-level PCI runtime PM wakeup-handling code use it.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Jesse Barnes
    Acked-by: Greg Kroah-Hartman
    Acked-by: markgross
    Reviewed-by: Alan Stern

    Rafael J. Wysocki
     

10 Jun, 2010

1 commit


18 Nov, 2009

1 commit

  • Allow memory hotplug and hibernation in the same kernel

    Memory hotplug and hibernation were exclusive in Kconfig. This is
    obviously a problem for distribution kernels who want to support both in
    the same image.

    After some discussions with Rafael and others the only problem is with
    parallel memory hotadd or removal while a hibernation operation is in
    process. It was also working for s390 before.

    This patch removes the Kconfig level exclusion, and simply makes the
    memory add / remove functions grab the pm_mutex to exclude against
    hibernation.

    Fixes a regression - old kernels didn't exclude memory hotadd and
    hibernation.

    Signed-off-by: Andi Kleen
    Cc: Gerald Schaefer
    Cc: KOSAKI Motohiro
    Cc: Yasunori Goto
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

13 Jun, 2009

1 commit

  • The *_nvs_* routines in swsusp.c make use of the io*map()
    functions, which are only provided for HAS_IOMEM, thus
    breaking compilation if HAS_IOMEM is not set. Fix this
    by moving the *_nvs_* routines into hibernate_nvs.c, which
    is only compiled if HAS_IOMEM is set.

    [rjw: Change the name of the new file to hibernate_nvs.c, add the
    license line to the header comment.]

    Signed-off-by: Cornelia Huck
    Acked-by: Pavel Machek
    Signed-off-by: Rafael J. Wysocki

    Cornelia Huck
     

20 Apr, 2009

1 commit

  • Commit 900af0d973856d6feb6fc088c2d0d3fde57707d3 (PM: Change suspend
    code ordering) changed the ordering of suspend code in such a way
    that the platform .prepare() callback is now executed after the
    device drivers' late suspend callbacks have run. Unfortunately, this
    turns out to break ARM platforms that need to talk via I2C to power
    control devices during the .prepare() callback.

    For this reason introduce two new platform suspend callbacks,
    .prepare_late() and .wake(), that will be called just prior to
    disabling non-boot CPUs and right after bringing them back on line,
    respectively, and use them instead of .prepare() and .finish() for
    ACPI suspend. Make the PM core execute the .prepare() and .finish()
    platform suspend callbacks where they were executed previously (that
    is, right after calling the regular suspend methods provided by
    device drivers and right before executing their regular resume
    methods, respectively).

    It is not necessary to make analogous changes to the hibernation
    code and data structures at the moment, because they are only used
    by ACPI platforms.

    Signed-off-by: Rafael J. Wysocki
    Reported-by: Russell King
    Acked-by: Len Brown

    Rafael J. Wysocki
     

01 Apr, 2009

1 commit

  • Make the following header file changes:

    - remove arch ifdefs and asm/suspend.h from linux/suspend.h
    - add asm/suspend.h to disk.c (for arch_prepare_suspend())
    - add linux/io.h to swsusp.c (for ioremap())
    - x86 32/64 bit compile fixes

    Signed-off-by: Magnus Damm
    Cc: Paul Mundt
    Acked-by: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Magnus Damm
     

27 Jan, 2009

1 commit

  • Introduce boolean function system_entering_hibernation() returning
    'true' during the last phase of hibernation, in which devices are
    being put into low power states and the sleep state (for example,
    ACPI S4) is finally entered.

    Some device drivers need such a function to check if the system is
    in the final phase of hibernation. In particular, some SATA drivers
    are going to use it for blacklisting systems in which the disks
    should not be spun down during the last phase of hibernation (the
    BIOS will do that anyway).

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Jeff Garzik

    Rafael J. Wysocki
     

19 Dec, 2008

1 commit

  • According to the ACPI Specification 3.0b, Section 15.3.2,
    "OSPM will call the _PTS control method some time before entering a
    sleeping state, to allow the platform's AML code to update this
    memory image before entering the sleeping state. After the system
    awakes from an S4 state, OSPM will restore this memory area and call
    the _WAK control method to enable the BIOS to reclaim its memory
    image." For this reason, implement a mechanism allowing us to save
    the NVS memory during hibernation and to restore it during the
    subsequent resume.

    Based on a patch by Zhang Rui.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Nigel Cunningham
    Cc: Zhang Rui
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

15 Aug, 2008

1 commit

  • WARNING: vmlinux.o(.text+0xe684): Section mismatch in reference from the function register_nosave_region() to the function .init.text:__register_nosave_region()
    The function register_nosave_region() references
    the function __init __register_nosave_region().
    This is often because register_nosave_region lacks a __init
    annotation or the annotation of __register_nosave_region is wrong.

    register_nosave_region calls __init function and is called only from
    __init functions

    Signed-off-by: Marcin Slusarz
    Acked-by: Rafael J. Wysocki
    Cc: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marcin Slusarz
     

27 Jul, 2008

1 commit

  • This patch implements devices state save/restore before after kexec.

    This patch together with features in kexec_jump patch can be used for
    following:

    - A simple hibernation implementation without ACPI support. You can kexec a
    hibernating kernel, save the memory image of original system and shutdown
    the system. When resuming, you restore the memory image of original system
    via ordinary kexec load then jump back.

    - Kernel/system debug through making system snapshot. You can make system
    snapshot, jump back, do some thing and make another system snapshot.

    - Cooperative multi-kernel/system. With kexec jump, you can switch between
    several kernels/systems quickly without boot process except the first time.
    This appears like swap a whole kernel/system out/in.

    - A general method to call program in physical mode (paging turning
    off). This can be used to invoke BIOS code under Linux.

    The following user-space tools can be used with kexec jump:

    - kexec-tools needs to be patched to support kexec jump. The patches
    and the precompiled kexec can be download from the following URL:
    source: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-src_git_kh10.tar.bz2
    patches: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-patches_git_kh10.tar.bz2
    binary: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec_git_kh10

    - makedumpfile with patches are used as memory image saving tool, it
    can exclude free pages from original kernel memory image file. The
    patches and the precompiled makedumpfile can be download from the
    following URL:
    source: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile-src_cvs_kh10.tar.bz2
    patches: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile-patches_cvs_kh10.tar.bz2
    binary: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile_cvs_kh10

    - An initramfs image can be used as the root file system of kexeced
    kernel. An initramfs image built with "BuildRoot" can be downloaded
    from the following URL:
    initramfs image: http://khibernation.sourceforge.net/download/release_v10/initramfs/rootfs_cvs_kh10.gz
    All user space tools above are included in the initramfs image.

    Usage example of simple hibernation:

    1. Compile and install patched kernel with following options selected:

    CONFIG_X86_32=y
    CONFIG_RELOCATABLE=y
    CONFIG_KEXEC=y
    CONFIG_CRASH_DUMP=y
    CONFIG_PM=y
    CONFIG_HIBERNATION=y
    CONFIG_KEXEC_JUMP=y

    2. Build an initramfs image contains kexec-tool and makedumpfile, or
    download the pre-built initramfs image, called rootfs.gz in
    following text.

    3. Prepare a partition to save memory image of original kernel, called
    hibernating partition in following text.

    4. Boot kernel compiled in step 1 (kernel A).

    5. In the kernel A, load kernel compiled in step 1 (kernel B) with
    /sbin/kexec. The shell command line can be as follow:

    /sbin/kexec --load-preserve-context /boot/bzImage --mem-min=0x100000
    --mem-max=0xffffff --initrd=rootfs.gz

    6. Boot the kernel B with following shell command line:

    /sbin/kexec -e

    7. The kernel B will boot as normal kexec. In kernel B the memory
    image of kernel A can be saved into hibernating partition as
    follow:

    jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='`
    echo $jump_back_entry > kexec_jump_back_entry
    cp /proc/vmcore dump.elf

    Then you can shutdown the machine as normal.

    8. Boot kernel compiled in step 1 (kernel C). Use the rootfs.gz as
    root file system.

    9. In kernel C, load the memory image of kernel A as follow:

    /sbin/kexec -l --args-none --entry=`cat kexec_jump_back_entry` dump.elf

    10. Jump back to the kernel A as follow:

    /sbin/kexec -e

    Then, kernel A is resumed.

    Implementation point:

    To support jumping between two kernels, before jumping to (executing)
    the new kernel and jumping back to the original kernel, the devices
    are put into quiescent state, and the state of devices and CPU is
    saved. After jumping back from kexeced kernel and jumping to the new
    kernel, the state of devices and CPU are restored accordingly. The
    devices/CPU state save/restore code of software suspend is called to
    implement corresponding function.

    Known issues:

    - Because the segment number supported by sys_kexec_load is limited,
    hibernation image with many segments may not be load. This is
    planned to be eliminated by adding a new flag to sys_kexec_load to
    make a image can be loaded with multiple sys_kexec_load invoking.

    Now, only the i386 architecture is supported.

    Signed-off-by: Huang Ying
    Acked-by: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: Pavel Machek
    Cc: Nigel Cunningham
    Cc: "Rafael J. Wysocki"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Huang Ying
     

13 Jun, 2008

1 commit

  • ACPI PM: Add possibility to change suspend sequence

    There are some systems out there that don't work correctly with
    our current suspend/hibernation code ordering. Provide a workaround
    for these systems allowing them to pass 'acpi_sleep=old_ordering' in
    the kernel command line so that it will use the pre-ACPI 2.0 ("old")
    suspend code ordering.

    Unfortunately, this requires us to add a platform hook to the
    resuming of devices for recovering the platform in case one of the
    device drivers' .suspend() routines returns error code. Namely,
    ACPI 1.0 specifies that _PTS should be called before suspending
    devices, but _WAK still should be called before resuming them in
    order to undo the changes made by _PTS. However, if there is an
    error during suspending devices, they are automatically resumed
    without returning control to the PM core, so the _WAK has to be
    called from within device_resume() in that cases.

    The patch also reorders and refactors the ACPI suspend/hibernation
    code to avoid duplication as far as reasonably possible.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Jesse Barnes

    Rafael J. Wysocki
     

28 Apr, 2008

1 commit

  • Prior to suspend, we allocate and switch to a new VT; after suspend, we switch
    back to the original VT. This can be slow, and is completely unnecessary if
    the framebuffer we're using can restore video properly.

    This adds a hook that allows drivers to select whether or not to do this vt
    switch, and changes the gxfb driver to call this hook. It also adds a module
    param to gxfb to allow controlling of the vt switch (defaulting to no switch).

    (Note: I'm not convinced that console_sem is the best way to protect this, but
    we should probably have some form of locking..)

    [akpm@linux-foundation.org: build fix]
    Signed-off-by: Andres Salomon
    Cc: Jordan Crouse
    Cc: "Antonino A. Daplas"
    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon