06 Dec, 2011
2 commits
-
Modify pci_acpi_wake_dev() to avoid resuming PME-capable devices
whose PME Status bits are not set, which may happen currently if
several devices are associated with the same wakeup GPE and all
of them are notified whenever at least one of them signals PME.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
"PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.Measured to save around 5W on an idle Thinkpad X220.
Signed-off-by: Matthew Garrett
Signed-off-by: Jesse Barnes
15 Oct, 2011
2 commits
-
The result returned by acpi_dev_run_wake() is always either -EINVAL
or -ENODEV, while obviously it should return 0 on success. The
problem is that the leftover error variable, that's not really used
in the function, is initialized with -ENODEV and then returned
without modification.To fix this issue remove the error variable from acpi_dev_run_wake()
and make the function return 0 on success as appropriate.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.Tested-by: Sarah Sharp
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
29 May, 2011
1 commit
-
_SxW returns an Integer containing the lowest D-state supported in state
Sx. If OSPM has not indicated that it supports _PR3, then the value “3”
corresponds to D3. If it has indicated _PR3 support, the value “3”
represents D3hot and the value “4” represents D3cold.Linux does set _OSC._PR3, so we should fix it to expect that _SxW can
return 4.Signed-off-by: Lin Ming
Acked-by: Jesse Barnes
Signed-off-by: Len Brown
25 Feb, 2011
1 commit
-
The wakeup.run_wake_count ACPI device field is only used by the PCI
runtime PM code to "protect" devices from being prepared for
generating wakeup signals more than once in a row. However, it
really doesn't provide any protection, because (1) all of the
functions it is supposed to protect use their own reference counters
effectively ensuring that the device will be set up for generating
wakeup signals just once and (2) the PCI runtime PM code uses
wakeup.run_wake_count in a racy way, since nothing prevents
acpi_dev_run_wake() from being called concurrently from two different
threads for the same device.Remove the wakeup.run_wake_count ACPI device field which is
unnecessary, confusing and used in a wrong way.Signed-off-by: Rafael J. Wysocki
15 Jan, 2011
1 commit
-
Make wakeup events be reported by the PCI subsystem before attempting to
resume devices or queuing up runtime resume requests for them, because
wakeup events should be reported as soon as they have been detected.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
24 Dec, 2010
1 commit
-
We currently refuse to touch the ASPM registers if the BIOS tells us that
ASPM isn't supported. This can cause problems if the BIOS has (for any
reason) enabled ASPM on some devices anyway. Change the code such that we
explicitly clear ASPM if the FADT indicates that ASPM isn't supported,
and make sure we tidy up appropriately on device removal in order to deal
with the hotplug case. If ASPM is disabled because the BIOS doesn't hand
over control then we won't touch the registers.Signed-off-by: Matthew Garrett
Signed-off-by: Jesse Barnes
08 Aug, 2010
1 commit
-
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
ACPI / ACPICA: Simplify acpi_ev_initialize_gpe_block()
ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset
ACPI / ACPICA: Do not execute _PRW methods during initialization
ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()
ACPICA: Update version to 20100702
ACPICA: Fix for Alias references within Package objects
ACPICA: Fix lint warning for 64-bit constant
ACPICA: Remove obsolete GPE function
ACPICA: Update debug output components
ACPICA: Add support for WDDT - Watchdog Descriptor Table
ACPICA: Drop acpi_set_gpe
ACPICA: Use low-level GPE enable during GPE block initialization
ACPI / EC: Do not use acpi_set_gpe
ACPI / EC: Drop suspend and resume routines
ACPICA: Remove wakeup GPE reference counting which is not used
ACPICA: Introduce acpi_gpe_wakeup()
ACPICA: Rename acpi_hw_gpe_register_bit
ACPICA: Update version to 20100528
ACPICA: Add signatures for undefined tables: ATKG, GSCI, IEIT
ACPICA: Optimization: Reduce the number of namespace walks
...
19 Jul, 2010
1 commit
-
One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.Generally, there are two problems in that area. First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended. Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.The /sys/power/wakeup_count file may be read from or written to by
user space. Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter. If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count. Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state. Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well. Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.Signed-off-by: Rafael J. Wysocki
Acked-by: Jesse Barnes
Acked-by: Greg Kroah-Hartman
Acked-by: markgross
Reviewed-by: Alan Stern
07 Jul, 2010
1 commit
-
After the previous patch that introduced acpi_gpe_wakeup() and
modified the ACPI suspend and wakeup code to use it, the third
argument of acpi_{enable|disable}_gpe() and the GPE wakeup
reference counter are not necessary any more. Remove them and
modify all of the users of acpi_{enable|disable}_gpe()
accordingly. Also drop GPE type constants that aren't used
any more.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
02 Mar, 2010
1 commit
-
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: replace acpi_integer by u64
ACPICA: Update version to 20100121.
ACPICA: Remove unused uint32_struct type
ACPICA: Disassembler: Remove obsolete "Integer64" field in parse object
ACPICA: Remove obsolete ACPI_INTEGER (acpi_integer) type
ACPICA: Predefined name repair: fix NULL package elements
ACPICA: AcpiGetDevices: Eliminate unnecessary _STA calls
ACPICA: Update all ACPICA copyrights and signons to 2010
ACPICA: Update for new gcc-4 warning options
23 Feb, 2010
1 commit
-
Although the majority of PCI devices can generate PMEs that in
principle may be used to wake up devices suspended at run time,
platform support is generally necessary to convert PMEs into wake-up
events that can be delivered to the kernel. If ACPI is used for this
purpose, PME signals generated by a PCI device will trigger the ACPI
GPE associated with the device to generate an ACPI wake-up event that
we can set up a handler for, provided that everything is configured
correctly.Unfortunately, the subset of PCI devices that have GPEs associated
with them is quite limited. The devices without dedicated GPEs have
to rely on the GPEs associated with other devices (in the majority of
cases their upstream bridges and, possibly, the root bridge) to
generate ACPI wake-up events in response to PME signals from them.Add ACPI platform support for PCI PME wake-up:
o Add a framework making is possible to use ACPI system notify
handlers for run-time PM.
o Add new PCI platform callback ->run_wake() to struct
pci_platform_pm_ops allowing us to enable/disable the platform to
generate wake-up events for given device. Implemet this callback
for the ACPI platform.
o Define ACPI wake-up handlers for PCI devices and PCI root buses and
make the PCI-ACPI binding code register wake-up notifiers for all
PCI devices present in the ACPI tables.
o Add function pci_dev_run_wake() which can be used by PCI drivers to
check if given device is capable of generating wake-up events at
run time.Developed in cooperation with Matthew Garrett .
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
28 Jan, 2010
1 commit
-
acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.Signed-off-by: Lin Ming
Signed-off-by: Len Brown
17 Dec, 2009
1 commit
-
Having read the PM part of the PCIe 2.0 specification more carefully
I think that it was a mistake to restrict the wake-up enable
propagation to non-PCIe devices, because if we do not request
control of the root ports' PME registers via OSC, PCIe PME is
supposed to be handled by the platform, just like the non-PCIe PME.
Even if we do that, the wake-up propagation is done to allow the
devices to wake up the system from sleep states which involves the
platform anyway, so it won't hurt.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
25 Nov, 2009
1 commit
-
Change for PCI core to use pci_is_pcie() instead of checking
pci_dev->is_pcie.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
10 Sep, 2009
3 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 -
Rework the PCI wake-up code so that it's easier to read without
changing the functionality.Reviewed-by: Matthew Garrett
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
05 Apr, 2009
1 commit
-
Conflicts:
arch/x86/kernel/cpu/cpufreq/longhaul.cSigned-off-by: Len Brown
27 Mar, 2009
1 commit
-
Add new flags in the Boot Architecture flags field. Update comments
for all FADT flags. Add FADT version when each flag was defined.Signed-off-by: Bob Moore
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
20 Mar, 2009
1 commit
-
Move PCI _OSC management code from drivers/pci/pci-acpi.c to
drivers/acpi/pci_root.c. The benefits are- We no longer need struct osc_data and its management code (contents
are moved to struct acpi_pci_root). This simplify the code, and we
no longer care about kmalloc() failure.- We can make pci_acpi_osc_support() be a static function, which is
called only from drivers/acpi/pci_root.c.Signed-off-by: Kenji Kaneshige
Reviewed-by: Andrew Patterson
Tested-by: Andrew Patterson
Acked-by: Alex Chiang
Signed-off-by: Jesse Barnes
09 Jan, 2009
1 commit
08 Jan, 2009
6 commits
-
Cleanup _OSC evaluation code. Some whitespace changes and a few other
minor cleanups.Reviewed-by: Andrew Patterson
Tested-by: Andrew Patterson
Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
If a control had already been granted, we don't need to re-evaluate
_OSC for it because firmware may not reject control of any feature it
has previously granted control to.Reviewed-by: Andrew Patterson
Tested-by: Andrew Patterson
Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
Reverts adf411b819adc9fa96e9b3e638c7480d5e71d270.
The commit adf411b819adc9fa96e9b3e638c7480d5e71d270 was based on the
improper assumption that queried result was not updated when _OSC
support field was changed. But, in fact, queried result is updated
whenever _OSC support field was changed through __acpi_query_osc().
As a result, the commit adf411b819adc9fa96e9b3e638c7480d5e71d270 only
introduced unnecessary additional _OSC evaluation...Tested-by: Andrew Patterson
Reviewed-by: Andrew Patterson
Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
The acpi_query_osc, __pci_osc_support_set, pci_osc_support_set, and
pcie_osc_support_set functions have been obsoleted in favor of setting
these capabilities during root bridge discovery with
pci_acpi_osc_support. There are no longer any callers of these
functions, so remove them.Signed-off-by: Andrew Patterson
Signed-off-by: Jesse Barnes -
Add pci_acpi_osc_support() and call it when a PCI bridge is added. This
allows us to avoid having every individual PCI root bridge driver call
_OSC support for every root bridge in their probe functions, a
significant savings in boot time.Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes -
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.Acked-by: Greg Kroah-Hartman
Signed-Off-By: Kay Sievers
Signed-off-by: Jesse Barnes
31 Dec, 2008
1 commit
-
External driver files should not include any private acpica headers.
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
12 Nov, 2008
1 commit
-
Currently acpi_run_osc() checks all the bits in _OSC result code (the
first DWORD in the capabilities buffer) to see error condition. But the
bit 0, which doesn't indicate any error, must be ignored.The bit 0 is used as the query flag at _OSC invocation time. Some
platforms clear it during _OSC evaluation, but the others don't. On
latter platforms, current acpi_run_osc() mis-detects error when _OSC is
evaluated with query flag set because it doesn't ignore the bit 0.
Because of this, the __acpi_query_osc() always fails on such platforms.And this is the cause of the problem that pci_osc_control_set() doesn't
work since the commit 4e39432f4df544d3dfe4fc90a22d87de64d15815 which
changed pci_osc_control_set() to use __acpi_query_osc().Tested-by:"Tomasz Czernecki
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
25 Oct, 2008
1 commit
-
ACPI Warning (nseval-0168): Insufficient arguments - method [_OSC] needs 5, found 4 [20080926]
ACPI Warning (nspredef-0252): \_SB_.PCI0._OSC: Parameter count mismatch - ASL declared 5, expected 4 [20080926]
ACPI Error (nspredef-0163): \_SB_.PCI0._OSC: Missing expected return value [20080926]
BUG: unable to handle kernel NULL pointer dereference at 00000000
IP: [] acpi_run_osc+0xa1/0x170Signed-off-by: Rafael J. Wysocki
Tested-by: James Bottomley
Signed-off-by: Len Brown
23 Oct, 2008
4 commits
-
If acpi_query_osc() returns other than AE_OK, __pci_osc_support_set()
stops scanning ACPI objects to evaluate _OSC. This prevents subsequent
_OSCs from being evaluated if some of root bridge doesn't have _OSC, for
example. So acpi_query_osc() should return always AE_OK to evaluate all
_OSC.Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
In current pci_osc_control_set() implementation, once the _OSC control
field is queried, it is never queried again. But the query result can
change depending on the _OSC support field. For example, if PCI Express
Native Hot Plug control depends on ASPM support on a certain platform, a
PCI Express Native Hot Plug Control query would fail before the ASPM
driver was loaded, but it would succeed if the ASPM driver was loaded
first. Therefore, pci_osc_control_set() should query the _OSC control
field every time.Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
Current pci_osc_control_set() evaluates _OSC without query for control
bits, unless __pci_osc_support_set() is called beforehand. But as
strongly recommended in PCI firmware specification, it should query
control bits first.This patch changes pci_osc_control_set() to query control bits first
even if __pci_osc_support_set() is not called beforehand.Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes -
Fix possible race condition on _OSC evaluation.
Current _OSC evaluation code has possible race condition because it
maniputes osc_data linked list or its contents without any lock
mechanism.Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Signed-off-by: Jesse Barnes
29 Jul, 2008
1 commit
-
The ACPI FADT table includes an ASPM control bit. If the bit is set, do
not enable ASPM since it may indicate that the platform doesn't actually
support the feature.Tested-by: Jack Howarth
Signed-off-by: Shaohua Li
Signed-off-by: Jesse Barnes
08 Jul, 2008
3 commits
-
* Introduce function acpi_pm_device_sleep_wake() for enabling and
disabling the system wake-up capability of devices that are power
manageable by ACPI.* Introduce function acpi_bus_can_wakeup() allowing other (dependent)
subsystems to check if ACPI is able to enable the system wake-up
capability of given device.* Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().* Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
for the ACPI 'driver' make it use acpi_bus_can_wakeup().* Move the PME# handlig code out of pci_enable_wake() and split it
into two functions, pci_pme_capable() and pci_pme_active(),
allowing the caller to check if given device is capable of
generating PME# from given power state and to enable/disable the
device's PME# functionality, respectively.* Modify pci_enable_wake() to use the new ACPI callbacks and the new
PME#-related functions.* Drop the generic .platform_enable_wakeup() callback that is not
used any more.* Introduce device_set_wakeup_capable() that will set the
power.can_wakeup flag of given device.* Rework PCI device PM initialization so that, if given device is
capable of generating wake-up events, either natively through the
PME# mechanism, or with the help of the platform, its
power.can_wakeup flag is set and its power.should_wakeup flag is
unset as appropriate.* Make ACPI set the power.can_wakeup flag for devices found to be
wake-up capable by it.* Make the ACPI wake-up code enable/disable GPEs for devices that
have the wakeup.flags.prepared flag set (which means that their
wake-up power has been enabled).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
Rework pci_set_power_state() so that the platform callback is
invoked before the native mechanism, if necessary. Also, make
the function check if the device is power manageable by the
platform before invoking the platform callback.This may matter if the device dependent on additional power
resources controlled by the platform is being put into D0, in which
case those power resources must be turned on before we attempt to
handle the device itself.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes -
Introduce function pointer platform_pci_power_manageable to be used
by the platform-related code to point to a function allowing us to
check if given device is power manageable by the platform.Introduce acpi_pci_power_manageable() playing that role for ACPI.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes