IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Whenever a device is resumed or its power state is changed using the
platform, its new power state is read from the PM Control & Status Register
and cached in pci_dev->current_state by calling pci_update_current_state().
If the device is in D3cold, reading from config space typically results in
a fabricated "all ones" response. But if it's in D3hot, the two bits
representing the power state in the PMCSR are *also* set to 1. Thus D3hot
and D3cold are not discernible by just reading the PMCSR.
To account for this, pci_update_current_state() uses two workarounds:
- When transitioning to D3cold using pci_platform_power_transition(), the
new power state is set blindly by pci_update_current_state(), i.e.
without verifying that the device actually *is* in D3cold. This is
achieved by setting the "state" argument to PCI_D3cold. The "state"
argument was originally intended to convey the new state in case the
device doesn't have the PM capability. It is *also* used to convey the
device state if the PM capability is present and the new state is D3cold,
but this was never explained in the kerneldoc.
- Once the current_state is set to D3cold, further invocations of
pci_update_current_state() will blindly assume that the device is still
in D3cold and leave the current_state unmodified. To get out of this
impasse, the current_state has to be set directly, typically by calling
pci_raw_set_power_state() or pci_enable_device().
It would be desirable if pci_update_current_state() could reliably detect
D3cold by itself. That would allow us to do away with these workarounds,
and it would allow for a smarter, more energy conserving runtime resume
strategy after system sleep: Currently devices which utilize
direct_complete are mandatorily runtime resumed in their ->complete stage.
This can be avoided if their power state after system sleep is the same as
before, but it requires a mechanism to detect the power state reliably.
We've just gained the ability to query the platform firmware for its
opinion on the device's power state. On platforms conforming to ACPI 4.0
or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3
and therefore the deepest power state that will ever be reported is D3hot,
even though the device may actually be in D3cold. To detect D3cold in
those cases, accessibility of the vendor ID in config space is probed using
pci_device_is_present(). This also works for devices which are not
platform-power-manageable at all, but can be suspended to D3cold using a
nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on
the Mac).
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
a6a64026c0