15 Aug, 2010
2 commits
25 Jul, 2010
1 commit
-
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
Reported-and-tested-by: tomas m
Signed-off-by: Len Brown
07 Jul, 2010
6 commits
-
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
Signed-off-by: Len Brown
Signed-off-by: Bob Moore
Signed-off-by: Lin Ming
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
Some hibernation and suspend routines can be merged, which reduces
the complexity of code a bit.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown
12 Jun, 2010
1 commit
-
Conflicts:
drivers/acpi/sleep.cSigned-off-by: Len Brown
10 Jun, 2010
2 commits
-
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
Signed-off-by: Len Brown -
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
Acked-by: Rafael J. Wysocki
Tested-by: Maxim Levitsky
Signed-off-by: Len Brown
02 Jun, 2010
1 commit
29 May, 2010
2 commits
-
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
Signed-off-by: Len Brown -
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
Reported-and-tested-by: Maxim Levitsky
Signed-off-by: Len Brown
12 May, 2010
2 commits
-
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
Tested-by: Rafael J. Wysocki
Signed-off-by: Len Brown -
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
Signed-off-by: Linus Torvalds
07 May, 2010
1 commit
-
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
Acked-by: Alex Chiang
Cc: stable@kernel.org
Signed-off-by: Len Brown
06 May, 2010
1 commit
-
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/532374Confirmed 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
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
15 Mar, 2010
1 commit
-
…31916-power-state', 'ht-warn-2.6.34', 'pnp', 'processor-rename', 'sony-2.6.34', 'suse-bugzilla-531547', 'tz-check', 'video' and 'misc-2.6.34' into release
09 Mar, 2010
1 commit
-
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
Reported-and-tested-by: Maxim Levitsky
Signed-off-by: Len Brown
23 Feb, 2010
1 commit
-
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 .
Signed-off-by: Matthew Garrett
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
31 Dec, 2009
1 commit
-
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
Acked-by: Rafael J. Wysocki
Signed-off-by: Len Brown
24 Nov, 2009
1 commit
-
...else ACPI thermal controls fail after resume.
http://bugzilla.kernel.org/show_bug.cgi?id=13745
Signed-off-by: Len Brown
06 Nov, 2009
2 commits
-
http://bugzilla.kernel.org/show_bug.cgi?id=13745
Signed-off-by: Len Brown
-
Fixes the missing battery on sleep problem for yet another HP laptop
("HP Pavilion dv4").Fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=13449Signed-off-by: Gustavo Maciel Dias Vieira
Signed-off-by: Len Brown
19 Sep, 2009
1 commit
10 Sep, 2009
2 commits
-
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
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
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
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
30 Aug, 2009
1 commit
-
DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv3 Notebook PC")
http://bugzilla.kernel.org/show_bug.cgi?id=13745
Signed-off-by: Len Brown
30 Jul, 2009
1 commit
-
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
Cc: stable@kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
24 Apr, 2009
1 commit
20 Apr, 2009
1 commit
-
Commit 900af0d973856d6feb6fc088c2d0d3fde57707d3 (PM: Change suspend
code ordering) changed the ordering of suspend code in such a way
that the platform .prepare() callback is now executed after the
device drivers' late suspend callbacks have run. Unfortunately, this
turns out to break ARM platforms that need to talk via I2C to power
control devices during the .prepare() callback.For this reason introduce two new platform suspend callbacks,
.prepare_late() and .wake(), that will be called just prior to
disabling non-boot CPUs and right after bringing them back on line,
respectively, and use them instead of .prepare() and .finish() for
ACPI suspend. Make the PM core execute the .prepare() and .finish()
platform suspend callbacks where they were executed previously (that
is, right after calling the regular suspend methods provided by
device drivers and right before executing their regular resume
methods, respectively).It is not necessary to make analogous changes to the hibernation
code and data structures at the moment, because they are only used
by ACPI platforms.Signed-off-by: Rafael J. Wysocki
Reported-by: Russell King
Acked-by: Len Brown
18 Apr, 2009
1 commit
-
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
05 Apr, 2009
2 commits
04 Apr, 2009
1 commit
-
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
Signed-off-by: Len Brown
27 Mar, 2009
1 commit
-
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
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
17 Mar, 2009
1 commit
-
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
Signed-off-by: Len Brown
16 Mar, 2009
1 commit
-
This is a supplement of commit 65df78473ffbf3bff5e2034df1638acc4f3ddd50.
http://bugzilla.kernel.org/show_bug.cgi?id=12798Signed-off-by: Zhang Rui
Signed-off-by: Len Brown