#
d7ef570a |
|
14-Mar-2024 |
Yang Li <yang.lee@linux.alibaba.com> |
ACPI: PM: Improve kerneldoc comments for suspend and hibernation functions This patch enhances the documentation for the ACPI power management functions related to system suspend and hibernation. This includes the use of kernel-doc style comments which provide developers with clearer guidance on the usage and expectations of these functions. Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cb98555f |
|
28-Feb-2024 |
Daniel Drake <drake@endlessos.org> |
Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default" This reverts commit d52848620de00cde4a3a5df908e231b8c8868250, which was originally put in place to work around a s2idle failure on this platform where the NVMe device was inaccessible upon resume. After extended testing, we found that the firmware's implementation of S3 is buggy and intermittently fails to wake up the system. We need to revert to s2idle mode. The NVMe issue has now been solved more precisely in the commit titled "PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge" Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Link: https://lore.kernel.org/r/20240228075316.7404-2-drake@endlessos.org Signed-off-by: Daniel Drake <drake@endlessos.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jian-Hong Pan <jhp@endlessos.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org>
|
#
22db0633 |
|
14-Jun-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep() The addition of might_sleep() to down_timeout() caused the latter to enable interrupts unconditionally in some cases, which in turn broke the ACPI S3 wakeup path in acpi_suspend_enter(), where down_timeout() is called by acpi_disable_all_gpes() via acpi_ut_acquire_mutex(). Namely, if CONFIG_DEBUG_ATOMIC_SLEEP is set, might_sleep() causes might_resched() to be used and if CONFIG_PREEMPT_VOLUNTARY is set, this triggers __cond_resched() which may call preempt_schedule_common(), so __schedule() gets invoked and it ends up with enabled interrupts (in the prev == next case). Now, enabling interrupts early in the S3 wakeup path causes the kernel to crash. Address this by modifying acpi_suspend_enter() to disable GPEs without attempting to acquire the sleeping lock which is not needed in that code path anyway. Fixes: 99409b935c9a ("locking/semaphore: Add might_sleep() to down_*() family") Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
|
#
89d5b717 |
|
01-Jun-2023 |
Arnd Bergmann <arnd@arndb.de> |
ACPI: PM: s2idle: fix section mismatch warning The acpi_sleep_suspend_setup() function is missing an __init annotation, which causes a warning in rare configurations that end up not inlining it into its caller: WARNING: modpost: vmlinux.o: section mismatch in reference: acpi_sleep_suspend_setup (section: .text) -> acpi_s2idle_setup (section: .init.text) It's only called from an __init function, so adding the annotation is correct here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f2cba54a |
|
13-Mar-2023 |
Simon Gaiser <simon@invisiblethingslab.com> |
ACPI: s2idle: Log when enabling wakeup IRQ fails enable_irq_wake() can fail. Previously acpi_s2idle_prepare() silently ignored it's return code. Based on [1] we should try to continue even in case of an error, so just log a warning for now. Discovered when trying to go into s2idle under Xen. This leads to a system that can't be woken, since xen-pirq currently doesn't support setting wakeup IRQs [2]. With this you get at least some helpful log message if you have access to console messages. Link: https://lore.kernel.org/linux-acpi/20230313125344.2893-1-simon@invisiblethingslab.com/ # v1 Link: https://lore.kernel.org/linux-acpi/CAJZ5v0jahjt58nP6P5+xRdtD_ndYPvq4ecMVz6nfGu9tf5iaUw@mail.gmail.com/ # [1] Link: https://lore.kernel.org/xen-devel/20230313134102.3157-1-simon@invisiblethingslab.com/ # [2] Signed-off-by: Simon Gaiser <simon@invisiblethingslab.com> [ rjw: Adjust white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fe0ba8c2 |
|
17-Jan-2023 |
Juergen Gross <jgross@suse.com> |
acpi: Fix suspend with Xen PV Commit f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") missed one code path accessing real_mode_header, leading to dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20 Fix that by adding an optional acpi callback allowing to skip setting the wakeup address, as in the Xen PV case this will be handled by the hypervisor anyway. Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/all/20230117155724.22940-1-jgross%40suse.com
|
#
38f34dba |
|
29-Sep-2022 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
PM: ACPI: reboot: Reinstate S5 for reboot Commit d60cd06331a3 ("PM: ACPI: reboot: Use S5 for reboot") caused Dell PowerEdge r440 hangs at reboot. The issue is fixed by commit 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER"), so use the new sysoff API to reinstate S5 for reboot on ACPI-based systems. Using S5 for reboot is default behavior under Windows: "A full shutdown (S5) occurs when a system restart is requested" [1]. Link: https://docs.microsoft.com/en-us/windows/win32/power/system-power-state # [1] Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ec6c0503 |
|
21-Jul-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: x86: Print messages regarding LPS0 idle support Because suspend-to-idle is always supported and on x86 it is the only way to suspend the system if S3 is not supported by the platform, the kernel attempts to enter low-power S0 idle in the suspend-to-idle flow regardless of whether or not the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT. However, if that flag is not set, residency counters associated with low-power S0 idle may not count and the platform may refuse to put the EC into a low-power mode, for example. For this reason, print diagnostic messages when the platform should achieve significant energy savings in low-power S0 idle (because the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT) and when suspend-to-idle becomes the default suspend method (because low-power S0 idle should be equally or more efficient than S3, if available). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
|
#
4b7ef7b0 |
|
22-Jun-2022 |
Manyi Li <limanyi@uniontech.com> |
ACPI: PM: save NVS memory for Lenovo G40-45 [821d6f0359b0614792ab8e2fb93b503e25a65079] is to make machines produced from 2012 to now not saving NVS region to accelerate S3. But, Lenovo G40-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Signed-off-by: Manyi Li <limanyi@uniontech.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
98f30d0e |
|
09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
ACPI: power: Switch to sys-off handler API Switch to sys-off API that replaces legacy pm_power_off callbacks, allowing us to remove global pm_* variables and support chaining of all restart and power-off modes consistently. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d5284862 |
|
10-May-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default ASUS B1400CEAE fails to resume from suspend to idle by default. This was bisected back to commit df4f9bc4fb9c ("nvme-pci: add support for ACPI StorageD3Enable property") but this is a red herring to the problem. Before this commit the system wasn't getting into deepest sleep state. Presumably this commit is allowing entry into deepest sleep state as advertised by firmware, but there are some other problems related to the wakeup. As it is confirmed the system works properly with S3, set the default for this system to S3. Reported-by: Jian-Hong Pan <jhp@endlessos.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Jian-Hong Pan <jhp@endlessos.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f6c46b1d |
|
11-Mar-2022 |
David Woodhouse <dwmw@amazon.co.uk> |
PM: hibernate: Honour ACPI hardware signature by default for virtual guests The ACPI specification says that OSPM should refuse to restore from hibernate if the hardware signature changes, and should boot from scratch. However, real BIOSes often vary the hardware signature in cases where we *do* want to resume from hibernate, so Linux doesn't follow the spec by default. However, in a virtual environment there's no reason for the VMM to vary the hardware signature *unless* it wants to trigger a clean reboot as defined by the ACPI spec. So enable the check by default if a hypervisor is detected. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
631e3893 |
|
01-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Print additional debug message in acpi_s2idle_wake() Make acpi_s2idle_wake() print an additional debug message when the SCI is going to be rearmed for system wakeup to help diagnose wakeup-related issues. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cb1f65c1 |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: s2idle: ACPI: Fix wakeup interrupts handling After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") wakeup interrupts occurring immediately after the one discarded by acpi_s2idle_wake() may be missed. Moreover, if the SCI triggers again immediately after the rearming in acpi_s2idle_wake(), that wakeup may be missed too. The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() when pm_wakeup_irq is 0, but that's not the case any more after the interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is cleared by the pm_wakeup_clear() call in s2idle_loop(). However, there may be wakeup interrupts occurring in that time frame and if that happens, they will be missed. To address that issue first move the clearing of pm_wakeup_irq to the point at which it is known that the interrupt causing acpi_s2idle_wake() to tun will be discarded, before rearming the SCI for wakeup. Moreover, because that only reduces the size of the time window in which the issue may manifest itself, allow pm_system_irq_wakeup() to register two second wakeup interrupts in a row and, when discarding the first one, replace it with the second one. [Of course, this assumes that only one wakeup interrupt can be discarded in one go, but currently that is the case and I am not aware of any plans to change that.] Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
dc0075ba |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") made acpi_ec_dispatch_gpe() check pm_wakeup_pending(), but that is before canceling the SCI wakeup, so pm_wakeup_pending() is always true. This causes the loop in acpi_ec_dispatch_gpe() to always terminate after one iteration which may not be correct. Address this issue by canceling the SCI wakeup earlier, from acpi_ec_dispatch_gpe() itself. Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3c89857a |
|
09-Dec-2021 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
ACPI: PM: Remove redundant cache flushing ACPICA code takes care about cache flushing on S1/S2/S3 in acpi_hw_extended_sleep() and acpi_hw_legacy_sleep(). acpi_suspend_enter() calls into ACPICA code via acpi_enter_sleep_state() for S1 or x86_acpi_suspend_lowlevel() for S3. acpi_sleep_prepare() call tree: __acpi_pm_prepare() acpi_pm_prepare() acpi_suspend_ops::prepare_late() acpi_hibernation_ops::pre_snapshot() acpi_hibernation_ops::prepare() acpi_suspend_begin_old() acpi_suspend_begin_old::begin() acpi_hibernation_begin_old() acpi_hibernation_ops_old::acpi_hibernation_begin_old() acpi_power_off_prepare() pm_power_off_prepare() Hibernation (S4) and Power Off (S5) don't require cache flushing, so the only interesting callsites are acpi_suspend_ops::prepare_late() and acpi_suspend_begin_old::begin(). Both of them have cache flush on ->enter() operation in acpi_suspend_enter(). Remove redundant ACPI_FLUSH_CPU_CACHE() in acpi_sleep_prepare() and acpi_suspend_enter(). Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
53d01e20 |
|
06-Dec-2021 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
ACPI: PM: Avoid CPU cache flush when entering S4 According to ACPI 6.4, Section 16.2, the CPU cache flushing is required on entering to S1, S2, and S3. No need to flush the caches during hibernation (S4). Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
74d95555 |
|
08-Nov-2021 |
David Woodhouse <dwmw@amazon.co.uk> |
PM: hibernate: Allow ACPI hardware signature to be honoured Theoretically, when the hardware signature in FACS changes, the OS is supposed to gracefully decline to attempt to resume from S4: "If the signature has changed, OSPM will not restore the system context and can boot from scratch" In practice, Windows doesn't do this and many laptop vendors do allow the signature to change especially when docking/undocking, so it would be a bad idea to simply comply with the specification by default in the general case. However, there are use cases where we do want the compliant behaviour and we know it's safe. Specifically, when resuming virtual machines where we know the hypervisor has changed sufficiently that resume will fail. We really want to be able to *tell* the guest kernel not to try, so it boots cleanly and doesn't just crash. This patch provides a way to opt in to the spec-compliant behaviour on the command line. A follow-up patch may do this automatically for certain "known good" machines based on a DMI match, or perhaps just for all hypervisor guests since there's no good reason a hypervisor would change the hardware_signature that it exposes to guests *unless* it wants them to obey the ACPI specification. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d69d1f70 |
|
20-Oct-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: sleep: Do not set suspend_ops unnecessarily If none of the S1 - S3 sleep states is supported, it is not necessary to register suspend_ops, so don't do that then. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
aa3a522c |
|
10-Jun-2021 |
Yang Li <yang.lee@linux.alibaba.com> |
ACPI: sleep: Fix acpi_pm_pre_suspend() kernel-doc Fix function name in sleep.c kernel-doc comment to remove a warning found by running make W=1 LLVM=1. drivers/acpi/sleep.c:413: warning: expecting prototype for acpi_pre_suspend(). Prototype was for acpi_pm_pre_suspend() instead. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f5ee87df |
|
02-Jun-2021 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI: sleep: Unify the message printing Intoduce pr_fmt() and use pr_*() macros to replace printk(), also remove all the PREFIX for pr_*() calls to generate a unified format string for prefix. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6381195a |
|
24-May-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: power: Rework turning off unused power resources Make turning off unused power resources (after the enumeration of devices and during system-wide resume from S3) more straightforward by using the observation that the power resource state stored in struct acpi_power_resource can be used to determine whether or not the give power resource has any users. Namely, when the state of the power resource is unknown, its _STA method has never been evaluated (or the evaluation of it has failed) and its _ON and _OFF methods have never been executed (or they have failed to execute), so for all practical purposes it can be assumed to have no users (or to be unusable). Therefore, instead of checking the number of power resource users, it is sufficient to check if its state is known. Moreover, if the last known state of a given power resource is "off", it is not necessary to turn it off, because it has been used to initialize the power state or the wakeup power resources list of at least one device and either its _STA method has returned 0 ("off"), or its _OFF method has been successfully executed already. Accordingly, modify acpi_turn_off_unused_power_resources() to do the above checks (which are suitable for both uses of it) instead of using the number of power resource users or evaluating its _STA method, drop its argument (which is not useful any more) and update its callers. Also drop the users field from struct acpi_power_resource as it is not useful any more. Tested-by: Dave Olsthoorn <dave@bewaar.me> Tested-by: Shujun Wang <wsj20369@163.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f1ffa9d4 |
|
02-Jun-2021 |
Zhang Rui <rui.zhang@intel.com> |
Revert "ACPI: sleep: Put the FACS table after using it" Commit 95722237cb2a ("ACPI: sleep: Put the FACS table after using it") puts the FACS table during initialization. But the hardware signature bits in the FACS table need to be accessed, after every hibernation, to compare with the original hardware signature. So there is no reason to release the FACS table mapping after initialization. This reverts commit 95722237cb2ae4f7b73471058cdb19e8f4057c93. An alternative solution is to use acpi_gbl_FACS variable instead, which is mapped by the ACPICA core and never released. Link: https://bugzilla.kernel.org/show_bug.cgi?id=212277 Reported-by: Stephan Hohe <sth.dev@tejp.de> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: 5.8+ <stable@vger.kernel.org> # 5.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9b7ff25d |
|
21-May-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: power: Refine turning off unused power resources Commit 7e4fdeafa61f ("ACPI: power: Turn off unused power resources unconditionally") dropped the power resource state check from acpi_turn_off_unused_power_resources(), because according to the ACPI specification (e.g. ACPI 6.4, Section 7.2.2) the OS "may run the _OFF method repeatedly, even if the resource is already off". However, it turns out that some systems do not follow the specification in this particular respect and that commit introduced boot issues on them, so refine acpi_turn_off_unused_power_resources() to only turn off power resources without any users after device enumeration and restore its previous behavior in the system-wide resume path. Fixes: 7e4fdeafa61f ("ACPI: power: Turn off unused power resources unconditionally") Link: https://uefi.org/specs/ACPI/6.4/07_Power_and_Performance_Mgmt/declaring-a-power-resource-object.html#off BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213019 Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Reported-by: Dave Olsthoorn <dave@bewaar.me> Tested-by: Dave Olsthoorn <dave@bewaar.me> Reported-by: Shujun Wang <wsj20369@163.com> Tested-by: Shujun Wang <wsj20369@163.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fef98671 |
|
17-Dec-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Move x86-specific code to the x86 directory Some code in drivers/acpi/sleep.c (which is regarded as a generic file) related to suspend-to-idle support has grown direct dependencies on x86, but in fact it has been specific to x86 (which is the only user of it) anyway for a long time. For this reason, move that code to a separate file under acpi/x86/ and make it build and run as before under the right conditions. While at it, rename a vendor checking function in that code and consistently use acpi_handle_debug() for printing debug-related information in it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
146f1ed8 |
|
19-Nov-2020 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
ACPI: PM: s2idle: Add AMD support to handle _DSM Initial support for S2Idle based on the Intel implementation [1] does not work for AMD as the BIOS implementation for ACPI methods like the _DSM are not standardized. So, the way in which the UUID's were parsed and the ACPI packages were retrieved out of the ACPI objects are not the same between Intel and AMD. Add AMD support for S2Idle to parse the UUID, evaluate the _DSM methods, prepare the Idle constraint list etc. Link: https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf # [1] Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3441362b |
|
19-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Print type of wakeup debug messages Since acpi_s2idle_wake() knows the category of wakeup causing the system to resume from suspend-to-idle, make it print a unique message for each of them to help diagnose wakeup issues. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
607b9df6 |
|
14-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive Flushing the EC work while suspended to idle when the EC GPE status is not set causes some EC wakeup events (notably power button and lid ones) to be missed after a series of spurious wakeups on the Dell XPS13 9360 in my office. If that happens, the machine cannot be woken up from suspend-to-idle by the power button or lid status change and it needs to be woken up in some other way (eg. by a key press). Flushing the EC work only after successful dispatching the EC GPE, which means that its status has been set, avoids the issue, so change the code in question accordingly. Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Chris Chiu <chiu@endlessm.com>
|
#
7b301750 |
|
09-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake() If the EC GPE status is not set after checking all of the other GPEs, acpi_s2idle_wake() returns 'false', to indicate that the SCI event that has just triggered is not a system wakeup one, but it does that without canceling the pending wakeup and re-arming the SCI for system wakeup which is a mistake, because it may cause s2idle_loop() to busy spin until the next valid wakeup event. [If that happens, the first spurious wakeup is still pending after acpi_s2idle_wake() has returned, so s2idle_enter() does nothing, acpi_s2idle_wake() is called again and it sees that the SCI has triggered, but no GPEs are active, so 'false' is returned again, and so on.] Fix that by moving all of the GPE checking logic from acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the latter return 'true' only if a non-EC GPE has triggered and 'false' otherwise, which will cause acpi_s2idle_wake() to cancel the pending SCI wakeup and re-arm the SCI for system wakeup regardless of the EC GPE status. This also addresses a lockup observed on an Elitegroup EF20EA laptop after attempting to wake it up from suspend-to-idle by a key press. Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check") Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603 Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Link: https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=MvyG_PE+PGVfeA17AHF5i5JucgaKqqMX6mjArbQ@mail.gmail.com/ Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu <chiu@endlessm.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
95722237 |
|
07-May-2020 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI: sleep: Put the FACS table after using it Put the FACS table after using it to release the table mapping. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ddfd9dcf |
|
03-Apr-2020 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: PM: Add acpi_[un]register_wakeup_handler() Since commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") the SCI triggering without there being a wakeup cause recognized by the ACPI sleep code will no longer wakeup the system. This works as intended, but this is a problem for devices where the SCI is shared with another device which is also a wakeup source. In the past these, from the pov of the ACPI sleep code, spurious SCIs would still cause a wakeup so the wakeup from the device sharing the interrupt would actually wakeup the system. This now no longer works. This is a problem on e.g. Bay Trail-T and Cherry Trail devices where some peripherals (typically the XHCI controller) can signal a Power Management Event (PME) to the Power Management Controller (PMC) to wakeup the system, this uses the same interrupt as the SCI. These wakeups are handled through a special INT0002 ACPI device which checks for events in the GPE0a_STS for this and takes care of acking the PME so that the shared interrupt stops triggering. The change to the ACPI sleep code to ignore the spurious SCI, causes the system to no longer wakeup on these PME events. To make things worse this means that the INT0002 device driver interrupt handler will no longer run, causing the PME to not get cleared and resulting in the system hanging. Trying to wakeup the system after such a PME through e.g. the power button no longer works. Add an acpi_register_wakeup_handler() function which registers a handler to be called from acpi_s2idle_wake() and when the handler returns true, return true from acpi_s2idle_wake(). The INT0002 driver will use this mechanism to check the GPE0a_STS register from acpi_s2idle_wake() and to tell the system to wakeup if a PME is signaled in the register. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d5406284 |
|
25-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Refine active GPEs check The check for any active GPEs added by commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") turns out to be insufficiently precise to prevent some systems from resuming prematurely due to a spurious EC wakeup, so refine it by first checking if any GPEs other than the EC GPE are active and skipping all of the SCIs coming from the EC that do not produce any genuine wakeup events after processing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629 Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Reported-by: Ondřej Caletka <ondrej@caletka.cz> Tested-by: Ondřej Caletka <ondrej@caletka.cz> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0ce792d6 |
|
25-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE The check carried out by acpi_any_gpe_status_set() is not precise enough for the suspend-to-idle implementation in Linux and in some cases it is necessary make it skip one GPE (specifically, the EC GPE) from the check to prevent a race condition leading to a premature system resume from occurring. For this reason, redefine acpi_any_gpe_status_set() to take the number of a GPE to skip as an argument. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629 Tested-by: Ondřej Caletka <ondrej@caletka.cz> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
243a9889 |
|
20-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late() Fix a comment in acpi_s2idle_prepare_late() that has become outdated after commit f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work"). Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
63fb9623 |
|
20-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake() Commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") overlooked the fact that fixed events can wake up the system too and broke RTC wakeup from suspend-to-idle as a result. Fix this issue by checking the fixed events in acpi_s2idle_wake() in addition to checking wakeup GPEs and break out of the suspend-to-idle loop if the status bits of any enabled fixed events are set then. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
fdde0ff8 |
|
11-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system If the platform triggers a spurious SCI even though the status bit is not set for any GPE when the system is suspended to idle, it will be treated as a genuine wakeup, so avoid that by checking if any GPEs are active at all before returning 'true' from acpi_s2idle_wake(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=206413 Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Reported-by: Tsuchiya Yuto <kitakar@gmail.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e3728b50 |
|
11-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Avoid possible race related to the EC GPE It is theoretically possible for the ACPI EC GPE to be set after the s2idle_ops->wake() called from s2idle_loop() has returned and before the subsequent pm_wakeup_pending() check is carried out. If that happens, the resulting wakeup event will cause the system to resume even though it may be a spurious one. To avoid that race, first make the ->wake() callback in struct platform_s2idle_ops return a bool value indicating whether or not to let the system resume and rearrange s2idle_loop() to use that value instad of the direct pm_wakeup_pending() call if ->wake() is present. Next, rework acpi_s2idle_wake() to process EC events and check pm_wakeup_pending() before re-arming the SCI for system wakeup to prevent it from triggering prematurely and add comments to that function to explain the rationale for the new code flow. Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8c53b318 |
|
26-Nov-2019 |
Sean Christopherson <seanjc@google.com> |
ACPI/sleep: Convert acpi_wakeup_address into a function Convert acpi_wakeup_address from a raw variable into a function so that x86 can wrap its dereference of the real mode boot header in a function instead of broadcasting it to the world via a #define. This sets the stage for a future patch to move x86's definition of the new function, acpi_get_wakeup_address(), out of asm/acpi.h and thus break acpi.h's dependency on asm/realmode.h. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Link: https://lkml.kernel.org/r/20191126165417.22423-12-sean.j.christopherson@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
024aa873 |
|
28-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Rework ACPI events synchronization Note that the EC GPE processing need not be synchronized in acpi_s2idle_wake() after invoking acpi_ec_dispatch_gpe(), because that function checks the GPE status and dispatches its handler if need be and the SCI action handler is not going to run anyway at that point. Moreover, it is better to drain all of the pending ACPI events before restoring the working-state configuration of GPEs in acpi_s2idle_restore(), because those events are likely to be related to system wakeup, in which case they will not be relevant going forward. Rework the code to take these observations into account. Tested-by: Kenneth R. Crudup <kenny@panix.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2189624b |
|
26-Sep-2019 |
Mario Limonciello <mario.limonciello@dell.com> |
ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist This reverts part of commit 71630b7a832f ("ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360") to remove the S0ix blacklist for the XPS 9360. The problems with this system occurred in one possible NVME SSD when putting system into s0ix. As the NVME sleep behavior has been adjusted in commit d916b1be94b6 ("nvme-pci: use host managed power state for suspend") this is expected to be now resolved. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196907 Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b90ff355 |
|
21-Aug-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Always set up EC GPE for system wakeup Commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") assumed that the EC GPE would only need to be set up for system wakeup if either the intel-hid or the intel-vbtn driver was in use, but that turns out to be incorrect. In particular, on ASUS Zenbook UX430UNR/i7-8550U, if the EC GPE is not enabled while suspended, the system cannot be woken up by opening the lid or pressing a key, and that machine doesn't use any of the drivers mentioned above. For this reason, always set up the EC GPE for system wakeup from suspend-to-idle by setting and clearing its wake mask in the ACPI suspend-to-idle callbacks. Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") Reported-by: Kristian Klausen <kristian@klausen.dk> Tested-by: Kristian Klausen <kristian@klausen.dk> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
45dc1576 |
|
18-Aug-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Avoid rearming SCI for wakeup unnecessarily It is only necessary to rearm the ACPI SCI for wakeup if pm_system_cancel_wakeup() has been called, so invoke rearm_wake_irq() only in that case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ac9eafbe |
|
01-Aug-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Execute LPS0 _DSM functions with suspended devices According to Section 3.5 of the "Intel Low Power S0 Idle" document [1], Function 5 of the LPS0 _DSM is expected to be invoked when the system configuration matches the criteria for entering the target low-power state of the platform. In particular, this means that all devices should be suspended and in low-power states already when that function is invoked. This is not the case currently, however, because Function 5 of the LPS0 _DSM is invoked by it before the "noirq" phase of device suspend, which means that some devices may not have been put into low-power states yet at that point. That is a consequence of the previous design of the suspend-to-idle flow that allowed the "noirq" phase of device suspend and the "noirq" phase of device resume to be carried out for multiple times while "suspended" (if any spurious wakeup events were detected) and the point of the LPS0 _DSM Function 5 invocation was chosen so as to call it (and LPS0 _DSM Function 6 analogously) once per suspend-resume cycle (regardless of how many times the "noirq" phases of device suspend and resume were carried out while "suspended"). Now that the suspend-to-idle flow has been redesigned to carry out the "noirq" phases of device suspend and resume once in each cycle, the code can be reordered to follow the specification that it is based on more closely. For this purpose, add ->prepare_late and ->restore_early platform callbacks for suspend-to-idle, to be executed, respectively, after the "noirq" phase of suspending devices and before the "noirq" phase of resuming them and make ACPI use them for the invocation of LPS0 _DSM functions as appropriate. While at it, move the LPS0 entry requirements check to be made before invoking Functions 3 and 5 of the LPS0 _DSM (also once per cycle) as follows from the specification [1]. Link: https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf # [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
6e86633a |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Eliminate acpi_sleep_no_ec_events() Change acpi_ec_suspend() to use pm_suspend_no_platform() instead of acpi_sleep_no_ec_events(), which allows the latter to be eliminated along with the s2idle_in_progress variable which is only used by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
068b47d0 |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Add acpi.sleep_no_lps0 module parameter Add a module parameter to prevent the ACPI LPS0 _DSM functions from being invoked (if need be) and rework the suspend-to-idle blacklist entries in acpisleep_dmi_table[] to make them simply prevent suspend-to-idle from being used by default on the systems in question (which really is the original purpose of those entries). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
2e2c2fdc |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Rearrange lps0_device_attach() To allow a subsequent change to be simpler, rearrange the code in lps0_device_attach() to reduce the indentation level and (while at it) make it avoid calling lpi_device_get_constraints() when lps0_device_handle is not going to be set. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
10a08fd6 |
|
30-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Set up EC GPE for system wakeup from drivers that need it The EC GPE needs to be set up for system wakeup only if there is a driver depending on it, either intel-hid or intel-vbtn, bound to a button device that is expected to wake up the system from sleep (such as the power button on some Dell systems, like the XPS13 9360). It doesn't need to be set up for waking up the system from sleep in any other cases and whether or not it is expected to wake up the system from sleep doesn't depend on whether or not the LPS0 device is present in the ACPI namespace. For this reason, rearrange the ACPI suspend-to-idle code to make the drivers depending on the EC GPE wakeup take care of setting it up and decouple that from the LPS0 device handling. While at it, make intel-hid and intel-vbtn prepare for system wakeup only if they are allowed to wake up the system from sleep by user space (via sysfs). [Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask() are there to prevent the EC GPE from being disabled by the acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on systems with either intel-hid or intel-vbtn this change doesn't affect any interactions with the hardware or platform firmware.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
56b99184 |
|
15-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: Simplify suspend-to-idle control flow After commit 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") the "noirq" phases of device suspend and resume may run for multiple times during suspend-to-idle, if there are spurious system wakeup events while suspended. However, this is complicated and fragile and actually unnecessary. The main reason for doing this is that on some systems the EC may signal system wakeup events (power button events, for example) as well as events that should not cause the system to resume (spurious system wakeup events). Thus, in order to determine whether or not a given event signaled by the EC while suspended is a proper system wakeup one, the EC GPE needs to be dispatched and to start with that was achieved by allowing the ACPI SCI action handler to run, which was only possible after calling resume_device_irqs(). However, dispatching the EC GPE this way turned out to take too much time in some cases and some EC events might be missed due to that, so commit 68e22011856f ("ACPI: EC: Dispatch the EC GPE directly on s2idle wake") started to dispatch the EC GPE right after a wakeup event has been detected, so in fact the full ACPI SCI action handler doesn't need to run any more to deal with the wakeups coming from the EC. Use this observation to simplify the suspend-to-idle control flow so that the "noirq" phases of device suspend and resume are each run only once in every suspend-to-idle cycle, which is reported to significantly reduce power drawn by some systems when suspended to idle (by allowing them to reach a deep platform-wide low-power state through the suspend-to-idle flow). [What appears to happen is that the "noirq" resume of devices after a spurious EC wakeup brings some devices into a state in which they prevent the platform from reaching the deep low-power state going forward, even after a subsequent "noirq" suspend phase, and on some systems the EC triggers such wakeups already when the "noirq" suspend of devices is running for the first time in the given suspend/resume cycle, so the platform cannot reach the deep low-power state at all.] First, make acpi_s2idle_wake() use the acpi_ec_dispatch_gpe() return value to determine whether or not the wakeup may have been triggered by the EC (in which case the system wakeup is canceled and ACPI events are processed in order to determine whether or not the event is a proper system wakeup one) and use rearm_wake_irq() (introduced by a previous change) in it to rearm the ACPI SCI for system wakeup detection in case the system will remain suspended. Second, drop acpi_s2idle_sync(), which is not needed any more, and the corresponding global platform suspend-to-idle callback. Next, drop the pm_wakeup_pending() check (which is an optimization only) from __device_suspend_noirq() to prevent it from returning errors on system wakeups occurring before the "noirq" phase of device suspend is complete (as in the case of suspend-to-idle it is not known whether or not these wakeups are suprious at that point), in order to avoid having to carry out a "noirq" resume of devices on a spurious system wakeup. Finally, change the code flow in s2idle_loop() to (1) run the "noirq" suspend of devices once before starting the loop, (2) check for spurious EC wakeups (via the platform ->wake callback) for the first time before calling s2idle_enter(), and (3) run the "noirq" resume of devices once after leaving the loop. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
41275eb5 |
|
15-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Set s2idle_wakeup earlier and clear it later The role of the s2idle_wakeup variable is to cause acpi_pm_wakeup_event() and acpi_pm_notify_handler() to increment pm_abort_suspend and trigger a wakeup from suspend-to-idle in case the ACPI SCI wakeup was canceled by acpi_s2idle_wake(). However, for this purpose it need not be set in acpi_s2idle_wake() and cleared in acpi_s2idle_sync(), respectively. In fact, it may be set as early as in acpi_s2idle_prepare() and cleared as late as in acpi_s2idle_restore(), so do that to allow subsequent changes to be simpler. This change is not expected to alter functionality. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
ad5a449b |
|
03-Jul-2019 |
Dexuan Cui <decui@microsoft.com> |
ACPI: PM: Make acpi_sleep_state_supported() non-static With some upcoming patches to save/restore the Hyper-V drivers related states, a Linux VM running on Hyper-V will be able to hibernate. When a Linux VM hibernates, unluckily we must disable the memory hot-add/remove and balloon up/down capabilities in the hv_balloon driver (drivers/hv/hv_balloon.c), because these can not really work according to the design of the related back-end driver on the host. By default, Hyper-V does not enable the virtual ACPI S4 state for a VM; on recent Hyper-V hosts, the administrator is able to enable the virtual ACPI S4 state for a VM, so we hope to use the presence of the virtual ACPI S4 state as a hint for hv_balloon to disable the aforementioned capabilities. In this way, hibernation will work more reliably, from the user's perspective. By marking acpi_sleep_state_supported() non-static, we'll be able to implement a hv_is_hibernation_supported() API in the always-built-in module arch/x86/hyperv/hv_init.c, and the API will be called by hv_balloon. Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
418e3ea1 |
|
14-Jun-2019 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
bus_find_device: Unify the match callback with class_find_device There is an arbitrary difference between the prototypes of bus_find_device() and class_find_device() preventing their callers from passing the same pair of data and match() arguments to both of them, which is the const qualifier used in the prototype of class_find_device(). If that qualifier is also used in the bus_find_device() prototype, it will be possible to pass the same match() callback function to both bus_find_device() and class_find_device(), which will allow some optimizations to be made in order to avoid code duplication going forward. Also with that, constify the "data" parameter as it is passed as a const to the match function. For this reason, change the prototype of bus_find_device() to match the prototype of class_find_device() and adjust its callers to use the const qualifier in accordance with the new prototype of it. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Corey Minyard <minyard@acm.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Kershner <david.kershner@unisys.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Airlie <airlied@linux.ie> Cc: Felipe Balbi <balbi@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonathan Cameron <jic23@kernel.org> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michael Jamet <michael.jamet@intel.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Sebastian Ott <sebott@linux.ibm.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: rafael@kernel.org Acked-by: Corey Minyard <minyard@acm.org> Acked-by: David Kershner <david.kershner@unisys.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a3487d8f |
|
12-Jun-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
ACPI / sleep: Switch to use acpi_dev_get_first_match_dev() Switch the acpi_pm_finish() to use acpi_dev_get_first_match_dev() instead of custom approach. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
55716d26 |
|
01-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 428 Based on 1 normalized pattern(s): this file is released under the gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 68 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bb186901 |
|
15-May-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Call pm_set_suspend_via_firmware() during hibernation On systems with ACPI platform firmware the last stage of hibernation is analogous to system suspend to S3 (suspend-to-RAM), so it should be handled analogously. In particular, pm_suspend_via_firmware() should return 'true' in that stage to let the callers of it know that control will be passed to the platform firmware going forward, so pm_set_suspend_via_firmware() needs to be called then in analogy with acpi_suspend_begin(). However, the platform hibernation ->begin() callback is invoked during the "freeze" transition (before creating a snapshot image of system memory) as well as during the "hibernate" transition which is the last stage of it and pm_set_suspend_via_firmware() should be invoked by that callback in the latter stage only. In order to implement that redefine the hibernation ->begin() callback to take a pm_message_t argument to indicate which stage of hibernation is taking place and rework acpi_hibernation_begin() and acpi_hibernation_begin_old() to take it into account as needed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2f844b61 |
|
13-May-2019 |
Rajat Jain <rajatja@google.com> |
ACPI: PM: Set enable_for_wake for wakeup GPEs during suspend-to-idle I noticed that recently multiple systems (chromebooks) couldn't wake from S0ix using LID or Keyboard after updating to a newer kernel. I bisected and it turned up commit f941d3e41da7 ("ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle"). I checked that the issue got fixed if that commit was reverted. I debugged and found that although PNP0C0D:00 (representing the LID) is wake capable and should wakeup the system per the code in acpi_wakeup_gpe_init() and in drivers/acpi/button.c: localhost /sys # cat /proc/acpi/wakeup Device S-state Status Sysfs node LID0 S4 *enabled platform:PNP0C0D:00 CREC S5 *disabled platform:GOOG0004:00 *disabled platform:cros-ec-dev.1.auto *disabled platform:cros-ec-accel.0 *disabled platform:cros-ec-accel.1 *disabled platform:cros-ec-gyro.0 *disabled platform:cros-ec-ring.0 *disabled platform:cros-usbpd-charger.2.auto *disabled platform:cros-usbpd-logger.3.auto D015 S3 *enabled i2c:i2c-ELAN0000:00 PENH S3 *enabled platform:PRP0001:00 XHCI S3 *enabled pci:0000:00:14.0 GLAN S4 *disabled WIFI S3 *disabled pci:0000:00:14.3 localhost /sys # On debugging, I found that its corresponding GPE is not being enabled. The particular GPE's "gpe_register_info->enable_for_wake" does not have any bits set when acpi_enable_all_wakeup_gpes() comes around to use it. I looked at code and could not find any other code path that should set the bits in "enable_for_wake" bitmask for the wake enabled devices for s2idle. [I do see that it happens for S3 in acpi_sleep_prepare()]. Thus I used the same call to enable the GPEs for wake enabled devices, and verified that this fixes the regression I was seeing on multiple of my devices. [ rjw: The problem is that commit f941d3e41da7 ("ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle") forgot to add the acpi_enable_wakeup_devices() call for s2idle along with acpi_enable_all_wakeup_gpes(). ] Fixes: f941d3e41da7 ("ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle") Link: https://bugzilla.kernel.org/show_bug.cgi?id=203579 Signed-off-by: Rajat Jain <rajatja@google.com> [ rjw: Subject & changelog ] Cc: 5.0+ <stable@vger.kernel.org> # 5.0+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7edcbbf2 |
|
16-Dec-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Loop in full LPS0 mode only After a previous change, all non-wakeup GPEs are disabled for suspend-to-idle unless full Low-Power S0 (LPS0) mode is in use, so it is not necessary to do anything in acpi_s2idle_wake() unless in full LPS0 mode, which is only when lps0_device_handle is set. Modify the code accordingly. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f941d3e4 |
|
16-Dec-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle There are systems in which non-wakeup GPEs fire during the "noirq" suspend stage of suspending devices and that effectively prevents the system that tries to suspend to idle from entering any low-power state at all. If the offending GPE fires regularly and often enough, the system appears to be suspended, but in fact it is in a tight loop over "noirq" suspend and "noirq" resume of devices all the time. To prevent that from happening, disable all non-wakeup GPEs except for the EC GPE for suspend-to-idle (the EC GPE is special, because on some systems it has to be enabled for power button wakeup events to be generated as expected). Fixes: 147a7d9d25ca (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle) Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987 Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
231f9415 |
|
09-Jul-2018 |
Willy Tarreau <w@1wt.eu> |
ACPI / PM: save NVS memory for ASUS 1025C laptop Every time I tried to upgrade my laptop from 3.10.x to 4.x I faced an issue by which the fan would run at full speed upon resume. Bisecting it showed me the issue was introduced in 3.17 by commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to accelerate S3). This code only affects machines built starting as of 2012, but this Asus 1025C laptop was made in 2012 and apparently needs the NVS data to be saved, otherwise the CPU's thermal state is not properly reported on resume and the fan runs at full speed upon resume. Here's a very simple way to check if such a machine is affected : # cat /sys/class/thermal/thermal_zone0/temp 55000 ( now suspend, wait one second and resume ) # cat /sys/class/thermal/thermal_zone0/temp 0 (and after ~15 seconds the fan starts to spin) Let's apply the same quirk as commit cbc00c13 (ACPI: save NVS memory for Lenovo G50-45) and reuse the function it provides. Note that this commit was already backported to 4.9.x but not 4.4.x. Cc: 3.17+ <stable@vger.kernel.org> # 3.17+: requires cbc00c13 Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6f9db69a |
|
15-Jun-2018 |
Tristian Celestin <tristiancelestin@fastmail.com> |
ACPI / PM: Default to s2idle in all machines supporting LP S0 The Dell Venue Pro 7140 supports the Low Power S0 Idle state, but does not support any of the _DSM functions that the current heuristic checks for. Since suspend-to-mem can not be safely performed on this machine, and since the bitfield check can't cover this case, it is safer to enable s2idle by default by checking for the presence of the _DSM alone and removing the bitfield check. Signed-off-by: Tristian Celestin <tristiancelestin@fastmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
68e22011 |
|
16-May-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Dispatch the EC GPE directly on s2idle wake On platforms where the Low Power S0 Idle _DSM interface is used, on wakeup from suspend-to-idle, when it is known that the ACPI SCI has triggered while suspended, dispatch the EC GPE in order to catch all EC events that may have triggered the wakeup before carrying out the noirq phase of device resume. That is needed to handle power button wakeup on some platforms where the EC goes into a low-power mode during suspend-to-idle and while in that mode it will discard events after a timeout. If that timeout is shorter than the time it takes to complete the noirq resume of devices, looking for EC events after the latter is too late. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Wendy Wang <wendy.wang@intel.com>
|
#
855c1c2f |
|
10-Apr-2018 |
Chen Yu <yu.c.chen@intel.com> |
ACPI / PM: Blacklist Low Power S0 Idle _DSM for ThinkPad X1 Tablet(2016) ThinkPad X1 Tablet(2016) is reported to have issues with the Low Power S0 Idle _DSM interface and since this machine model generally can do ACPI S3 just fine, and user would like to use S3 as default sleep model, add a blacklist entry to disable that interface for ThinkPad X1 Tablet(2016). Link: https://bugzilla.kernel.org/show_bug.cgi?id=199057 Reported-and-tested-by: Robin Lee <robinlee.sysu@gmail.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6f1d7c45 |
|
30-Mar-2018 |
Chris Chiu <chiu@endlessm.com> |
ACPI / PM: Fix keyboard wakeup from suspend-to-idle on ASUS UX331UA This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress event is routed to Embedded Controller (EC) in standby mode. EC then signals the SCI event to BIOS so BIOS would Notify() power button to wake up the system. It's from BIOS perspective. What we observe here is that kernel receives the SCI event from SCI interrupt handler which informs that the GPE status bit belongs to EC needs to be handled and then queries the EC to find out what event is pending. Then execute the following ACPI _QDF method which defined in ACPI DSDT for EC to notify power button. Method (_QDF, 0, NotSerialized) // _Qxx: EC Query { Notify (PWRB, 0x80) // Status Change } With more debug messages added to analyze this problem, we find that the keypress does wake up the system from suspend-to-idle but it's back to suspend again almost immediately. As we see in the following messages, the acpi_button_notify() is invoked but acpi_pm_wakeup_event() can not really wake up the system here because acpi_s2idle_wakeup() is false. The acpi_s2idle_wakeup() returnd false because the acpi_s2idle_sync() has alrealdy exited. [ 52.987048] s2idle_loop going s2idle [ 59.713392] acpi_s2idle_wake enter [ 59.713394] acpi_s2idle_wake exit [ 59.760888] acpi_ev_gpe_detect enter [ 59.760893] acpi_s2idle_sync enter [ 59.760893] acpi_ec_query_flushed ec pending queries 0 [ 59.760953] Read registers for GPE 50-57: Status=01, Enable=01, RunEnable=01, WakeEnable=00 [ 59.760955] ACPI: EC: ===== IRQ (1) ===== [ 59.760972] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 59.760979] ACPI: EC: +++++ Polling enabled +++++ [ 59.760979] ACPI: EC: ##### Command(QR_EC) submitted/blocked ##### [ 59.761003] acpi_s2idle_sync exit [ 59.769587] ACPI: EC: ##### Query(0xdf) started ##### [ 59.769611] ACPI: EC: ##### Query(0xdf) stopped ##### [ 59.774154] acpi_button_notify button type 1 [ 59.813175] s2idle_loop going s2idle acpi_s2idle_sync() already makes an effort to flush the EC event queue, but in this case, the EC event has yet to be generated when the call to acpi_ec_flush_work() is made. The event is generated shortly after, through the ongoing handling of the SCI interrupt which is happening on another CPU, and we must synchronize that to make sure that it has run and completed. Adding another call to acpi_os_wait_events_complete() solves this issue, since that function synchronizes with SCI interrupt completion. Signed-off-by: Chris Chiu <chiu@endlessm.com> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fa54150a |
|
13-Mar-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Reduce LPI constraints logging noise If a device referred to by ACPI LPI constrains (coming from function 1 of the Low Power S0 Idle _DSM interface) is not power-manageable via ACPI (no _PS0 method and no power resources), the code generating diagnostic information for the LPI constraints will print a message about that to the kernel log on every system suspend-resume cycle (possibly for multiple times). That is not very useful and noisy, so modify that code to disregard the LPI list entries corresponding to the devices that are not power- manageable after printing that information for them once. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
|
#
9c0a30b6 |
|
22-Feb-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
ACPI/sleep: Simplify code by using the new dmi_get_bios_year() helper ...instead of open coding its functionality. No changes in functionality. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jean Delvare <jdelvare@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-acpi@vger.kernel.org Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/20180222125923.57385-3-andriy.shevchenko@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
147a7d9d |
|
19-Feb-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Do not reconfigure GPEs for suspend-to-idle It is reported that commit 235d81a630ca (ACPI / PM: Clean up device wakeup enable/disable code) broke wakeup from suspend-to-idle on some platforms. That is due to the acpi_enable_all_wakeup_gpes() in acpi_s2idle_prepare() which needs acpi_enable_wakeup_devices() to be called before it as the latter sets up the GPE masks used by the former and commit 235d81a630ca removed acpi_enable_wakeup_devices() invocation from the suspend-to-idle path. However, acpi_enable_wakeup_devices() does more than just setting the GPE masks and the remaining part of it is not necessary for suspend-to-idle. Moreover, non-wakeup GPEs are disabled on suspend- to-idle entry to avoid spurious wakeups, but that should not be strictly necessary any more after commit 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle) which prevents spurious GPE wakeups from resuming the system. The only consequence of leaving non-wakeup GPEs enabled may be more interrupt-related activity while suspended, which is not ideal (more energy is used if that happens), but it is not critical too. For this reason, drop the GPE reconfiguration from the suspend-to-idle path entirely. This change also allows Dells XPS13 9360 blacklisted by commit 71630b7a832f (ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360) to use the power button for waking up from suspend- to-idle and it helps at least one other older Dell system (the wakeup button GPE on that one is not listed in _PRW for any devices, so it is not regarded as a wakeup one and gets disabled on suspend-to-idle entry today). Fixes: 235d81a630ca (ACPI / PM: Clean up device wakeup enable/disable code) Reported-by: Du Wenkai <wenkai.du@intel.com> Tested-by: Du Wenkai <wenkai.du@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
29a5a6d7 |
|
10-Jan-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Use Low Power S0 Idle on more systems Some systems don't support the ACPI_LPS0_ENTRY and ACPI_LPS0_EXIT functions in their Low Power S0 Idle _DSM, but still expect EC events to be processed in the suspend-to-idle state for power button wakeup (among other things) to work. Surface Pro3 turns out to be one of them. Fortunately, it still provides Low Power S0 Idle _DSM with the screen on/off functions supported, so modify the ACPI suspend-to-idle to use the Low Power S0 Idle code path for all systems supporting the ACPI_LPS0_ENTRY and ACPI_LPS0_EXIT or the ACPI_LPS0_SCREEN_OFF and ACPI_LPS0_SCREEN_ON functions in their Low Power S0 Idle _DSM. Potentially, that will cause more systems to use suspend-to-idle by default, so some future corrections may be necessary if it leads to issues, but let it remain more straightforward for now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198389#add_comment Reported-by: Valentin Manea <valy@mrs.ro> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Valentin Manea <valy@mrs.ro>
|
#
57044031 |
|
14-Nov-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Make it possible to ignore the system sleep blacklist The ACPI code supporting system transitions to sleep states uses an internal blacklist to apply special handling to some machines reported to behave incorrectly in some ways. However, some entries of that blacklist cover problematic as well as non-problematic systems, so give the users of the latter a chance to ignore the blacklist and run their systems in the default way by adding acpi_sleep=nobl to the kernel command line. For example, that allows the users of Dell XPS13 9360 systems not affected by the issue that caused the blacklist entry for this machine to be added by commit 71630b7a832f (ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360) to use suspend-to-idle with the Low Power S0 Idle _DSM interface which in principle should be more energy-efficient than S3 on them. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
71630b7a |
|
06-Nov-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360 At least one Dell XPS13 9360 is reported to have serious issues with the Low Power S0 Idle _DSM interface and since this machine model generally can do ACPI S3 just fine, add a blacklist entry to disable that interface for Dell XPS13 9360. Fixes: 8110dd281e15 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196907 Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
|
#
6faadbbb |
|
14-Sep-2017 |
Christoph Hellwig <hch@lst.de> |
dmi: Mark all struct dmi_system_id instances const ... and __initconst if applicable. Based on similar work for an older kernel in the Grsecurity patch. [JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
|
#
726fb6b4 |
|
15-Aug-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
ACPI / PM: Check low power idle constraints for debug only For SoC to achieve its lowest power platform idle state a set of hardware preconditions must be met. These preconditions or constraints can be obtained by issuing a device specific method (_DSM) with function "1". Refer to the document provided in the link below. Here during initialization (from attach() callback of LPS0 device), invoke function 1 to get the device constraints. Each enabled constraint is stored in a table. The devices in this table are used to check whether they were in required minimum state, while entering suspend. This check is done from platform freeze wake() callback, only when /sys/power/pm_debug_messages attribute is non zero. If any constraint is not met and device is ACPI power managed then it prints the device information to kernel logs. Also if debug is enabled in acpi/sleep.c, the constraint table and state of each device on wake is dumped in kernel logs. Since pm_debug_messages_on setting is used as condition to check constraints outside kernel/power/main.c, pm_debug_messages_on is changed to a global variable. Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
23d5855f |
|
09-Aug-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / s2idle: Rename platform operations structure Rename struct platform_freeze_ops to platform_s2idle_ops to make it clear that the callbacks in it are used during suspend-to-idle suspend/resume transitions and rename the related functions, variables and so on accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
690cbb90 |
|
09-Aug-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / s2idle: Rename PM_SUSPEND_FREEZE to PM_SUSPEND_TO_IDLE To make it clear that the symbol in question refers to suspend-to-idle, rename it from PM_SUSPEND_FREEZE to PM_SUSPEND_TO_IDLE. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e870c6c8 |
|
31-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Prefer suspend-to-idle over S3 on some systems 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 <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
|
#
a042e0c6 |
|
31-Jul-2017 |
Jean Delvare <jdelvare@suse.de> |
ACPI / sleep: Make acpi_sleep_syscore_init() static Function acpi_sleep_syscore_init has no external user so it should be static. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
880a6627 |
|
19-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM / EC: Flush all EC work in acpi_freeze_sync() Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) introduced acpi_freeze_sync() whose purpose is to flush all of the processing of possible wakeup events signaled via the ACPI SCI. However, it doesn't flush the query workqueue used by the EC driver, so the events generated by the EC may not be processed timely which leads to issues (increased overhead at least, lost events possibly). To fix that introduce acpi_ec_flush_work() that will flush all of the outstanding EC work and call it from acpi_freeze_sync(). Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8110dd28 |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is not expected to be used at all (the OS these systems ship with never exercises the ACPI S3 path in the firmware) and suspend-to-idle is the only viable system suspend mechanism there. The reason why the power button wakeup from suspend-to-idle doesn't work on those systems is because their power button events are signaled by the EC (Embedded Controller), whose GPE (General Purpose Event) line is disabled during suspend-to-idle transitions in Linux. That is done on purpose, because in general the EC tends to be noisy for various reasons (battery and thermal updates and similar, for example) and all events signaled by it would kick the CPUs out of deep idle states while in suspend-to-idle, which effectively might defeat its purpose. Of course, on the Dell systems in question the EC GPE must be enabled during suspend-to-idle transitions for the button press events to be signaled while suspended at all, but fortunately there is a way out of this puzzle. First of all, those systems have the ACPI_FADT_LOW_POWER_S0 flag set in their ACPI tables, which means that the OS is expected to prefer the "low power S0 idle" system state over ACPI S3 on them. That causes the most recent versions of other OSes to simply ignore ACPI S3 on those systems, so it is reasonable to expect that it should not be necessary to block GPEs during suspend-to-idle on them. Second, in addition to that, the systems in question provide a special firmware interface that can be used to indicate to the platform that the OS is transitioning into a system-wide low-power state in which certain types of activity are not desirable or that it is leaving such a state and that (in principle) should allow the platform to adjust its operation mode accordingly. That interface is a special _DSM object under a System Power Management Controller device (PNP0D80). The expected way to use it is to invoke function 0 from it on system initialization, functions 3 and 5 during suspend transitions and functions 4 and 6 during resume transitions (to reverse the actions carried out by the former). In particular, function 5 from the "Low-Power S0" device _DSM is expected to cause the platform to put itself into a low-power operation mode which should include making the EC less verbose (so to speak). Next, on resume, function 6 switches the platform back to the "working-state" operation mode. In accordance with the above, modify the ACPI suspend-to-idle code to look for the "Low-Power S0" _DSM interface on platforms with the ACPI_FADT_LOW_POWER_S0 flag set in the ACPI tables. If it's there, use it during suspend-to-idle transitions as prescribed and avoid changing the GPE configuration in that case. [That should reflect what the most recent versions of other OSes do.] Also modify the ACPI EC driver to make it handle events during suspend-to-idle in the usual way if the "Low-Power S0" _DSM interface is going to be used to make the power button events work while suspended on the Dell machines mentioned above Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
33e4f80e |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle 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@intel.com>
|
#
235d81a6 |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Clean up device wakeup enable/disable code The wakeup.flags.enabled flag in struct acpi_device is not used consistently, as there is no reason why it should only apply to the enabling/disabling of the wakeup GPE, so put the invocation of acpi_enable_wakeup_device_power() under it too. Moreover, it is not necessary to call acpi_enable_wakeup_devices() and acpi_disable_wakeup_devices() for suspend-to-idle, so don't do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f3b7eaae |
|
06-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle" 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 <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eed4d47e |
|
26-Apr-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle 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@intel.com>
|
#
8ece1d83 |
|
30-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
ACPI / power: Delay turning off unused power resources after suspend Commit 660b1113e0f3 (ACPI / PM: Fix consistency check for power resources during resume) introduced a check for ACPI power resources which have been turned on by the BIOS during suspend and turns these back off again. This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes the following messages to show up in dmesg: [ 131.014605] ACPI: Waking up from system sleep state S3 [ 131.150271] acpi LNXPOWER:07: Turning OFF [ 131.150323] acpi LNXPOWER:06: Turning OFF [ 131.150911] acpi LNXPOWER:00: Turning OFF [ 131.169014] ACPI : EC: interrupt unblocked [ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI [ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed [ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state, currently in D3 [ 133.597672] PM: noirq resume of devices complete after 2428.891 msecs Followed by a bunch of iwlwifi errors later on and the pcie device dropping from the bus (acpiphp thinks it has been unplugged). Disabling the turning off of unused power resources fixes this. Instead of adding a quirk for this system, this commit fixes this by moving the disabling of unused power resources to later in the resume sequence when the iwlwifi card has been moved out of D3 so the ref_count for its power resource no longer is 0. This new behavior seems to match the intend of the original commit which commit-msg says: "(... which means that no devices are going to need them any time soon) and we should turn them off". This also avoids power resources which we need when bringing devices out of D3 from getting bounced off and then back on again. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cbc00c13 |
|
15-Jan-2017 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: save NVS memory for Lenovo G50-45 In commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to accelerate S3), to optimize S3 suspend/resume speed, code is introduced to ignore NVS memory saving during S3 for all the platforms later than 2012. But, Lenovo G50-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431 Tested-by: Przemek <soprwa@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> [ rjw: Drop unnecessary code ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e326ce01 |
|
19-Jan-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag" Revert commit 08b98d329165 (PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag) as it caused system suspend (in the default configuration) to fail on Dell XPS13 (9360) with the Kaby Lake processor. Fixes: 08b98d329165 (PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag) Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
08b98d32 |
|
16-Nov-2016 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag 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 <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
|
#
9713adc2 |
|
21-Nov-2016 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI: Execute _PTS before system reboot" Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot) as it is reported to cause poweroff and reboot to hang on Dell Latitude E7250. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187061 Reported-by: Gianpaolo <gianpaoloc@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c2b46d67 |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add PM operations to improve event handling for resume process This patch makes 2 changes: 1. Restore old behavior Originally, EC driver stops handling both events and transactions in acpi_ec_block_transactions(), and restarts to handle transactions in acpi_ec_unblock_transactions_early(), restarts to handle both events and transactions in acpi_ec_unblock_transactions(). While currently, EC driver still stops handling both events and transactions in acpi_ec_block_transactions(), but restarts to handle both events and transactions in acpi_ec_unblock_transactions_early(). This patch tries to restore the old behavior by dropping __acpi_ec_enable_event() from acpi_unblock_transactions_early(). 2. Improve old behavior However this still cannot fix the real issue as both of the acpi_ec_unblock_xxx() functions are invoked in the noirq stage. Since the EC driver actually doesn't implement the event handling in the polling mode, re-enabling the event handling too early in the noirq stage could result in the problem that if there is no triggering source causing advance_transaction() to be invoked, pending SCI_EVT cannot be detected by the EC driver and _Qxx cannot be triggered. It actually makes sense to restart the event handling in any point during resuming after the noirq stage. Just like the boot stage where the event handling is enabled in .add(), this patch further moves acpi_ec_enable_event() to .resume(). After doing that, the following 2 functions can be combined: acpi_ec_unblock_transactions_early()/acpi_ec_unblock_transactions(). The differences of the event handling availability between the old behavior (this patch isn't applied) and the new behavior (this patch is applied) are as follows: !Applied Applied before suspend Y Y suspend before EC Y Y suspend after EC Y Y suspend_late Y Y suspend_noirq Y (actually N) Y (actually N) resume_noirq Y (actually N) Y (actually N) resume_late Y (actually N) Y (actually N) resume before EC Y (actually N) Y (actually N) resume after EC Y (actually N) Y after resume Y (actually N) Y Where "actually N" means if there is no triggering source, the EC driver is actually not able to notice the pending SCI_EVT occurred in the noirq stage. So we can clearly see that this patch has improved the situation. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
18864cc4 |
|
04-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / sysfs: Use new GPE masking mechanism in GPE interface Now GPE can be masked via the new acpi_mask_gpe() API and this patch modifies /sys/firmware/acpi/interrupts/gpexx to use this new facility. Writes "mask/unmask" to this file now invokes acpi_mask_gpe(). Reads from this file now returns new "EN/STS" when the corresponding GPE hardware register's EN/STS bits are flagged, and new "masked/unmasked" attribute to indicate the status of the masking mechanism. Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2c85025c |
|
27-Jun-2016 |
Ocean He <hehy1@lenovo.com> |
ACPI: Execute _PTS before system reboot The _PTS control method is defined in the section 7.4.1 of acpi 6.0 spec. The _PTS control method is executed by the OS during the sleep transition process for S1, S2, S3, S4, and for orderly S5 shutdown. The _PTS control method provides the BIOS a mechanism for performing some housekeeping, such as writing the sleep type value to the embedded controller, before entering the system sleeping state. Note that some Lenovo Server BIOS use this mechanism to detect reboot event and prompt user by popped dialog box. According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS. Add a _PTS evaulation to the existing _TTS reboot notifier and change the notifier name to reflect the fact that it's not for _TTS only any more. Signed-off-by: Ocean He <hehy1@lenovo.com> Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
13737181 |
|
21-Mar-2016 |
Chen Yu <yu.c.chen@intel.com> |
ACPI / PM: Introduce efi poweroff for HW-full platforms without _S5 The problem is Linux registers pm_power_off = efi_power_off only if we are in hardware reduced mode. Actually, what we also want is to do this when ACPI S5 is simply not supported on non-legacy platforms. Since some future Intel platforms are HW-full mode where the DSDT fails to supply an _S5 object(without SLP_TYP), we should let such kind of platform to leverage efi runtime service to poweroff. This patch uses efi power off as first choice when S5 is unavailable, even if there is a customized poweroff(driver provided, eg). Meanwhile, the legacy platforms will not be affected because there is no path for them to overwrite the pm_power_off to efi power off. Suggested-by: Len Brown <len.brown@intel.com> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fbda4b38 |
|
22-Mar-2016 |
Lukas Wunner <lukas@wunner.de> |
ACPI / PM: Runtime resume devices when waking from hibernate Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered suspend-to-RAM. Briefly, the motivation was to ensure that devices did not remain in a reset-power-on state after resume, potentially preventing deep SoC-wide low-power states from being entered on idle. Currently we're not doing the same when leaving suspend-to-disk and this asymmetry is a problem if drivers rely on the automatic resume triggered by pm_complete_with_resume_check(). Fix it. Fixes: 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware) Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
504997cf |
|
16-Feb-2016 |
Sudeep Holla <Sudeep.Holla@arm.com> |
ACPI / sleep: move acpi_processor_sleep to sleep.c acpi_processor_sleep is neither related nor used by CPUIdle framework. It's used in system suspend/resume path as a syscore operation. It makes more sense to move it to acpi/sleep.c where all the S-state transition (a.k.a. Linux system suspend/hiberate) related code are present. Also make it depend on CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT so that it's not compiled on architecture like ARM64 where S-states are not yet defined in ACPI. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e3e9b577 |
|
04-Jan-2016 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPICA: Drop Linux-specific waking vector functions Commit f06147f9fbf1 (ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS) added three functions that aren't present in upstream ACPICA, acpi_hw_set_firmware_waking_vectors(), acpi_set_firmware_waking_vectors() and acpi_set_firmware_waking_vector64(), to allow Linux to use the previously existing API for setting the platform firmware waking vector. However, that wasn't necessary, since the ACPI sleep support code in Linux can be modified to use the upstream ACPICA's API easily and the additional functions may be dropped which reduces the code size and puts the kernel's ACPICA code more in line with the upstream. Make the changes as per the above. While at it, make the relevant function desctiption comments reflect the upstream ACPICA's ones. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lv Zheng <lv.zheng@intel.com>
|
#
8c01275e |
|
24-Oct-2015 |
Chen Yu <yu.c.chen@intel.com> |
ACPI / PM: Fix incorrect wakeup IRQ setting during suspend-to-idle For an ACPI compatible system, the SCI (ACPI System Control Interrupt) is used to wake the system up from suspend-to-idle. Once the CPU is woken up by the SCI, the interrupt handler will first check if the current IRQ has been configured for system wakeup, so irq_pm_check_wakeup() is invoked to validate the IRQ number. However, during suspend-to-idle, enable_irq_wake() is called for acpi_gbl_FADT.sci_interrupt, although the IRQ number that the SCI handler has been installed for should be passed to it instead. Thus, if acpi_gbl_FADT.sci_interrupt happens to be different from that number, ACPI interrupts will not be able to wake up the system from sleep. Fix this problem by passing the IRQ number returned by acpi_gsi_to_irq() to enable_irq_wake() instead of acpi_gbl_FADT.sci_interrupt. Cc: 3.18+ <stable@vger.kernel.org> # 3.18+ Acked-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ef25ba04 |
|
06-Oct-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / sleep: Add flags to indicate platform firmware involvement 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@intel.com>
|
#
7b02ccea |
|
27-Mar-2015 |
Chen Yu <yu.c.chen@intel.com> |
ACPI / PM: Enable all wakeup GPEs in suspend-to-idle Currently, in suspend-to-idle, wakeup GPE for PCI devices are handled properly because acpi_pci_sleep_wake() invokes acpi_enable_gpe() to enable the wakeup GPE directly. But for the other wakeup-capable devices in ACPI bus, acpi_enable_wakeup_devices() should be invoked to update enable_for_wake mask in gpe_register_info structure, thus acpi_enable_all_wakeup_gpes() can enable the wakeup GPE referred in _PRW methods. And acpi_disable_wakeup_devices() will be called before disable_irq_wake() in acpi_freeze_restore() to restore the mask. This patch fixes a power button wakeup problem on Surface Pro 3, on which platform power button uses EC to deliver event (EC GPE is referred in _PRW). Note: enabling EC GPE during freeze state may bring some risks because EC events are expected to fire more frequently than others. Thus it may bring the system out of freeze state unnecessarily. (We already have comments about this in bugzilla) Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651 Reported-and-tested-by: Ethan Schoonover <es@ethanschoonover.com> Tested-by: Peter Amidon <psa.pub.0@picnicpark.org> Tested-by: Yani Ioadnnou <yani.ioannou@gmail.com> Tested-by: Mister Wardrop <mister.wardrop@gmail.com> Tested-by: Anton Anikin <anton@anikin.name> Tested-by: Keith McClelland <zismylaptop@gmail.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b8ee2978 |
|
17-Mar-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Drop acpi_suspend() which is not used The acpi_suspend() function has no callers, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
|
#
8b691c9c |
|
23-Jan-2015 |
Jan Beulich <JBeulich@suse.com> |
ACPI / sleep: mark acpi_sleep_dmi_check() __init This makes a difference if the compiler decides not to inline the function, as then the function's reference to acpisleep_dmi_table[] yields a section mismatch warning. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c52fa70c |
|
01-Dec-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Drain outstanding events after disabling multiple GPEs After multiple GPEs have been disabled at the low level in one go, like when acpi_disable_all_gpes() is called, we should always drain all of the outstanding events from them, or interesting races become possible. For this reason, call acpi_os_wait_events_complete() after acpi_enable_all_wakeup_gpes() and acpi_disable_all_gpes() in acpi_freeze_prepare() and acpi_power_off_prepare(), respectively. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a8d46b9e |
|
29-Sep-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle The ACPI GPE wakeup from suspend-to-idle is currently based on using the IRQF_NO_SUSPEND flag for the ACPI SCI, but that is problematic for a couple of reasons. First, in principle the ACPI SCI may be shared and IRQF_NO_SUSPEND does not really work well with shared interrupts. Second, it may require the ACPI subsystem to special-case the handling of device notifications depending on whether or not they are received during suspend-to-idle in some places which would lead to fragile code. Finally, it's better the handle ACPI wakeup interrupts consistently with wakeup interrupts from other sources. For this reason, remove the IRQF_NO_SUSPEND flag from the ACPI SCI and use enable_irq_wake()/disable_irq_wake() with it instead, which requires two additional platform hooks to be added to struct platform_freeze_ops. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
821d6f03 |
|
23-Jul-2014 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / sleep: Do not save NVS for new machines to accelerate S3 NVS region is saved and restored unconditionally for machines without nvs_nosave quirk during S3. Tested some new machines and the operation is not necessary. Saving NVS region also affects S2RAM speed. The time of NVS saving and restoring depends on the size of NVS region and it consumes 7~10ms normally. This patch is to make machines produced from 2012 to now not saving NVS region to accelerate S3. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bb3632c6 |
|
06-Jun-2014 |
Todd E Brandt <todd.e.brandt@linux.intel.com> |
PM / sleep: trace events for suspend/resume Adds trace events that give finer resolution into suspend/resume. These events are graphed in the timelines generated by the analyze_suspend.py script. They represent large areas of time consumed that are typical to suspend and resume. The event is triggered by calling the function "trace_suspend_resume" with three arguments: a string (the name of the event to be displayed in the timeline), an integer (case specific number, such as the power state or cpu number), and a boolean (where true is used to denote the start of the timeline event, and false to denote the end). The suspend_resume trace event reproduces the data that the machine_suspend trace event did, so the latter has been removed. Signed-off-by: Todd Brandt <todd.e.brandt@intel.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1f0b6386 |
|
15-May-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state The "freeze" sleep state suffers from the same issue that was addressed by commit ad07277e82de (ACPI / PM: Hold acpi_scan_lock over system PM transitions) for ACPI sleep states, that is, things break if ->remove() is called for devices whose system resume callbacks haven't been executed yet. It also can be addressed in the same way, by holding the ACPI scan lock over the "freeze" sleep state and PM transitions to and from that state, but ->begin() and ->end() platform operations for the "freeze" sleep state are needed for this purpose. This change has been tested on Acer Aspire S5 with Thunderbolt. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fad16dd9 |
|
08-May-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Export acpi_target_system_state() to modules Export the acpi_target_system_state() function to modules so that modular drivers can use it to check what the target ACPI sleep state of the system is (that is needed for i915 mostly at this point). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a4e90bed |
|
13-Mar-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses the optional sleep control and sleep status registers for making the system enter sleep states (including S5), so it is not possible to use system sleep states or power it off using ACPI if the HW Reduced ACPI mode bit is set and those registers are not available. For this reason, add a new function, acpi_sleep_state_supported(), checking if the HW Reduced ACPI mode bit is set and whether or not system sleep states are usable in that case in addition to checking the return value of acpi_get_sleep_type_data() and make the ACPI sleep setup routines use that function to check the availability of system sleep states. Among other things, this prevents the kernel from attempting to use ACPI for powering off HW Reduced ACPI systems without the sleep control and sleep status registers, because ACPI power off doesn't have a chance to work on them. That allows alternative power off mechanisms that may actually work to be used on those systems. The affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell Desktop SDP and Ivy Bridge EP Demo depot. References: https://bugzilla.kernel.org/show_bug.cgi?id=70931 Reported-by: Adam Williamson <awilliam@redhat.com> Tested-by: Aubrey Li <aubrey.li@linux.intel.com> Cc: 3.4+ <stable@vger.kernel.org> # 3.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4c7b7040 |
|
09-Mar-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI / sleep: pm_power_off needs more sanity checks to be installed" Revert commit 3130497f5bab ("ACPI / sleep: pm_power_off needs more sanity checks to be installed") that breaks power ACPI power off on a lot of systems, because it checks wrong registers. Fixes: 3130497f5bab ("ACPI / sleep: pm_power_off needs more sanity checks to be installed") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3130497f |
|
01-Mar-2014 |
Li, Aubrey <aubrey.li@linux.intel.com> |
ACPI / sleep: pm_power_off needs more sanity checks to be installed Sleep control and status registers need santity checks as well before ACPI installs acpi_power_off to pm_power_off hook. The checking code in acpi_enter_sleep_state() is too late, we should not allow a not-working pm_power_off function to be hooked up. Signed-off-by: Aubrey Li <aubrey.li@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5c551e62 |
|
10-Jan-2014 |
Oliver Neukum <oneukum@suse.de> |
ACPI / sleep: remove panic in case hardware has changed after S4 Some BIOSes change hardware based on the state of a laptop's lid. If the lid is closed, the touchpad is disabled and the checksum changes. Windows 8 no longer aborts resume if the checksum has changed. Signed-off-by: Oliver Neukum <oneukum@suse.de> [rjw: Use pr_crit() for the message and don't break the string] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
100eb0b0 |
|
05-Dec-2013 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI / sleep: Drop redundant acpi_disabled check acpi_sleep_init() is only called from acpi_bus_init() and the code logic shows that it doesn't need to check acpi_disabled: acpi_init(); if (acpi_disabled) return; acpi_bus_init(); acpi_sleep_init(); if (acpi_disabled) return 0; Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8b48463f |
|
02-Dec-2013 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
51468a9d |
|
20-Nov-2013 |
Al Stone <al.stone@linaro.org> |
ACPI / sleep: clean up compiler warning about uninitialized field Initialize pwr_btn_status as disabled which (a) makes sure it is in a proper state to start, and (b) cleans up a compiler warning about an uninitialized variable. Signed-off-by: Al Stone <al.stone@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ad07277e |
|
19-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Hold acpi_scan_lock over system PM transitions Bad things happen if ACPI hotplug events are handled during system PM transitions, especially if devices are removed as a result. To prevent those bad things from happening, acquire acpi_scan_lock when a PM transition is started and release it when that transition is complete or has been aborted. This fixes resume lockup on my test-bed Acer Aspire S5 that happens when Thunderbolt devices are disconnected from the machine while suspended. Also fixes the analogous problem for Mika Westerberg on an Intel DZ77RE-75K board. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
3e4376ff |
|
07-Aug-2013 |
Sachin Kamat <sachin.kamat@linaro.org> |
ACPI / Sleep: Fix incorrect placement of __initdata __initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0db98202 |
|
28-Jun-2013 |
Jiang Liu <jiang.liu@huawei.com> |
ACPI: introduce helper function acpi_execute_simple_method() Introduce helper function acpi_execute_simple_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d6a77ead |
|
14-May-2013 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
x86 / ACPI / sleep: Provide registration for acpi_suspend_lowlevel. Which by default will be x86_acpi_suspend_lowlevel. This registration allows us to register another callback if there is a need to use another platform specific callback. Signed-off-by: Liang Tang <liang.tang@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-by: Ben Guthro <benjamin.guthro@citrix.com> Acked-by: "H. Peter Anvin" <hpa@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
469dd1c4 |
|
11-Mar-2013 |
Fabio Valentini <fafatheone@gmail.com> |
ACPI / PM: fix suspend and resume on Sony Vaio VGN-FW21M Add Sony Vaio VGN-FW21M to the device blacklist in drivers/acpi/sleep.c. Fixes suspend/resume on this device (device no longer reboots instead of resuming). References: https://bugzilla.kernel.org/show_bug.cgi?id=55001 Signed-off-by: Fabio Valentini <fafatheone@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ed4cf5b2 |
|
22-Feb-2013 |
Joe Perches <joe@perches.com> |
ACPI / Sleep: Avoid interleaved message on errors Got this dmesg log on an Acer Aspire 725. [ 0.256351] ACPI: (supports S0ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568) [ 0.256373] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568) [ 0.256391] S3 S4 S5) Avoid this interleaving error messages. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
66f2fda9 |
|
04-Feb-2013 |
Joseph Salisbury <joseph.salisbury@canonical.com> |
ACPI: Add DMI entry for Sony VGN-FW41E_H This patch adds a quirk to allow the Sony VGN-FW41E_H to suspend/resume properly. References: http://bugs.launchpad.net/bugs/1113547 Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
02040f0b |
|
17-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Consolidate suspend-specific and hibernate-specific code Move some suspend-specific and hibernate-specific code from acpi_sleep_init() into separate functions to get rid of explicit #ifdefs in acpi_sleep_init(). Use pr_info() to start and pr_cont() to continue printing the supported ACPI sleep states line. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
781d737c |
|
17-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Drop power resources driver The ACPI power resources driver is not very useful, because the only thing it really does is to restore the state of the power resources that were "on" before system suspend or hibernation, but that may be achieved in a different way. Drop the ACPI power resources driver entirely and add acpi_resume_power_resources() that will walk the list of all registered power resources during system resume and turn on the ones that were "on" before the preceding system suspend or hibernation. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0ac1b1d7 |
|
29-Nov-2012 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: do acpisleep dmi check when CONFIG_ACPI_SLEEP is set The current acpisleep DMI checks only run when CONFIG_SUSPEND is set. And this may break hibernation on some platforms when CONFIG_SUSPEND is cleared. Move acpisleep DMI check into #ifdef CONFIG_ACPI_SLEEP instead. [rjw: Added acpi_sleep_dmi_check() and rebased on top of earlier patches adding entries to acpisleep_dmi_table[].] References: https://bugzilla.kernel.org/show_bug.cgi?id=45921 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
876ab790 |
|
21-Nov-2012 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. Sony Vaio VPCEB1S1E does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=48781 Reported-by: Sébastien Wilmet <swilmet@gnome.org> Cc: <stable@vger.kernel.org> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1bad2f19 |
|
26-Oct-2012 |
Kristen Carlson Accardi <kristen@linux.intel.com> |
ACPI / Sleep: add acpi_sleep=nonvs_s3 parameter The ACPI specificiation would like us to save NVS at hibernation time, but makes no mention of saving NVS over S3. Not all versions of Windows do this either, and it is clear that not all machines need NVS saved/restored over S3. Allow the user to improve their suspend/resume time by disabling the NVS save/restore at S3 time, but continue to do the NVS save/restore for S4 as specified. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a6ae7594 |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Move device PM functions related to sleep states Introduce helper function returning the target sleep state of the system and use it to move the remaining device power management functions from sleep.c to device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
dee8370c |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Split device wakeup management routines Two device wakeup management routines in device_pm.c and sleep.c, acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a device pointer argument and use it to obtain the ACPI handle of the corresponding ACPI namespace node. That handle is then used to get the address of the struct acpi_device object corresponding to the struct device passed as the argument. Unfortunately, that last operation may be costly, because it involves taking the global ACPI namespace mutex, so it shouldn't be carried out too often. However, the callers of those routines usually call them in a row with acpi_pm_device_sleep_state() which also takes that mutex for the same reason, so it would be more efficient if they ran acpi_bus_get_device() themselves to obtain a pointer to the struct acpi_device object in question and then passed that pointer to the appropriate PM routines. To make that possible, split each of the PM routines mentioned above in two parts, one taking a struct acpi_device pointer argument and the other implementing the current interface for compatibility. Additionally, change acpi_pm_device_run_wake() to actually return an error code if there is an error while setting up runtime remote wakeup for the device. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cd7bd02d |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Move runtime remote wakeup setup routine to device_pm.c The ACPI function for setting up devices to do runtime remote wakeup is now located in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more logical place for it, so move it there. No functional changes should result from this modification. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
86b3832c |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Move device power state selection routine to device_pm.c The ACPI function for choosing device power state is now located in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more logical place for it, so move it there. However, instead of moving the function entirely, move its core only under a different name and with a different list of arguments, so that it is more flexible, and leave a wrapper around it in the original location. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bdda27fb |
|
26-Oct-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix device PM kernedoc comments and #ifdefs The kerneldoc comments for acpi_pm_device_sleep_state(), acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are outdated or otherwise inaccurate and/or don't follow the common kerneldoc patterns, so fix them. Additionally, notice that acpi_pm_device_run_wake() should be under CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8b713a88 |
|
23-Oct-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / ACPI: Take device PM QoS flags into account Make ACPI power management routines and PCI power management routines depending on ACPI take device PM QoS flags into account when deciding what power state to put the device into. In particular, after this change acpi_pm_device_sleep_state() will not return ACPI_STATE_D3_COLD as the deepest available low-power state if PM_QOS_FLAG_NO_POWER_OFF is requested for the device and it will not require remote wakeup to work for the device in the returned low-power state if there is at least one PM QoS flags request for the device, but PM_QOS_FLAG_REMOTE_WAKEUP is not requested for it. Accordingly, acpi_pci_set_power_state() will refuse to put the device into D3cold if PM_QOS_FLAG_NO_POWER_OFF is requested for it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Huang Ying <ying.huang@intel.com>
|
#
3f6f49c7 |
|
26-Jul-2012 |
Len Brown <len.brown@intel.com> |
ACPI: delete _GTS/_BFS support _GTS and _BFS were added to the suspend/resume flow in the ACPI 2.0 specification. Linux dutifully implemented _GTS and _BFS. We discovered that it was rarely seen in systems in the field. Further, some of those systems had AML so bogus that it could never work -- proof that no other operating system supports _GTS and _BFS. So we made _GTS and _BFS optional via modparam, and disabled them by default. But we've had to complicate some code to keep this support in the kernel, as these methods are defined to be evaluated very close to sleep entry and exit. Indeed, no other AML is ever evaluated with interrupts off. We have submitted a proposal for _GTS and _BFS to be officially removed from the ACPI specification on the next revision. Here we remove it from Linux. Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
#
a5ca7345 |
|
23-Jul-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Fix build warning in sleep.c for CONFIG_ACPI_SLEEP unset If CONFIG_ACPI_SLEEP is unset, the compiler complains that pwr_btn_event_pending is defined but not used. To silence the warning, move the definition of pwr_btn_event_pending under an appropriate #ifdef. Reported-by: Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3bd46600a7 |
|
25-Jun-2012 |
Lin Ming <ming.m.lin@intel.com> |
libata-acpi: add ata port runtime D3Cold support ATA port may support runtime D3Cold state, for example, Zero-power ODD case. This patch adds wakeup notifier and enable/disable run_wake during supend/resume. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
|
#
ee85f543 |
|
22-Jun-2012 |
Huang Ying <ying.huang@intel.com> |
ACPI/PM: specify lowest allowed state for device sleep state Lower device sleep state can save more power, but has more exit latency too. Sometimes, to satisfy some power QoS and other requirement, we need to constrain the lowest device sleep state. In this patch, a parameter to specify lowest allowed state for acpi_pm_device_sleep_state is added. So that the caller can enforce the constraint via the parameter. This is needed by PCIe D3cold support, where the lowest power state allowed may be D3_HOT instead of default D3_COLD. CC: Len Brown <lenb@kernel.org> CC: linux-acpi@vger.kernel.org Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
bd6f10a5 |
|
22-May-2012 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Remove argument of acpi_os_wait_events_complete Remove the unused argument of acpi_os_wait_events_complete. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
319b6ffc |
|
29-May-2012 |
H. Peter Anvin <hpa@kernel.org> |
x86, realmode: Unbreak the ia64 build of drivers/acpi/sleep.c Revert usage of acpi_wakeup_address and move definition to x86 architecture code in order to make compilation work in ia64. [jsakkine: tested compilation in ia64/x86-64 and added proper commit message] Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Originally-by: H. Peter Anvin <hpa@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Link: http://lkml.kernel.org/r/1338370421-27735-1-git-send-email-jarkko.sakkinen@intel.com Cc: Tony Luck <tony.luck@intel.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
#
dbe9a2ed |
|
29-May-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification The comparison between the system sleep state being entered and the lowest system sleep state the given device may wake up from in acpi_pm_device_sleep_state() is reversed, because the specification (ACPI 5.0) says that for wakeup to work: "The sleeping state being entered must be less than or equal to the power state declared in element 1 of the _PRW object." In other words, the state returned by _PRW is the deepest (lowest-power) system sleep state the device is capable of waking up the system from. Moreover, acpi_pm_device_sleep_state() also should check if the wakeup capability is supported through ACPI, because in principle it may be done via native PCIe PME, for example, in which case _SxW should not be evaluated. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
c10d7a13 |
|
09-May-2012 |
Daniel Drake <dsd@laptop.org> |
ACPI / PM: Generate wakeup events on fixed power button When the system is woken up by the ACPI fixed power button, currently there is no way of userspace becoming aware that the power button was pressed. OLPC would like to know this, so that we can respond appropriately. For example, if the system was woken up by a network packet, we know we can go back to sleep very quickly. But if the user explicitly woke the system with the power button, we're going to want to stay awake for a while. The wakeup count mechanism seems like a good fit for communicating this. Mark the fixed power button as wakeup-enabled, and increment its wakeup counter when the system is woken with the power button. (The wakeup counter is also incremented when the power button is pressed during system operation; this is already handled by an existing acpi-button codepath). Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
b429dbf6 |
|
08-May-2012 |
Jarkko Sakkinen <jarkko.sakkinen@intel.com> |
x86, realmode: don't copy real_mode_header Replaced copying of real_mode_header with a pointer to beginning of RM memory. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Link: http://lkml.kernel.org/r/1336501366-28617-19-git-send-email-jarkko.sakkinen@intel.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
#
c9b77ccb |
|
08-May-2012 |
Jarkko Sakkinen <jarkko.sakkinen@intel.com> |
x86, realmode: Move ACPI wakeup to unified realmode code Migrated ACPI wakeup code to the real-mode blob. Code existing in .x86_trampoline can be completely removed. Static descriptor table in wakeup_asm.S is courtesy of H. Peter Anvin. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Link: http://lkml.kernel.org/r/1336501366-28617-7-git-send-email-jarkko.sakkinen@intel.com Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <len.brown@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
#
be96447e |
|
08-May-2012 |
Kay Sievers <kay@vrfy.org> |
acpi: use KERN_CONT in printk() continuation lines Cc: Len Brown <lenb@kernel.org> Signed-off-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2a14e541 |
|
22-Apr-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
ACPI: Convert wake_sleep_flags to a value instead of function With commit a2ef5c4fd44ce3922435139393b89f2cce47f576 "ACPI: Move module parameter gts and bfs to sleep.c" the wake_sleep_flags is required when calling acpi_enter_sleep_state, which means that if there are functions outside the sleep.c code they can't get the wake_sleep_flags values. This converts the function in to a exported value and converts the module config operands to a function. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Lin Ming <ming.m.lin@intel.com> [v2: Parameters can be turned on/off dynamically] [v3: unsigned char -> u8] [v4: val -> kp->arg] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/1335150198-21899-2-git-send-email-konrad.wilk@oracle.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
#
b24e5098 |
|
27-Mar-2012 |
Lin Ming <ming.m.lin@intel.com> |
ACPI, PCI: Move acpi_dev_run_wake() to ACPI core acpi_dev_run_wake() is a generic function which can be used by other subsystem too. Rename it to acpi_pm_device_run_wake, to be consistent with acpi_pm_device_sleep_wake. Then move it to ACPI core. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a2ef5c4f |
|
20-Mar-2012 |
Lin Ming <ming.m.lin@intel.com> |
ACPI: Move module parameter gts and bfs to sleep.c Move linux specific module parameter gts and bfs out of ACPICA core code to sleep.c. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8a73b17e |
|
20-Mar-2012 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Sleep/Wake interfaces: optionally execute _GTS and _BFS Enhanced the sleep/wake interfaces to optionally execute the _GTS method (Going To Sleep), and the _BFS method (Back From Sleep). Windows apparently does not execute these methods, and therefore these methods are often untested. It has been seen on some systems where the execution of these methods causes errors and also prevents the machine from entering S5. It is therefore suggested that host operating systems do not execute these methods by default. In the future, perhaps these methods can be optionally executed based on the age of the system and/or what is the newest version of Windows that the BIOS asks for via _OSI. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4efeeecd |
|
20-Mar-2012 |
Bob Moore <robert.moore@intel.com> |
ACPICA: Clarify METHOD_NAME* defines for full-pathname cases Changed the METHOD_NAME* defines that define a full pathname to the method to METHOD_PATHNAME* in order to make it clear that it is not a simple 4-character ACPI name. Used for the various sleep/wake methods. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
93f77084 |
|
20-Jan-2012 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / PM: Add Sony Vaio VPCCW29FX to nonvs blacklist. Sony Vaio VPCCW29FX does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. https://bugzilla.kernel.org/show_bug.cgi?id=34722 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5a50a7c3 |
|
01-Dec-2011 |
Keng-Yu Lin <kengyu@canonical.com> |
ACPI / PM: Do not save/restore NVS on Asus K54C/K54HR The models do not resume correctly without acpi_sleep=nonvs. Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
ddf6ce45 |
|
02-Nov-2011 |
Dave Jones <davej@redhat.com> |
ACPI / PM: Add Sony VPCEB17FX to nonvs blacklist Another entry for the nonvs blacklist, as noted by a user in https://bugzilla.redhat.com/show_bug.cgi?id=641789#c12 Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
d11c78e9 |
|
19-Oct-2011 |
Dave Jones <davej@redhat.com> |
ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist. As noted by a user in https://bugzilla.redhat.com/show_bug.cgi?id=641789 The Sony VGN-FW21E also needs the nonvs by default workaround added. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
731b25a4 |
|
06-Oct-2011 |
Bogdan Radulescu <bogdan@nimblex.net> |
PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs Sony Vaio VGN-FW520F does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=16396#c86 Signed-off-by: Bogdan Radulescu <bogdan@nimblex.net> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
89e8ea12 |
|
06-Oct-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs Apparently, Sony Vaio VGN-SR26GN_P does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=16396#c91 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
bb0c5ed6 |
|
29-Jul-2011 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: DMI workaround for Asus A8N-SLI Premium and Asus A8N-SLI DELUX DMI workaround for A8N-SLI Premium and A8N-SLI DELUXE to enable the s3 suspend old ordering. http://bugzilla.kernel.org/show_bug.cgi?id=9528 Tested-by: Heiko Ettelbrück <hbruckynews@gmx.de> Tested-by: Brian Beardall <brian@rapsure.net> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
aa338601 |
|
10-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Remove CONFIG_PM_OPS 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: Rafael J. Wysocki <rjw@sisk.pl>
|
#
aad83b14 |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: acpi_hibernation_enter() need not switch interrupts off The function acpi_hibernation_enter() is always called with interrupts off, so it doesn't need to switch them off and on. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
f1a2003e |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Merge do_suspend_lowlevel() into acpi_save_state_mem() The function do_suspend_lowlevel() is specific to x86 and defined in assembly code, so it should be called from the x86 low-level suspend code rather than from acpi_suspend_enter(). Merge do_suspend_lowlevel() into the x86's acpi_save_state_mem() and change the name of the latter to acpi_suspend_lowlevel(), so that the function's purpose is better reflected by its name. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
979f11b0 |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Call acpi_save_state_mem() right before low-level suspend Since acpi_save_state_mem() is only called by acpi_suspend_enter() if the target sleep state is S3, it's better to call it under the switch (acpi_state), right before do_suspend_lowlevel(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
7a63f08b |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Modify the "low-level resume finished" message Move the low-level resume completion message to the point where control goes back to acpi_suspend_enter() during resume and change it so that it's more informative. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
82911fe1 |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: acpi_suspend_enter() need not switch interrupts off The function acpi_suspend_enter() is always called with interrupts off, so it doesn't need to switch them off and on. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
c41b93fb |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Drop acpi_restore_state_mem() The function acpi_restore_state_mem() has never been and most likely never will be used, so remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
d1ee4335 |
|
14-Feb-2011 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, trampoline: Use the unified trampoline setup for ACPI wakeup Use the unified trampoline allocation setup to allocate and install the ACPI wakeup code in low memory. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> LKML-Reference: <4D5DFBE4.7090104@intel.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Matthieu Castet <castet.matthieu@free.fr> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
|
#
d551d81d |
|
19-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Call suspend_nvs_free() earlier during resume It turns out that some device drivers map pages from the ACPI NVS region during resume using ioremap(), which conflicts with ioremap_cache() used for mapping those pages by the NVS save/restore code in nvs.c. Make the NVS pages mapped by the code in nvs.c be unmapped before device drivers' resume routines run. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7b330707 |
|
06-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Blacklist Averatec machine known to require acpi_sleep=nonvs Apparently, Averatec AV1020-ED2 does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=16396#c86 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
26fcaf60 |
|
06-Jan-2011 |
Jiri Slaby <jirislaby@kernel.org> |
PM: Fix oops in suspend/hibernate code related to failing ioremap() When ioremap() fails (which might happen for some reason), we nicely oops in suspend_nvs_save() due to NULL dereference by memcpy() in there. Fail gracefully instead. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
291a73c9 |
|
12-Dec-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Do not save/restore NVS on Sony Vaio VGN-NW130D The saving of the NVS memory area during suspend and restoring it during resume causes problems to appear on Sony Vaio VGN-NW130D, so blacklist that machine to avoid those problems. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=23002 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Adriano <adriano.vilela@yahoo.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
091aad6a |
|
07-Dec-2010 |
Jan Beulich <JBeulich@novell.com> |
ACPI: eliminate unused variable warning for !ACPI_SLEEP Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2f55ac07 |
|
16-Nov-2010 |
Lionel Debroux <lionel_debroux@yahoo.fr> |
suspend: constify platform_suspend_ops 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 <lionel_debroux@yahoo.fr> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
073ef1f6 |
|
09-Nov-2010 |
Lionel Debroux <lionel_debroux@yahoo.fr> |
hibernation: constify platform_hibernation_ops 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 <jkosina@suse.cz>
|
#
af48931c |
|
17-Oct-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Blacklist another machine that needs acpi_sleep=nonvs Sony Vaio VPCEB1Z1E is reported to require acpi_sleep=nonvs for suspend/resume to work on it correctly, so blacklist it. Reported-by: Emanuele Bigiarini <pulmro@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
01eac60b |
|
18-Oct-2010 |
Stephen Hemminger <shemminger@vyatta.com> |
ACPI: static sleep_states[] and acpi_gts_bfs_check Only used in one file so should be static. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
761afb86 |
|
14-Oct-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / PM: Fix problems with acpi_pm_device_sleep_state() There is a number of problems with acpi_pm_device_sleep_state() now. First, if _S0W is not defined, it prevents devices from being put into D3 by PCI runtime PM, which shouldn't happen. Second, it shouldn't use adev->wakeup.state.enabled, because if it's set, it only means that either the device is permanently enabled to wake up the system, or that it has been enabled to do that through /proc/acpi/wakeup. Finally, it should be compiled if CONFIG_PM_SLEEP is not set, so that PCI runtime PM works correctly in that case. Fix these problems. Reported-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
53998648 |
|
24-Sep-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / ACPI: Blacklist systems known to require acpi_sleep=nonvs Commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2 (ACPI: Store NVS state even when entering suspend to RAM) changed the ACPI suspend to RAM code so that the NVS memory area is always unconditionally saved during suspend and restored during resume, since some systems evidently need that for the suspend-resume to work on them. However, it turned out that this change broke suspend-resume on a few systems, so commit 72ad5d77fb981963edae15eee8196c80238f5ed0 (ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM) introduced the acpi_sleep=nonvs command line switch to allow their users to work around this issue. To keep track of the systems that require this workaround and to make the life of their users slightly easier blacklist them in acpisleep_dmi_table[]. https://bugzilla.kernel.org/show_bug.cgi?id=16396 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
72ad5d77 |
|
23-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM Commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2 (ACPI: Store NVS state even when entering suspend to RAM) caused the ACPI suspend code save the NVS area during suspend and restore it during resume unconditionally, although it is known that some systems need to use acpi_sleep=s4_nonvs for hibernation to work. To allow the affected systems to avoid saving and restoring the NVS area during suspend to RAM and resume, introduce kernel command line option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its alias temporarily (add acpi_sleep=s4_nonvs to the feature removal file). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 . Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: tomas m <tmezzadra@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e8b6f970 |
|
24-Jun-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPICA: Introduce acpi_gpe_wakeup() ACPICA uses reference counters to avoid disabling GPEs too early in case they have been enabled for many times. This is done separately for runtime and for wakeup, but the wakeup GPE reference counter is not really necessary, because GPEs are only enabled to wake up the system at the hardware level by acpi_enter_sleep_state(). Thus it only is necessary to set the corresponding bits in the wakeup enable masks of these GPEs' registers right before the system enters a sleep state. Moreover, the GPE wakeup enable bits can only be set when the target sleep state of the system is known and they need to be cleared immediately after wakeup regardless of how many wakeup devices are associated with a given GPE. On the basis of the above observations, introduce function acpi_gpe_wakeup() to be used for setting or clearing the enable bit corresponding to a given GPE in its enable register's enable_for_wake mask. Modify the ACPI suspend and wakeup code the use acpi_gpe_wakeup() instead of acpi_{enable|disable}_gpe() to set and clear GPE enable bits in their registers' enable_for_wake masks during system transitions to a sleep state and back to the working state, respectively. [This will allow us to drop the third argument of acpi_{enable|disable}_gpe() and simplify the GPE handling code.] Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
618d7fd0 |
|
01-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Sleep: Drop acpi_suspend_finish() The function acpi_suspend_finish() is not necessary any more, because acpi_pm_finish() can be used instead of it just fine. Remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c5f7a1bb |
|
01-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Sleep: Consolidate suspend and hibernation routines Some hibernation and suspend routines can be merged, which reduces the complexity of code a bit. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
78f5f023 |
|
06-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Wakeup: Simplify enabling of wakeup devices To simplify the enabling of wakeup devices during system suspend and hibernation, merge acpi_enable_wakeup_device_prep() with acpi_disable_wakeup_device() and remove unnecessary (and no longer valid) comments from the latter. Rename acpi_enable_wakeup_device() to acpi_enable_wakeup_devices() and acpi_disable_wakeup_device() to acpi_disable_wakeup_devices(), because these functions usually operate on multiple device objects. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
25bed557 |
|
01-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Sleep: Rework enabling wakeup devices There is no reason why acpi_enable_wakeup_device() should be called with interrupts disabled, because it doesn't access hardware. Thus it is possible to move it next to acpi_enable_wakeup_device_prep() and make the ACPI suspend, hibernate and poweroff code more straightforward. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e96c4b08 |
|
06-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / Sleep: Free NVS copy if suspending of devices fails If suspending of devices fails or system suspend is tested in the "devices" mode, the memory allocated for storing a copy of the ACPI NVS area will not be freed, because acpi_pm_finish() is not called in that case. Fix this by moving the suspend_nvs_free() call to acpi_pm_end(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2a6b6976 |
|
28-May-2010 |
Matthew Garrett <mjg@redhat.com> |
ACPI: Store NVS state even when entering suspend to RAM https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where a system fails to successfully resume after the second suspend. Maxim Levitsky discovered that this could be rectified by forcibly saving and restoring the ACPI non-volatile state. The spec indicates that this is only required for S4, but testing the behaviour of Windows by adding an ACPI NVS region to qemu's e820 map and registering a custom memory read/write handler reveals that it's saved and restored even over suspend to RAM. We should mimic that behaviour to avoid other broken platforms. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dd4c4f17 |
|
28-May-2010 |
Matthew Garrett <mjg@redhat.com> |
suspend: Move NVS save/restore code to generic suspend functionality Saving platform non-volatile state may be required for suspend to RAM as well as hibernation. Move it to more generic code. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fe955682 |
|
08-Apr-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Fix names of functions that block/unblock EC transactions The names of the functions used for blocking/unblocking EC transactions during suspend/hibernation suggest that the transactions are suspended and resumed by them, while in fact they are disabled and enabled. Rename the functions (and the flag used by them) to better reflect what they really do. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d5a64513 |
|
08-Apr-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Fix race between EC transactions and system suspend There still is a race that may result in suspending the system in the middle of an EC transaction in progress, which leads to problems (like the kernel thinking that the ACPI global lock is held during resume while in fact it's not). To remove the race condition, modify the ACPI platform suspend and hibernate callbacks so that EC transactions are blocked right after executing the _PTS global control method and are allowed to happen again right after the low-level wakeup. Introduce acpi_pm_freeze() that will disable GPEs, wait until the event queues are empty and block EC transactions. Use it wherever GPEs are disabled in preparation for switching local interrupts off. Introduce acpi_pm_thaw() that will allow EC transactions to happen again and enable runtime GPEs. Use it to balance acpi_pm_freeze() wherever necessary. In addition to that use acpi_ec_resume_transactions_early() to unblock EC transactions as early as reasonably possible during resume. Also unblock EC transactions in acpi_hibernation_finish() and in the analogous suspend routine to make sure that the EC transactions are enabled in all error paths. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=14668 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b6dacf63 |
|
11-May-2010 |
Matthew Garrett <mjg@redhat.com> |
ACPI: Unconditionally set SCI_EN on resume The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by: Matthew Garrett <mjg@redhat.com> Tested-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7d6fb7bd |
|
11-May-2010 |
Alex Chiang <achiang@canonical.com> |
ACPI: sleep: eliminate duplicate entries in acpisleep_dmi_table[] Duplicate entries ended up acpisleep_dmi_table[] by accident. They don't hurt functionality, but they are ugly, so let's get rid of them. Cc: stable@kernel.org Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ea5bc73f |
|
27-Apr-2010 |
Kamal Mostafa <kamal@canonical.com> |
ACPI: sleep: init_set_sci_en_on_resume for Dell Studio 155x Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume' list to fix hang on resume. BugLink: http://bugs.launchpad.net/bugs/553498 Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Alex Chiang <achiang@canonical.com> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
|
#
07bedca2 |
|
20-Apr-2010 |
Alex Chiang <achiang@canonical.com> |
ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can successfully suspend/resume once, and then hang on the second s/r cycle. We got confirmation that this was due to a BIOS defect. The BIOS did not properly set SCI_EN coming out of S3. The BIOS guys hinted that The Other Leading OS ignores the fact that hardware owns the bit and sets it manually. In any case, an existing DMI table exists for machines where this defect is a known problem. Lenovo promise to fix their BIOS, but for folks who either won't or can't upgrade their BIOS, allow Linux to workaround the issue. https://bugzilla.kernel.org/show_bug.cgi?id=15407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 Confirmed by numerous testers in the launchpad bug that using acpi_sleep=sci_force_enable fixes the issue. We add the machines to acpisleep_dmi_table[] to automatically enable this workaround. Cc: stable@kernel.org Cc: Colin King <colin.king@canonical.com> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f6bb13aa |
|
03-Mar-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Close race between EC and resume from hibernation There is a race between resume from hibernation and the EC driver that may result in restoring the hibernation image in the middle of an EC transaction in progress, which in turn may lead to unpredictable behavior of the platform. To remove that race condition, add a helpers for suspending and resuming EC transactions in a safe way to be executed by the ACPI platform hibernate pre-restore and restore cleanup callbacks. http://bugzilla.kernel.org/show_bug.cgi?id=14668 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9630bdd9 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI: Use GPE reference counting to support shared GPEs ACPI GPEs may map to multiple devices. The current GPE interface only provides a mechanism for enabling and disabling GPEs, making it difficult to change the state of GPEs at runtime without extensive cooperation between devices. Add an API to allow devices to indicate whether or not they want their device's GPE to be enabled for both runtime and wakeup events. Remove the old GPE type handling entirely, which gets rid of various quirks, like the implicit disabling with GPE type setting. This requires a small amount of rework in order to ensure that non-wake GPEs are enabled by default to preserve existing behaviour. Based on patches from Matthew Garrett <mjg@redhat.com>. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d7f0eea9 |
|
30-Dec-2009 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: introduce kernel parameter acpi_sleep=sci_force_enable Introduce kernel parameter acpi_sleep=sci_force_enable some laptop requires SCI_EN being set directly on resume, or else they hung somewhere in the resume code path. We already have a blacklist for these laptops but we still need this option, especially when debugging some suspend/resume problems, in case there are systems that need this workaround and are not yet in the blacklist. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
87c687be |
|
23-Nov-2009 |
Len Brown <len.brown@intel.com> |
ACPI: DMI init_set_sci_en_on_resume for HP-Compaq C700 ...else ACPI thermal controls fail after resume. http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2839d396 |
|
05-Nov-2009 |
Vaibhav Verma <vaibhav.verma86@gmail.com> |
ACPI: sleep: another HP/Compaq DMI entries for init_set_sci_en_on_resume http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8a1cbf64 |
|
19-Oct-2009 |
Gustavo Maciel Dias Vieira <gustavo@sagui.org> |
ACPI: add DMI entry for SCI_EN resume quirk on HP dv4 Fixes the missing battery on sleep problem for yet another HP laptop ("HP Pavilion dv4"). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13449 Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0baed8da |
|
08-Sep-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support Some PCI devices (not PCI Express), like PCI add-on cards, can generate PME#, but they don't have any special platform wake-up support. For this reason, even if they generate PME# to wake up the system from a sleep state, wake-up events are not generated by the platform. It turns out that, at least on some systems, PCI bridges and the PCI host bridge have ACPI GPEs associated with them that, if enabled to generate wake-up events, allow the system to wake up if one of the add-on devices asserts PME# while the system is in a sleep state. Following this observation, if a PCI device without direct ACPI wake-up support is prepared to wake up the system during a transition into a sleep state (eg. suspend to RAM), try to configure the bridges on the path from the device to the root bridge to wake-up the system. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
df8db91f |
|
08-Sep-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / ACPI PM: Rework some debug messages Move a debug message from acpi_pci_sleep_wake() to acpi_pm_device_sleep_wake() and use the standard dev_*() macros in there. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
eb0ca849 |
|
29-Aug-2009 |
Len Brown <len.brown@intel.com> |
ACPI: sleep: another HP DMI entry for init_set_sci_en_on_resume DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv3 Notebook PC") http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ec79be26 |
|
29-Jul-2009 |
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> |
PM / ACPI: HP G7000 Notebook needs a SCI_EN resume quirk This fixes regression (battery "vanishing" on resume) introduced by commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 ("ACPI Suspend: Enable ACPI during resume if SCI_EN is not set") and also the issue with the "screaming" IRQ 9. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13745 Reported-and-tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: stable@kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: Len Brown <lenb@kernel.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
6a7c7eaf |
|
19-Apr-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM/Suspend: Introduce two new platform callbacks to avoid breakage 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 <rjw@sisk.pl> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Len Brown <len.brown@intel.com>
|
#
96f15efc |
|
17-Apr-2009 |
Len Brown <len.brown@intel.com> |
ACPI: Disable _GTS and _BFS support by default Executing BIOS code paths not exercised by Windows tends to get Linux into trouble. However, if a system does benefit from _GTS or _BFS, acpi.gts=1 an acpi.bfs=1 are now available to enable them. http://bugzilla.kernel.org/show_bug.cgi?id=13041 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2a9ef8e1 |
|
18-Mar-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: suspend: Add the Pansonic CF51 box to the dmi check table The Pansonic CF51-2L requires "acpi_sleep=old_ordering", so invoke it automatically via DMI. http://bugzilla.kernel.org/show_bug.cgi?id=12561 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50ffba1b |
|
23-Feb-2009 |
Bob Moore <robert.moore@intel.com> |
ACPICA: Rename ACPI bit register access functions Rename acpi_get_register and acpi_set_register to clarify the purpose of these functions. New names are acpi_read_bit_register and acpi_write_bit_register. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e60cc7a6 |
|
13-Mar-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: move private declarations to internal.h A number of things that shouldn't be exposed outside the ACPI core were declared in include/acpi/acpi_drivers.h, where anybody can see them. This patch moves those declarations to a new "internal.h" inside drivers/acpi. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
45e77988 |
|
15-Mar-2009 |
Zhang Rui <rui.zhang@intel.com> |
ACPI suspend: Blacklist Toshiba Satellite L300 that requires to set SCI_EN directly on resume This is a supplement of commit 65df78473ffbf3bff5e2034df1638acc4f3ddd50. http://bugzilla.kernel.org/show_bug.cgi?id=12798 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a1404495 |
|
11-Feb-2009 |
Andy Whitcroft <apw@canonical.com> |
suspend: switch the Asus Pundit P1-AH2 to old ACPI sleep ordering Switch the Asus Pundit P1-AH2 (M2N8L motherboard) to the old ACPI 1.0 sleep ordering by default. Without this it will not suspend/resume correctly. Signed-off-by: Andy Whitcroft <apw@canonical.com> Tested-by: Dustin Kirkland <kirkland@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4d939155 |
|
04-Feb-2009 |
Frank Seidel <frank@f-seidel.de> |
ACPI: add missing KERN_* constants to printks According to kerneljanitors todo list all printk calls (beginning a new line) should have an according KERN_* constant. Those are the missing peaces here for the acpi subsystem. Signed-off-by: Frank Seidel <frank@f-seidel.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5d8b532a |
|
16-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI suspend: Fix compilation warnings in drivers/acpi/sleep.c Fix two compilation warnings in drivers/acpi/sleep.c, one triggered by unsetting CONFIG_SUSPEND and the other triggered by unsetting CONFIG_HIBERNATION, by moving some code under the appropriate #ifdefs . Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d08ca2ca |
|
16-Jan-2009 |
Len Brown <len.brown@intel.com> |
ACPI: rename main.c to sleep.c Signed-off-by: Len Brown <len.brown@intel.com>
|