07 May, 2019

1 commit

  • Pull power management updates from Rafael Wysocki:
    "These fix the (Intel-specific) Performance and Energy Bias Hint (EPB)
    handling and expose it to user space via sysfs, fix and clean up
    several cpufreq drivers, add support for two new chips to the qoriq
    cpufreq driver, fix, simplify and clean up the cpufreq core and the
    schedutil governor, add support for "CPU" domains to the generic power
    domains (genpd) framework and provide low-level PSCI firmware support
    for that feature, fix the exynos cpuidle driver and fix a couple of
    issues in the devfreq subsystem and clean it up.

    Specifics:

    - Fix the handling of Performance and Energy Bias Hint (EPB) on Intel
    processors and expose it to user space via sysfs to avoid having to
    access it through the generic MSR I/F (Rafael Wysocki).

    - Improve the handling of global turbo changes made by the platform
    firmware in the intel_pstate driver (Rafael Wysocki).

    - Convert some slow-path static_cpu_has() callers to boot_cpu_has()
    in cpufreq (Borislav Petkov).

    - Fix the frequency calculation loop in the armada-37xx cpufreq
    driver (Gregory CLEMENT).

    - Fix possible object reference leaks in multuple cpufreq drivers
    (Wen Yang).

    - Fix kerneldoc comment in the centrino cpufreq driver (dongjian).

    - Clean up the ACPI and maple cpufreq drivers (Viresh Kumar, Mohan
    Kumar).

    - Add support for lx2160a and ls1028a to the qoriq cpufreq driver
    (Vabhav Sharma, Yuantian Tang).

    - Fix kobject memory leak in the cpufreq core (Viresh Kumar).

    - Simplify the IOwait boosting in the schedutil cpufreq governor and
    rework the TSC cpufreq notifier on x86 (Rafael Wysocki).

    - Clean up the cpufreq core and statistics code (Yue Hu, Kyle Lin).

    - Improve the cpufreq documentation, add SPDX license tags to some PM
    documentation files and unify copyright notices in them (Rafael
    Wysocki).

    - Add support for "CPU" domains to the generic power domains (genpd)
    framework and provide low-level PSCI firmware support for that
    feature (Ulf Hansson).

    - Rearrange the PSCI firmware support code and add support for
    SYSTEM_RESET2 to it (Ulf Hansson, Sudeep Holla).

    - Improve genpd support for devices in multiple power domains (Ulf
    Hansson).

    - Unify target residency for the AFTR and coupled AFTR states in the
    exynos cpuidle driver (Marek Szyprowski).

    - Introduce new helper routine in the operating performance points
    (OPP) framework (Andrew-sh.Cheng).

    - Add support for passing on-die termination (ODT) and auto power
    down parameters from the kernel to Trusted Firmware-A (TF-A) to the
    rk3399_dmc devfreq driver (Enric Balletbo i Serra).

    - Add tracing to devfreq (Lukasz Luba).

    - Make the exynos-bus devfreq driver suspend all devices on system
    shutdown (Marek Szyprowski).

    - Fix a few minor issues in the devfreq subsystem and clean it up
    somewhat (Enric Balletbo i Serra, MyungJoo Ham, Rob Herring,
    Saravana Kannan, Yangtao Li).

    - Improve system wakeup diagnostics (Stephen Boyd).

    - Rework filesystem sync messages emitted during system suspend and
    hibernation (Harry Pan)"

    * tag 'pm-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (72 commits)
    cpufreq: Fix kobject memleak
    cpufreq: armada-37xx: fix frequency calculation for opp
    cpufreq: centrino: Fix centrino_setpolicy() kerneldoc comment
    cpufreq: qoriq: add support for lx2160a
    x86: tsc: Rework time_cpufreq_notifier()
    PM / Domains: Allow to attach a CPU via genpd_dev_pm_attach_by_id|name()
    PM / Domains: Search for the CPU device outside the genpd lock
    PM / Domains: Drop unused in-parameter to some genpd functions
    PM / Domains: Use the base device for driver_deferred_probe_check_state()
    cpufreq: qoriq: Add ls1028a chip support
    PM / Domains: Enable genpd_dev_pm_attach_by_id|name() for single PM domain
    PM / Domains: Allow OF lookup for multi PM domain case from ->attach_dev()
    PM / Domains: Don't kfree() the virtual device in the error path
    cpufreq: Move ->get callback check outside of __cpufreq_get()
    PM / Domains: remove unnecessary unlikely()
    cpufreq: Remove needless bios_limit check in show_bios_limit()
    drivers/cpufreq/acpi-cpufreq.c: This fixes the following checkpatch warning
    firmware/psci: add support for SYSTEM_RESET2
    PM / devfreq: add tracing for scheduling work
    trace: events: add devfreq trace event file
    ...

    Linus Torvalds
     

04 May, 2019

1 commit

  • This adds a function to disable secondary CPUs for suspend that are
    not necessarily non-zero / non-boot CPUs. Platforms will be able to
    use this to suspend using non-zero CPUs.

    Signed-off-by: Nicholas Piggin
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Frederic Weisbecker
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Rafael J . Wysocki
    Cc: Thomas Gleixner
    Cc: linuxppc-dev@lists.ozlabs.org
    Link: https://lkml.kernel.org/r/20190411033448.20842-3-npiggin@gmail.com
    Signed-off-by: Ingo Molnar

    Nicholas Piggin
     

02 Apr, 2019

1 commit


12 Oct, 2018

1 commit

  • Dmitry writes:
    "Input updates for v4.19-rc7

    - we added a few scheduling points into various input interfaces to
    ensure that large writes will not cause RCU stalls
    - fixed configuring PS/2 keyboards as wakeup devices on newer
    platforms
    - added a new Xbox gamepad ID."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
    Input: uinput - add a schedule point in uinput_inject_events()
    Input: evdev - add a schedule point in evdev_write()
    Input: mousedev - add a schedule point in mousedev_write()
    Input: i8042 - enable keyboard wakeups by default when s2idle is used
    Input: xpad - add support for Xbox1 PDP Camo series gamepad

    Greg Kroah-Hartman
     

02 Oct, 2018

1 commit

  • Previously, on typical consumer laptops, pressing a key on the keyboard
    when the system is in suspend would cause it to wake up (default or
    unconditional behaviour). This happens because the EC generates a SCI
    interrupt in this scenario.

    That is no longer true on modern laptops based on Intel WhiskeyLake,
    including Acer Swift SF314-55G, Asus UX333FA, Asus UX433FN and Asus
    UX533FD. We confirmed with Asus EC engineers that the "Modern Standby"
    design has been modified so that the EC no longer generates a SCI
    in this case; the keyboard controller itself should be used for wakeup.

    In order to retain the standard behaviour of being able to use the
    keyboard to wake up the system, enable serio wakeups by default on
    platforms that are using s2idle.

    Link: https://lkml.kernel.org/r/CAB4CAwfQ0mPMqCLp95TVjw4J0r5zKPWkSvvkK4cpZUGE--w8bQ@mail.gmail.com
    Reviewed-by: Rafael J. Wysocki
    Signed-off-by: Daniel Drake
    Signed-off-by: Dmitry Torokhov

    Daniel Drake
     

15 Aug, 2018

1 commit

  • Pull power management updates from Rafael Wysocki:
    "These add a new framework for CPU idle time injection, to be used by
    all of the idle injection code in the kernel in the future, fix some
    issues and add a number of relatively small extensions in multiple
    places.

    Specifics:

    - Add a new framework for CPU idle time injection (Daniel Lezcano).

    - Add AVS support to the armada-37xx cpufreq driver (Gregory
    CLEMENT).

    - Add support for current CPU frequency reporting to the ACPI CPPC
    cpufreq driver (George Cherian).

    - Rework the cooling device registration in the imx6q/thermal driver
    (Bastian Stender).

    - Make the pcc-cpufreq driver refuse to work with dynamic scaling
    governors on systems with many CPUs to avoid scalability issues
    with it (Rafael Wysocki).

    - Fix the intel_pstate driver to report different maximum CPU
    frequencies on systems where they really are different and to
    ignore the turbo active ratio if hardware-managend P-states (HWP)
    are in use; make it use the match_string() helper (Xie Yisheng,
    Srinivas Pandruvada).

    - Fix a minor deferred probe issue in the qcom-kryo cpufreq driver
    (Niklas Cassel).

    - Add a tracepoint for the tracking of frequency limits changes (from
    Andriod) to the cpufreq core (Ruchi Kandoi).

    - Fix a circular lock dependency between CPU hotplug and sysfs
    locking in the cpufreq core reported by lockdep (Waiman Long).

    - Avoid excessive error reports on driver registration failures in
    the ARM cpuidle driver (Sudeep Holla).

    - Add a new device links flag to the driver core to make links go
    away automatically on supplier driver removal (Vivek Gautam).

    - Eliminate potential race condition between system-wide power
    management transitions and system shutdown (Pingfan Liu).

    - Add a quirk to save NVS memory on system suspend for the ASUS 1025C
    laptop (Willy Tarreau).

    - Make more systems use suspend-to-idle (instead of ACPI S3) by
    default (Tristian Celestin).

    - Get rid of stack VLA usage in the low-level hibernation code on
    64-bit x86 (Kees Cook).

    - Fix error handling in the hibernation core and mark an expected
    fall-through switch in it (Chengguang Xu, Gustavo Silva).

    - Extend the generic power domains (genpd) framework to support
    attaching a device to a power domain by name (Ulf Hansson).

    - Fix device reference counting and user limits initialization in the
    devfreq core (Arvind Yadav, Matthias Kaehlcke).

    - Fix a few issues in the rk3399_dmc devfreq driver and improve its
    documentation (Enric Balletbo i Serra, Lin Huang, Nick Milner).

    - Drop a redundant error message from the exynos-ppmu devfreq driver
    (Markus Elfring)"

    * tag 'pm-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (35 commits)
    PM / reboot: Eliminate race between reboot and suspend
    PM / hibernate: Mark expected switch fall-through
    cpufreq: intel_pstate: Ignore turbo active ratio in HWP
    cpufreq: Fix a circular lock dependency problem
    cpu/hotplug: Add a cpus_read_trylock() function
    x86/power/hibernate_64: Remove VLA usage
    cpufreq: trace frequency limits change
    cpufreq: intel_pstate: Show different max frequency with turbo 3 and HWP
    cpufreq: pcc-cpufreq: Disable dynamic scaling on many-CPU systems
    cpufreq: qcom-kryo: Silently error out on EPROBE_DEFER
    cpufreq / CPPC: Add cpuinfo_cur_freq support for CPPC
    cpufreq: armada-37xx: Add AVS support
    dt-bindings: marvell: Add documentation for the Armada 3700 AVS binding
    PM / devfreq: rk3399_dmc: Fix duplicated opp table on reload.
    PM / devfreq: Init user limits from OPP limits, not viceversa
    PM / devfreq: rk3399_dmc: fix spelling mistakes.
    PM / devfreq: rk3399_dmc: do not print error when get supply and clk defer.
    dt-bindings: devfreq: rk3399_dmc: move interrupts to be optional.
    PM / devfreq: rk3399_dmc: remove wait for dcf irq event.
    dt-bindings: clock: add rk3399 DDR3 standard speed bins.
    ...

    Linus Torvalds
     

06 Aug, 2018

1 commit

  • At present, "systemctl suspend" and "shutdown" can run in parrallel. A
    system can suspend after devices_shutdown(), and resume. Then the shutdown
    task goes on to power off. This causes many devices are not really shut
    off. Hence replacing reboot_mutex with system_transition_mutex (renamed
    from pm_mutex) to achieve the exclusion. The renaming of pm_mutex as
    system_transition_mutex can be better to reflect the purpose of the mutex.

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

    Pingfan Liu
     

20 Jun, 2018

1 commit

  • Since swait basically implemented exclusive waits only, make sure
    the API reflects that.

    $ git grep -l -e "\"
    -e "\" | while read file;
    do
    sed -i -e 's/\/&_one/g'
    -e 's/\/&_exclusive/g' $file;
    done

    With a few manual touch-ups.

    Suggested-by: Linus Torvalds
    Signed-off-by: Peter Zijlstra (Intel)
    Signed-off-by: Thomas Gleixner
    Acked-by: Linus Torvalds
    Cc: bigeasy@linutronix.de
    Cc: oleg@redhat.com
    Cc: paulmck@linux.vnet.ibm.com
    Cc: pbonzini@redhat.com
    Link: https://lkml.kernel.org/r/20180612083909.261946548@infradead.org

    Peter Zijlstra
     

27 May, 2018

3 commits

  • The `s2idle_lock' is acquired during suspend while interrupts are
    disabled even on RT. The lock is acquired for short sections only.
    Make it a RAW lock which avoids "sleeping while atomic" warnings on RT.

    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Rafael J. Wysocki

    Sebastian Andrzej Siewior
     
  • s2idle_wait_head is used during s2idle with interrupts disabled even on
    RT. There is no "custom" wake up function so swait could be used instead
    which is also lower weight compared to the wait_queue.
    Make s2idle_wait_head a swait_queue_head.

    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Rafael J. Wysocki

    Sebastian Andrzej Siewior
     
  • timekeeping suspend/resume calls read_persistent_clock() which takes
    rtc_lock. That results in might sleep warnings because at that point
    we run with interrupts disabled.

    We cannot convert rtc_lock to a raw spinlock as that would trigger
    other might sleep warnings.

    As a workaround we disable the might sleep warnings by setting
    system_state to SYSTEM_SUSPEND before calling sysdev_suspend() and
    restoring it to SYSTEM_RUNNING afer sysdev_resume(). There is no lock
    contention because hibernate / suspend to RAM is single-CPU at this
    point.

    In s2idle's case the system_state is set to SYSTEM_SUSPEND before
    timekeeping_suspend() which is invoked by the last CPU. In the resume
    case it set back to SYSTEM_RUNNING after timekeeping_resume() which is
    invoked by the first CPU in the resume case. The other CPUs will block
    on tick_freeze_lock.

    Signed-off-by: Thomas Gleixner
    [bigeasy: cover s2idle in tick_freeze() / tick_unfreeze()]
    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Rafael J. Wysocki

    Thomas Gleixner
     

03 Apr, 2018

1 commit

  • Using this helper allows us to avoid the in-kernel calls to the
    sys_sync() syscall. The ksys_ prefix denotes that this function
    is meant as a drop-in replacement for the syscall. In particular, it
    uses the same calling convention as sys_sync().

    This patch is part of a series which removes in-kernel calls to syscalls.
    On this basis, the syscall entry path can be streamlined. For details, see
    http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.net

    Cc: Alexander Viro
    Signed-off-by: Dominik Brodowski

    Dominik Brodowski
     

09 Nov, 2017

1 commit

  • Problem: This flag does not get cleared currently in the suspend or
    resume path in the following cases:

    * In case some driver's suspend routine returns an error.
    * Successful s2idle case
    * etc?

    Why is this a problem: What happens is that the next suspend attempt
    could fail even though the user did not enable the flag by writing to
    /sys/power/wakeup_count. This is 1 use case how the issue can be seen
    (but similar use case with driver suspend failure can be thought of):

    1. Read /sys/power/wakeup_count
    2. echo count > /sys/power/wakeup_count
    3. echo freeze > /sys/power/wakeup_count
    4. Let the system suspend, and wakeup the system using some wake source
    that calls pm_wakeup_event() e.g. power button or something.
    5. Note that the combined wakeup count would be incremented due
    to the pm_wakeup_event() in the resume path.
    6. After resuming the events_check_enabled flag is still set.

    At this point if the user attempts to freeze again (without writing to
    /sys/power/wakeup_count), the suspend would fail even though there has
    been no wake event since the past resume.

    Address that by clearing the flag just before a resume is completed,
    so that it is always cleared for the corner cases mentioned above.

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

    Rajat Jain
     

29 Sep, 2017

1 commit

  • The role of the ->wake() platform callback for suspend-to-idle is to
    deal with possible spurious wakeups, among other things. The ACPI
    implementation of it, acpi_s2idle_wake(), additionally checks the
    conditions for entering the Low Power S0 Idle state by the platform
    and reports the ones that have not been met.

    However, the ->wake() platform callback is invoked after calling
    dpm_noirq_resume_devices(), which means that the power states of some
    devices may have changed since s2idle_enter() returned, so some unmet
    Low Power S0 Idle conditions may be reported incorrectly as a result
    of that.

    To avoid these false positives, reorder the invocations of the
    dpm_noirq_resume_devices() routine and the ->wake() platform callback
    in s2idle_loop().

    Fixes: 726fb6b4f2a8 (ACPI / PM: Check low power idle constraints for debug only)
    Tested-by: Srinivas Pandruvada
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

11 Aug, 2017

3 commits


05 Aug, 2017

1 commit

  • Modify the ACPI system sleep support setup code to select
    suspend-to-idle as the default system sleep state if
    (1) the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and
    (2) the Low Power Idle S0 _DSM interface has been discovered and
    (3) the default sleep state was not selected from the kernel command
    line.

    The main motivation for this change is that systems where the (1) and
    (2) conditions are met typically ship with OSes that don't exercise
    the S3 path in the platform firmware which remains untested and turns
    out to be non-functional at least in some cases.

    Signed-off-by: Rafael J. Wysocki
    Tested-by: Mario Limonciello

    Rafael J. Wysocki
     

25 Jul, 2017

4 commits

  • Define a common prefix ("PM:") for messages printed by the
    code in kernel/power/suspend.c.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Andy Shevchenko

    Rafael J. Wysocki
     
  • Some messages in suspend.c currently print state names from
    pm_states[], but that may be confusing if the mem_sleep sysfs
    attribute is changed to anything different from "mem", because
    in those cases the messages will say either "freeze" or "standby"
    after writing "mem" to /sys/power/state.

    To avoid the confusion, use mem_sleep_labels[] strings in those
    messages instead.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Andy Shevchenko

    Rafael J. Wysocki
     
  • Restore the pm_wakeup_pending() check in __device_suspend_noirq()
    removed by commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI
    wakeups from suspend-to-idle) as that allows the function to return
    earlier if there's a wakeup event pending already (so that it may
    spend less time on carrying out operations that will be reversed
    shortly anyway) and rework the main suspend-to-idle loop to take
    that optimization into account.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • As a preparation for subsequent changes, rearrange the core
    suspend-to-idle code by moving the initial invocation of
    dpm_suspend_noirq() into s2idle_loop().

    This also causes debug messages from that code to appear in
    a less confusing order.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

22 Jul, 2017

3 commits

  • Regardless of whether or not debug messages from the core system
    suspend/hibernation code are enabled, it is useful to know when
    system-wide transitions start and finish (or fail), so print "info"
    messages at these points.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Mark Salyzyn

    Rafael J. Wysocki
     
  • Debug messages from the system suspend/hibernation infrastructure can
    fill up the entire kernel log buffer in some cases and anyway they
    are only useful for debugging. They depend on CONFIG_PM_DEBUG, but
    that is set as a rule as some generally useful diagnostic facilities
    depend on it too.

    For this reason, avoid printing those messages by default, but make
    it possible to turn them on as needed with the help of a new sysfs
    attribute under /sys/power/.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • Have the core suspend/resume framework store the system-wide suspend
    state (suspend_state_t) we are about to enter, and expose it to drivers
    via pm_suspend_target_state in order to retrieve that. The state is
    assigned in suspend_devices_and_enter().

    This is useful for platform specific drivers that may need to take a
    slightly different suspend/resume path based on the system's
    suspend/resume state being entered.

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

    Florian Fainelli
     

15 Jun, 2017

1 commit

  • The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
    during suspend-to-idle transitions and, consequently, any events
    signaled through it wake up the system from that state. However,
    on some systems some of the events signaled via the ACPI SCI while
    suspended to idle should not cause the system to wake up. In fact,
    quite often they should just be discarded.

    Arguably, systems should not resume entirely on such events, but in
    order to decide which events really should cause the system to resume
    and which are spurious, it is necessary to resume up to the point
    when ACPI SCIs are actually handled and processed, which is after
    executing dpm_resume_noirq() in the system resume path.

    For this reasons, add a loop around freeze_enter() in which the
    platforms can process events signaled via multiplexed IRQ lines
    like the ACPI SCI and add suspend-to-idle hooks that can be
    used for this purpose to struct platform_freeze_ops.

    In the ACPI case, the ->wake hook is used for checking if the SCI
    has triggered while suspended and deferring the interrupt-induced
    system wakeup until the events signaled through it are actually
    processed sufficiently to decide whether or not the system should
    resume. In turn, the ->sync hook allows all of the relevant event
    queues to be flushed so as to prevent events from being missed due
    to race conditions.

    In addition to that, some ACPI code processing wakeup events needs
    to be modified to use the "hard" version of wakeup triggers, so that
    it will cause a system resume to happen on device-induced wakeup
    events even if the "soft" mechanism to prevent the system from
    suspending is not enabled. However, to preserve the existing
    behavior with respect to suspend-to-RAM, this only is done in
    the suspend-to-idle case and only if an SCI has occurred while
    suspended.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

07 Jun, 2017

1 commit

  • Revert commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups
    from suspend-to-idle) as it turned out to be premature and triggered
    a number of different issues on various systems.

    That includes, but is not limited to, premature suspend-to-RAM aborts
    on Dell XPS 13 (9343) reported by Dominik.

    The issue the commit in question attempted to address is real and
    will need to be taken care of going forward, but evidently more work
    is needed for this purpose.

    Reported-by: Dominik Brodowski
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

06 May, 2017

1 commit

  • The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
    during suspend-to-idle transitions and, consequently, any events
    signaled through it wake up the system from that state. However,
    on some systems some of the events signaled via the ACPI SCI while
    suspended to idle should not cause the system to wake up. In fact,
    quite often they should just be discarded.

    Arguably, systems should not resume entirely on such events, but in
    order to decide which events really should cause the system to resume
    and which are spurious, it is necessary to resume up to the point
    when ACPI SCIs are actually handled and processed, which is after
    executing dpm_resume_noirq() in the system resume path.

    For this reasons, add a loop around freeze_enter() in which the
    platforms can process events signaled via multiplexed IRQ lines
    like the ACPI SCI and add suspend-to-idle hooks that can be
    used for this purpose to struct platform_freeze_ops.

    In the ACPI case, the ->wake hook is used for checking if the SCI
    has triggered while suspended and deferring the interrupt-induced
    system wakeup until the events signaled through it are actually
    processed sufficiently to decide whether or not the system should
    resume. In turn, the ->sync hook allows all of the relevant event
    queues to be flushed so as to prevent events from being missed due
    to race conditions.

    In addition to that, some ACPI code processing wakeup events needs
    to be modified to use the "hard" version of wakeup triggers, so that
    it will cause a system resume to happen on device-induced wakeup
    events even if the "soft" mechanism to prevent the system from
    suspending is not enabled (that also helps to catch device-induced
    wakeup events occurring during suspend transitions in progress).

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

20 Jan, 2017

1 commit


22 Nov, 2016

2 commits

  • Modify the ACPI system sleep support setup code to select
    suspend-to-idle as the default system sleep state if the
    ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and the
    default sleep state was not selected from the kernel command
    line.

    Signed-off-by: Rafael J. Wysocki
    Tested-by: Mario Limonciello

    Rafael J. Wysocki
     
  • There are systems in which the platform doesn't support any special
    sleep states, so suspend-to-idle (PM_SUSPEND_FREEZE) is the only
    available system sleep state. However, some user space frameworks
    only use the "mem" and (sometimes) "standby" sleep state labels, so
    the users of those systems need to modify user space in order to be
    able to use system suspend at all and that may be a pain in practice.

    Commit 0399d4db3edf (PM / sleep: Introduce command line argument for
    sleep state enumeration) attempted to address this problem by adding
    a command line argument to change the meaning of the "mem" string in
    /sys/power/state to make it trigger suspend-to-idle (instead of
    suspend-to-RAM).

    However, there also are systems in which the platform does support
    special sleep states, but suspend-to-idle is the preferred one anyway
    (it even may save more energy than the platform-provided sleep states
    in some cases) and the above commit doesn't help in those cases.

    For this reason, rework the system sleep state selection interface
    again (but preserve backwards compatibiliby). Namely, add a new
    sysfs file, /sys/power/mem_sleep, that will control the system
    suspend mode triggered by writing "mem" to /sys/power/state (in
    analogy with what /sys/power/disk does for hibernation). Make it
    select suspend-to-RAM ("deep" sleep) by default (if supported) and
    fall back to suspend-to-idle ("s2idle") otherwise and add a new
    command line argument, mem_sleep_default, allowing that default to
    be overridden if need be.

    At the same time, drop the relative_sleep_states command line
    argument that doesn't make sense any more.

    Signed-off-by: Rafael J. Wysocki
    Tested-by: Mario Limonciello

    Rafael J. Wysocki
     

24 Oct, 2016

1 commit

  • Commit 4bcc595ccd80 (printk: reinstate KERN_CONT for printing
    continuation lines) exposed a missing KERN_CONT from one of the
    messages shown on entering suspend. With v4.9-rc1, the 'done.' shown
    after syncing the filesystems no longer appears as a continuation but
    a new message with its own timestamp.

    [ 9.259566] PM: Syncing filesystems ... [ 9.264119] done.

    Fix this by adding the KERN_CONT log level for the 'done.' part of the
    message seen after syncing filesystems. While we are at it, convert
    these suspend printks to pr_info and pr_cont, respectively.

    Signed-off-by: Jon Hunter
    Signed-off-by: Rafael J. Wysocki

    Jon Hunter
     

13 Sep, 2016

1 commit

  • Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
    in which all of the processors enter deepest possible idle state and
    wait for interrupts right after suspending all the devices.

    There is no hard requirement for a platform to support and register
    platform specific suspend_ops to enter suspend-to-idle/freeze state.
    Only deeper system sleep states like PM_SUSPEND_STANDBY and
    PM_SUSPEND_MEM rely on such low level support/implementation.

    suspend-to-idle can be entered as along as all the devices can be
    suspended. This patch enables the support for suspend-to-idle even on
    systems that don't have any low level support for deeper system sleep
    states and/or don't register any platform specific suspend_ops.

    Signed-off-by: Sudeep Holla
    Tested-by: Andy Gross
    Signed-off-by: Rafael J. Wysocki

    Sudeep Holla
     

28 Jun, 2016

1 commit


23 Mar, 2016

1 commit

  • Use the more common logging method with the eventual goal of removing
    pr_warning altogether.

    Miscellanea:

    - Realign arguments
    - Coalesce formats
    - Add missing space between a few coalesced formats

    Signed-off-by: Joe Perches
    Acked-by: Rafael J. Wysocki [kernel/power/suspend.c]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joe Perches
     

11 Feb, 2016

1 commit


14 Oct, 2015

1 commit

  • There are quite a few cases in which device drivers, bus types or
    even the PM core itself may benefit from knowing whether or not
    the platform firmware will be involved in the upcoming system power
    transition (during system suspend) or whether or not it was involved
    in it (during system resume).

    For this reason, introduce global system suspend flags that can be
    used by the platform code to expose that information for the benefit
    of the other parts of the kernel and make the ACPI core set them
    as appropriate.

    Users of the new flags will be added later.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

01 Aug, 2015

1 commit

  • The Linux kernel suspend path has traditionally invoked sys_sync()
    before freezing user threads.

    But sys_sync() can be expensive, and some user-space OS's do not want
    the kernel to pay the cost of sys_sync() on every suspend -- preferring
    invoke sync() from user-space if/when they want it.

    So make sys_sync on suspend build-time optional.

    The default is unchanged.

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

    Len Brown
     

19 May, 2015

1 commit

  • If a wakeup source is found to be pending in the last stage of
    suspend after syscore suspend, then the machine won't suspend, but
    suspend_enter() will return 0. That is confusing, as wakeup detection
    elsewhere causes -EBUSY to be returned from suspend_enter().

    To avoid the confusion, make suspend_enter() return -EBUSY in that
    case too.

    Signed-off-by: Ruchi Kandoi
    [ rjw: Subject and changelog ]
    Signed-off-by: Rafael J. Wysocki

    Ruchi Kandoi
     

13 May, 2015

1 commit

  • Some of the system suspend diagnostic messages related to
    suspend-to-idle refer to it as "freeze sleep" or "freeze state"
    while the others say "suspend-to-idle". To reduce the possible
    confusion that may result from that, refine the former either to
    say "suspend to idle" too or to make it clearer that what is printed
    is a state string written to /sys/power/state ("mem", "standby",
    or "freeze").

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki