#
37ba91a8 |
|
12-Nov-2023 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: PM: Add acpi_device_fix_up_power_children() function In some cases it is necessary to fix-up the power-state of an ACPI device's children without touching the ACPI device itself add a new acpi_device_fix_up_power_children() function for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: 6.6+ <stable@vger.kernel.org> # 6.6+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8133844a |
|
12-Jan-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/ACPI: Account for _S0W of the target bridge in acpi_pci_bridge_d3() It is questionable to allow a PCI bridge to go into D3 if it has _S0W returning D2 or a shallower power state, so modify acpi_pci_bridge_d3(() to always take the return value of _S0W for the target bridge into account. That is, make it return 'false' if _S0W returns D2 or a shallower power state for the target bridge regardless of its ancestor Root Port properties. Of course, this also causes 'false' to be returned if the Root Port itself is the target and its _S0W returns D2 or a shallower power state. However, still allow bridges without _S0W that are power-manageable via ACPI to enter D3 to retain the current code behavior in that case. This fixes problems where a hotplug notification is missed because a bridge is in D3. That means hot-added devices such as USB4 docks (and the devices they contain) and Thunderbolt 3 devices may not work. Link: https://lore.kernel.org/linux-pci/20221031223356.32570-1-mario.limonciello@amd.com/ Link: https://lore.kernel.org/r/12155458.O9o76ZdvQC@kreacher Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a6c05e12 |
|
29-Sep-2022 |
Raul E Rangel <rrangel@chromium.org> |
ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle This change adds support for ACPI devices that use ExclusiveAndWake or SharedAndWake in their _CRS GpioInt definition (instead of using _PRW), and also provide power resources. Previously the ACPI subsystem had no idea if the device had a wake capable interrupt armed. This resulted in the ACPI device PM system placing the device into D3Cold, and thus cutting power to the device. With this change we will now query the _S0W method to figure out the appropriate wake capable D-state. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d5008ef5 |
|
29-Aug-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power() In principle, it should be valid to pass NULL as the ACPI device pointer to acpi_device_get_power() and acpi_device_set_power() and they both are expected to return -EINVAL in that case, but that has been broken recently by commit 62fcb99bdf10 ("ACPI: Drop parent field from struct acpi_device") which has caused the ACPI device pointer to be dereferenced in these functions before the NULL check. Fix that and while at it make acpi_device_set_power() only use the parent field if the target ACPI device object's ignore_parent flag in not set. Fixes: 62fcb99bdf10 ("ACPI: Drop parent field from struct acpi_device") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
62fcb99b |
|
24-Aug-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Drop parent field from struct acpi_device The parent field in struct acpi_device is, in fact, redundant, because the dev.parent field in it effectively points to the same object and it is used by the driver core. Accordingly, the parent field can be dropped from struct acpi_device and for this purpose define acpi_dev_parent() to retrieve a parent struct acpi_device pointer from the dev.parent field in struct acpi_device. Next, update all of the users of the parent field in struct acpi_device to use acpi_dev_parent() instead of it and drop it. While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used in one place in a confusing way. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wei Liu <wei.liu@kernel.org> Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
#
0efe92b4 |
|
17-Aug-2022 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
ACPI: PM: Fix acpi_dev_state_d0() kerneldoc The documentation for acpi_dev_state_d0() referred to Documentation/firmware-guide/acpi/low-power-probe.rst that does not exist, the right file name is Documentation/firmware-guide/acpi/non-d0-probe.rst. Fix this. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
45e9aa1f |
|
10-Aug-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Rename acpi_bus_get/put_acpi_device() Because acpi_bus_get_acpi_device() is completely analogous to acpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() and add a kerneldoc comment to it. Accordingly, rename acpi_bus_put_acpi_device() to acpi_put_acpi_dev() and update all of the users of these two functions. While at it, move the acpi_fetch_acpi_dev() header next to the acpi_get_acpi_dev() header in the header file holding them. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
#
a22f18bd |
|
13-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / MMC: PM: Unify fixing up device power Introduce acpi_device_fix_up_power_extended() for fixing up power of a device having an ACPI companion in a manner that takes the device's children into account and make the MMC code use it in two places instead of walking the list of the device ACPI companion's children directly. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
10fa1b2c |
|
22-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: bus: Avoid non-ACPI device objects in walks over children When walking the children of an ACPI device, take extra care to avoid using to_acpi_device() on the ones that are not ACPI devices, because that may lead to out-of-bounds access and memory corruption. While at it, make the function passed to acpi_dev_for_each_child() take a struct acpi_device pointer argument (instead of a struct device one), so it is more straightforward to use. Fixes: b7dd6298db81 ("ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()") Reported-by: kernel test robot <oliver.sang@intel.com> BugLink: https://lore.kernel.org/lkml/20220420064725.GB16310@xsang-OptiPlex-9020/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
6dd4a29d |
|
14-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Always print final debug message in acpi_device_set_power() acpi_device_set_power() prints debug messages regarding its outcome (whether or not the power state has been changed and how) in all cases except when the device whose power state is being changed to D0 is in that power state already. Make acpi_device_set_power() print a final debug message in that case too and while at it, fix the indentation of the "end" label in this function. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b7dd6298 |
|
04-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Introduce acpi_dev_power_up_children_with_adr() Introduce a function powering up all of the children of a given ACPI device object that are power-manageable and hold valid _ADR ACPI objects so as to make it possible to prepare the corresponding "physical" devices for enumeration carried out by a bus type driver, like PCI. This function will be used in a subsequent change set. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
f4f3548d |
|
04-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Unify debug messages in acpi_device_set_power() Convert all of the debug messages printed by acpi_device_set_power() to acpi_handle_debug() and adjust them slightly for consistency with acpi_device_get_power() and other acpi_device_set_power() debug messages. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
255a04cc |
|
04-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Change pr_fmt() in device_pm.c All messages printed by functions in this file either contain the "ACPI" or "acpi" string regardless of the format, or they don't need to contain it at all. In the former case, the "ACPI:" string added by the format is redundant, so drop it from there. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
198ee437 |
|
04-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Convert debug message in acpi_device_get_power() Convert the debug message printed by acpi_device_get_power() to acpi_handle_debug(), because that function is also called when the ACPI device object name has not been set yet and the dev_dbg() message printed by it at that time is not useful. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
99ece713 |
|
03-Dec-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device() Modify the ACPI code to use acpi_fetch_acpi_dev() instead of acpi_bus_get_device() where applicable. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
b82a7df4 |
|
18-Oct-2021 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
ACPI: Add a convenience function to tell a device is in D0 state Add a convenience function to tell whether a device is in D0 state, primarily for use in drivers' probe or remove functions on busses where the custom is to power on the device for the duration of both. Returns false on non-ACPI systems. Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6485fc18 |
|
09-Jun-2021 |
Mario Limonciello <mario.limonciello@amd.com> |
ACPI: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hint AMD systems from Renoir and Lucienne require that the NVME controller is put into D3 over a Modern Standby / suspend-to-idle cycle. This is "typically" accomplished using the `StorageD3Enable` property in the _DSD, but this property was introduced after many of these systems launched and most OEM systems don't have it in their BIOS. On AMD Renoir without these drives going into D3 over suspend-to-idle the resume will fail with the NVME controller being reset and a trace like this in the kernel logs: ``` [ 83.556118] nvme nvme0: I/O 161 QID 2 timeout, aborting [ 83.556178] nvme nvme0: I/O 162 QID 2 timeout, aborting [ 83.556187] nvme nvme0: I/O 163 QID 2 timeout, aborting [ 83.556196] nvme nvme0: I/O 164 QID 2 timeout, aborting [ 95.332114] nvme nvme0: I/O 25 QID 0 timeout, reset controller [ 95.332843] nvme nvme0: Abort status: 0x371 [ 95.332852] nvme nvme0: Abort status: 0x371 [ 95.332856] nvme nvme0: Abort status: 0x371 [ 95.332859] nvme nvme0: Abort status: 0x371 [ 95.332909] PM: dpm_run_callback(): pci_pm_resume+0x0/0xe0 returns -16 [ 95.332936] nvme 0000:03:00.0: PM: failed to resume async: error -16 ``` The Microsoft documentation for StorageD3Enable mentioned that Windows has a hardcoded allowlist for D3 support, which was used for these platforms. Introduce quirks to hardcode them for Linux as well. As this property is now "standardized", OEM systems using AMD Cezanne and newer APU's have adopted this property, and quirks like this should not be necessary. CC: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com> CC: Alexander Deucher <Alexander.Deucher@amd.com> CC: Prike Liang <prike.liang@amd.com> Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Julian Sikorski <belegdol@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
2744d7a0 |
|
09-Jun-2021 |
Mario Limonciello <mario.limonciello@amd.com> |
ACPI: Check StorageD3Enable _DSD property in ACPI code Although first implemented for NVME, this check may be usable by other drivers as well. Microsoft's specification explicitly mentions that is may be usable by SATA and AHCI devices. Google also indicates that they have used this with SDHCI in a downstream kernel tree that a user can plug a storage device into. Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro Suggested-by: Keith Busch <kbusch@kernel.org> CC: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com> CC: Alexander Deucher <Alexander.Deucher@amd.com> CC: Rafael J. Wysocki <rjw@rjwysocki.net> CC: Prike Liang <prike.liang@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
f7599be2 |
|
22-Jun-2021 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
ACPI: PM: postpone bringing devices to D0 unless we need them Currently ACPI power domain brings devices into D0 state in the "resume early" phase. Normally this does not cause any issues, as powering up happens quickly. However there are peripherals that have certain timing requirements for powering on, for example some models of Elan touchscreens need 300msec after powering up/releasing reset line before they can accept commands from the host. Such devices will dominate the time spent in early resume phase and cause increase in overall resume time as we wait for early resume to complete before we can proceed to the normal resume stage. There are ways for a driver to indicate that it can tolerate device being in the low power mode and that it knows how to power the device back up when resuming, bit that requires changes to individual drivers that may not really care about details of ACPI controlled power management. This change attempts to solve this issue at ACPI power domain level, by postponing powering up device until we get to the normal resume stage, unless there is early resume handler defined for the device, or device does not declare any resume handlers, in which case we continue powering up such devices early. This allows us to shave off several hundred milliseconds of resume time on affected systems. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b9370dce |
|
14-May-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM / fan: Put fan device IDs into separate header file The ACPI fan device IDs are shared between the fan driver and the device power management code. The former is modular, so it needs to include the table of device IDs for module autoloading and the latter needs that list to avoid attaching the generic ACPI PM domain to fan devices (which doesn't make sense) possibly before the fan driver module is loaded. Unfortunately, that requires the list of fan device IDs to be updated in two places which is prone to mistakes, so put it into a symbol definition in a separate header file so there is only one copy of it in case it needs to be updated again in the future. Fixes: b9ea0bae260f ("ACPI: PM: Avoid attaching ACPI PM domain to certain devices") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2404b874 |
|
11-May-2021 |
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> |
ACPI: PM: Add ACPI ID of Alder Lake Fan Add a new unique fan ACPI device ID for Alder Lake to support it in acpi_dev_pm_attach() function. Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake") Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3da8236b |
|
27-Mar-2021 |
Xiaofei Tan <tanxiaofei@huawei.com> |
ACPI: PM: add a missed blank line after declarations Add a missed blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c56fd5ea |
|
20-Jan-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Clean up printing messages Replace the remaining ACPI_DEBUG_PRINT() instances in device_pm.c with dev_dbg() invocations, drop the _COMPONENT and ACPI_MODULE_NAME() definitions that are not used any more, and drop the no longer needed ACPI_POWER_COMPONENT definition from the headers and documentation. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b93b7ef6 |
|
24-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: ACPI: Refresh wakeup device power configuration every time When wakeup signaling is enabled for a bridge for the second (or every next) time in a row, its existing device wakeup power configuration may not match the new conditions. For example, some devices below it may have been put into low-power states and that changes the device wakeup power conditions or similar. This causes functional problems to appear on some systems (for example, because of it the Thunderbolt port on Dell Precision 5550 cannot detect devices plugged in after it has been suspended). For this reason, modify __acpi_device_wakeup_enable() to refresh the device wakeup power configuration of the target device on every invocation, not just when it is called for that device first time in a row. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
7482c5cb |
|
24-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup() The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to be reference counted for wakeup enabling, because they may be enabled to signal wakeup on behalf of their subordinate devices and that may happen for multiple times in a row, whereas for the other devices it only makes sense to enable wakeup signaling once. However, this becomes problematic if the bridge itself is suspended, because it is treated as a "regular" device in that case and the reference counting doesn't work. For instance, suppose that there are two devices below a bridge and they both can signal wakeup. Every time one of them is suspended, wakeup signaling is enabled for the bridge, so when they both have been suspended, the bridge's wakeup reference counter value is 2. Say that the bridge is suspended subsequently and acpi_pci_wakeup() is called for it. Because the bridge can signal wakeup, that function will invoke acpi_pm_set_device_wakeup() to configure it and __acpi_pm_set_device_wakeup() will be called with the last argument equal to 1. This causes __acpi_device_wakeup_enable() invoked by it to omit the reference counting, because the reference counter of the target device (the bridge) is 2 at that time. Now say that the bridge resumes and one of the device below it resumes too, so the bridge's reference counter becomes 0 and wakeup signaling is disabled for it, but there is still the other suspended device which may need the bridge to signal wakeup on its behalf and that is not going to work. To address this scenario, use wakeup enable reference counting for all devices, not just for bridges, so drop the last argument from __acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(), which causes acpi_pm_set_device_wakeup() and acpi_pm_set_bridge_wakeup() to become identical, so drop the latter and use the former instead of it everywhere. Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
|
#
956ad9d9 |
|
04-Jun-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Avoid using power resources if there are none for D0 As recently reported, some platforms provide a list of power resources for device power state D3hot, through the _PR3 object, but they do not provide a list of power resources for device power state D0. Among other things, this causes acpi_device_get_power() to return D3hot as the current state of the device in question if all of the D3hot power resources are "on", because it sees the power_resources flag set and calls acpi_power_get_inferred_state() which finds that D3hot is the shallowest power state with all of the associated power resources turned "on", so that's what it returns. Moreover, that value takes precedence over the acpi_dev_pm_explicit_get() return value, because it means a deeper power state. The device may very well be in D0 physically at that point, however. Moreover, the presence of _PR3 without _PR0 for a given device means that only one D3-level power state can be supported by it. Namely, because there are no power resources to turn "off" when transitioning the device from D0 into D3cold (which should be supported since _PR3 is present), the evaluation of _PS3 should be sufficient to put it straight into D3cold, but this means that the effect of turning "on" the _PR3 power resources is unclear, so it is better to avoid doing that altogether. Consequently, there is no practical way do distinguish D3cold from D3hot for the device in question and the power states of it can be labeled so that D3hot is the deepest supported one (and Linux assumes that putting a device into D3hot via ACPI may cause power to be removed from it anyway, for legacy reasons). To work around the problem described above modify the ACPI enumeration of devices so that power resources are only used for device power management if the list of D0 power resources is not empty and make it mart D3cold as supported only if that is the case and the D3hot list of power resources is not empty too. Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057 Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/ Reported-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: youling257@gmail.com Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
a9b760b0 |
|
21-Apr-2020 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
PM: ACPI: Output correct message on target power state Transitioned power state logged at the end of setting ACPI power. However, D3cold won't be in the message because state can only be D3hot at most. Use target_state to corretly report when power state is D3cold. Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fa2bfead |
|
18-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: core: Rename dev_pm_smart_suspend_and_suspended() Because all callers of dev_pm_smart_suspend_and_suspended use it only for checking whether or not to skip driver suspend callbacks for a device, rename it to dev_pm_skip_suspend() in analogy with dev_pm_skip_resume(). No functional impact. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
76c70cb5 |
|
18-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: core: Rename dev_pm_may_skip_resume() The name of dev_pm_may_skip_resume() may be easily confused with the power.may_skip_resume flag which is not checked by that function, so rename the former as dev_pm_skip_resume(). No functional impact. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0fe8a1be |
|
18-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: core: Rework the power.may_skip_resume handling Because the power.may_skip_resume device status bit is taken into account in combination with the DPM_FLAG_LEAVE_SUSPENDED driver flag, it can be set to 'true' for all devices in the "suspend" phase of a suspend-resume cycle, so do that. Then, neither the PM core nor the middle-layer (sybsystem) code handling it needs to set it to 'true' any more and it just has to be cleared if there is a reason to avoid skipping the "noirq" and "early" resume callbacks provided by the driver, so update the code in question accordingly. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6e176bf8 |
|
18-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: core: Do not skip callbacks in the resume phase The current code in device_resume_noirq() causes the entire early resume and resume phases of device suspend to be skipped for devices for which the noirq resume phase have been skipped (due to the LEAVE_SUSPENDED flag being set) on the premise that those devices should stay in runtime-suspend after system-wide resume. However, that may not be correct in two situations. First, the middle layer (subsystem) noirq resume callback may be missing for a given device, but its early resume callback may be present and it may need to do something even if it decides to skip the driver callback. Second, if the device's wakeup settings were adjusted in the suspend phase without resuming the device (that was in runtime suspend at that time), they most likely need to be adjusted again in the resume phase and so the driver callback in that phase needs to be run. For the above reason, modify the core to allow the middle layer ->resume_late callback to run even if its ->resume_noirq callback is missing (and the core has skipped the driver-level callback in that phase) and to allow all device callbacks to run in the resume phase. Also make the core set the PM-runtime status of devices with SMART_SUSPEND set whose resume callbacks are not skipped to "active" in the "noirq" resume phase and update the affected subsystems (PCI and ACPI) accordingly. After this change, middle-layer (subsystem) callbacks will always be invoked in all phases of system suspend and resume and driver callbacks will always run in the prepare, suspend, resume, and complete phases for all devices. For devices with SMART_SUSPEND set, driver callbacks will be skipped in the late and noirq phases of system suspend if those devices remain in runtime suspend in __device_suspend_late(). Driver callbacks will also be skipped for them during the noirq and early phases of the "thaw" transition related to hibernation in that case. Setting LEAVE_SUSPENDED means that the driver allows its callbacks to be skipped in the noirq and early phases of system resume, but some additional conditions need to be met for that to happen (among other things, the power.may_skip_resume flag needs to be set for the device during system suspend for the driver callbacks to be skipped during the subsequent resume transition). For all devices with SMART_SUSPEND set whose driver callbacks are invoked during system resume, the PM-runtime status will be set to "active" (by the core). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b62c770f |
|
27-Mar-2020 |
Gayatri Kammela <gayatri.kammela@intel.com> |
ACPI: Update Tiger Lake ACPI device IDs Tiger Lake's new unique ACPI device IDs for DPTF and fan drivers are not valid as the IDs are missing 'C'. Fix the IDs by updating them. After the update, the new IDs should now look like INT1047 --> INTC1047 INT1040 --> INTC1040 INT1043 --> INTC1043 INT1044 --> INTC1044 Fixes: 55cfe6a5c582 ("ACPI: DPTF: Add Tiger Lake ACPI device IDs") Fixes: c248dfe7e0ca ("ACPI: fan: Add Tiger Lake ACPI device ID") Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c248dfe7 |
|
16-Dec-2019 |
Gayatri Kammela <gayatri.kammela@intel.com> |
ACPI: fan: Add Tiger Lake ACPI device ID Tiger Lake has a new unique ACPI device ID for the ACPI fan that needs to be added to the fan driver and to the blacklist in acpi_dev_pm_attach() to support it. Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> [ rjw: Subject & changelog, fold in another patch ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b9ea0bae |
|
03-Dec-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Avoid attaching ACPI PM domain to certain devices Certain ACPI-enumerated devices represented as platform devices in Linux, like fans, require special low-level power management handling implemented by their drivers that is not in agreement with the ACPI PM domain behavior. That leads to problems with managing ACPI fans during system-wide suspend and resume. For this reason, make acpi_dev_pm_attach() skip the affected devices by adding a list of device IDs to avoid to it and putting the IDs of the affected devices into that list. Fixes: e5cc8ef31267 (ACPI / PM: Provide ACPI PM callback routines for subsystems) Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c8377adf |
|
06-Aug-2019 |
Tri Vo <trong@android.com> |
PM / wakeup: Show wakeup sources stats in sysfs Add an ID and a device pointer to 'struct wakeup_source'. Use them to to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup<ID>/*. Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tri Vo <trong@android.com> Tested-by: Kalesh Singh <kaleshsingh@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ee8193ee |
|
01-Aug-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Print debug messages on device power state changes Add an acpi_handle_debug() statement to acpi_device_set_power() to allow ACPI device power state changes to be tracked. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
42787ed7 |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Fix regression in acpi_device_set_power() Commit f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in special cases") overlooked the fact that acpi_power_transition() may change the power.state value for the target device and if that happens, it may confuse acpi_device_set_power() and cause it to omit the _PS0 evaluation which on some systems is necessary to change power states of devices from low-power to D0. Fix that by saving the current value of power.state for the target device before passing it to acpi_power_transition() and using the saved value in a subsequent check. Fixes: f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in special cases") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
|
#
9ed411c0 |
|
03-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Unexport acpi_device_get_power() Using acpi_device_get_power() outside of ACPI device initialization and ACPI sysfs is problematic due to the way in which power resources are handled by it, so unexport it and add a paragraph explaining the pitfalls to its kerneldoc comment. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
c95b7595 |
|
30-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Introduce "poweroff" callbacks for ACPI PM domain and LPSS In general, it is not correct to call pm_generic_suspend(), pm_generic_suspend_late() and pm_generic_suspend_noirq() during the hibernation's "poweroff" transition, because device drivers may provide special callbacks to be invoked then and the wrappers in question cause system suspend callbacks to be run. Unfortunately, that happens in the ACPI PM domain and ACPI LPSS. To address this potential issue, introduce "poweroff" callbacks for the ACPI PM and LPSS that will use pm_generic_poweroff(), pm_generic_poweroff_late() and pm_generic_poweroff_noirq() as appropriate. Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
3cd7957e |
|
30-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Simplify and fix PM domain hibernation callbacks First, after a previous change causing all runtime-suspended devices in the ACPI PM domain (and ACPI LPSS devices) to be resumed before creating a snapshot image of memory during hibernation, it is not necessary to worry about the case in which them might be left in runtime-suspend any more, so get rid of the code related to that from ACPI PM domain and ACPI LPSS hibernation callbacks. Second, it is not correct to use pm_generic_resume_early() and acpi_subsys_resume_noirq() in hibernation "restore" callbacks (which currently happens in the ACPI PM domain and ACPI LPSS), so introduce proper _restore_late and _restore_noirq callbacks for the ACPI PM domain and ACPI LPSS. Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
501debd4 |
|
30-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: ACPI/PCI: Resume all devices during hibernation Both the PCI bus type and the ACPI PM domain avoid resuming runtime-suspended devices with DPM_FLAG_SMART_SUSPEND set during hibernation (before creating the snapshot image of system memory), but that turns out to be a mistake. It leads to functional issues and adds complexity that's hard to justify. For this reason, resume all runtime-suspended PCI devices and all devices in the ACPI PM domains before creating a snapshot image of system memory during hibernation. Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Fixes: c4b65157aeef (PCI / PM: Take SMART_SUSPEND driver flag into account) Link: https://lore.kernel.org/linux-acpi/917d4399-2e22-67b1-9d54-808561f9083f@uwyo.edu/T/#maf065fe6e4974f2a9d79f332ab99dfaba635f64c Reported-by: Robert R. Howell <RHowell@uwyo.edu> Tested-by: Robert R. Howell <RHowell@uwyo.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
f850a48a |
|
25-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Allow transitions to D0 to occur in special cases If a device with ACPI PM is left in D0 during a system-wide transition to the S3 (suspend-to-RAM) or S4 (hibernation) sleep state, the actual state of the device need not be D0 during resume from it, although its power.state value will still reflect D0 (that is, the power state from before the system-wide transition). In that case, the acpi_device_set_power() call made to ensure that the power state of the device will be D0 going forward has no effect, because the new state (D0) is equal to the one reflected by the device's power.state value. That does not affect power resources, which are taken care of by acpi_resume_power_resources() called from acpi_pm_finish() during resume from system-wide sleep states, but it still may be necessary to invoke _PS0 for the device on top of that in order to finalize its transition to D0. For this reason, modify acpi_device_set_power() to allow transitions to D0 to occur even if D0 is the current power state of the device according to its power.state value. That will not affect power resources, which are assumed to be in the right configuration already (as reflected by the current values of their reference counters), but it may cause _PS0 to be evaluated for the device. However, evaluating _PS0 for a device already in D0 may lead to confusion in general, so invoke _PSC (if present) to check the device's current power state upfront and only evaluate _PS0 for it if _PSC has returned a power state different from D0. [If _PSC is not present or the evaluation of it fails, the power state of the device is assumed to be D0 at this point.] Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
21ba2379 |
|
25-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Avoid evaluating _PS3 on transitions from D3hot to D3cold If the power state of a device with ACPI PM is changed from D3hot to D3cold, it merely is a matter of dropping references to additional power resources (specifically, those in the list returned by _PR3), and the _PS3 method should not be invoked for the device then (as it has already been evaluated during the previous transition to D3hot). Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
1802d0be |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9a51c6b1 |
|
15-May-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI/PCI: PM: Add missing wakeup.flags.valid checks Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the current ACPI wakeup configuration of the device matches what is expected as far as system wakeup from sleep states is concerned, as reflected by the device_may_wakeup() return value for the device. However, they only should do that if wakeup.flags.valid is set for the device's ACPI companion, because otherwise the wakeup.prepare_count value for it is meaningless. Add the missing wakeup.flags.valid checks to these functions. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
d75f773c |
|
25-Mar-2019 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively %pF and %pf are functionally equivalent to %pS and %ps conversion specifiers. The former are deprecated, therefore switch the current users to use the preferred variant. The changes have been produced by the following command: git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \ while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done And verifying the result. Link: http://lkml.kernel.org/r/20190325193229.23390-1-sakari.ailus@linux.intel.com Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: sparclinux@vger.kernel.org Cc: linux-um@lists.infradead.org Cc: xen-devel@lists.xenproject.org Cc: linux-acpi@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-nvdimm@lists.01.org Cc: linux-pci@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-btrfs@vger.kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net Cc: linux-mm@kvack.org Cc: ceph-devel@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: David Sterba <dsterba@suse.com> (for btrfs) Acked-by: Mike Rapoport <rppt@linux.ibm.com> (for mm/memblock.c) Acked-by: Bjorn Helgaas <bhelgaas@google.com> (for drivers/pci) Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
|
#
fbc9418f |
|
03-Apr-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Print debug messages when enabling GPEs for wakeup In sufficiently complicated GPE configurations it is hard to determine which GPE could be the source of system wakeup from a sleep state, so make __acpi_device_wakeup_enable() print that information to the kernel log if debugging is enabled. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fe650c8b |
|
11-Oct-2018 |
Hans de Goede <hdegoede@redhat.com> |
ACPI / PM: Export acpi_device_get_power() for use by modular build drivers Export acpi_device_get_power() for use by modular build drivers. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
919b7308 |
|
08-May-2018 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM / Domains: Allow a better error handling of dev_pm_domain_attach() The callers of dev_pm_domain_attach() currently checks the returned error code for -EPROBE_DEFER and needs to ignore other error codes. This is an unnecessary limitation, which also leads to a rather strange behaviour in the error path. Address this limitation, by changing the return codes from acpi_dev_pm_attach() and genpd_dev_pm_attach(). More precisely, let them return 0, when no PM domain is needed for the device and then return 1, in case the device was successfully attached to its PM domain. In this way, dev_pm_domain_attach(), gets a better understanding of what happens in the attach attempts and also allowing its caller to better act on real errors codes. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4f688748 |
|
26-Apr-2018 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM / Domains: Check for existing PM domain in dev_pm_domain_attach() Instead of checking if an existing PM domain pointer has been assigned in genpd_dev_pm_attach() and acpi_dev_pm_attach(), move the check to the common path in dev_pm_domain_attach(), thus potentially avoid one unnecessary check. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bf8c6184 |
|
19-Mar-2018 |
Daniel Drake <drake@endlessm.com> |
ACPI / PM: Allow deeper wakeup power states with no _SxD nor _SxW acpi_dev_pm_get_state() is used to determine the range of allowable device power states when going into S3 suspend. This is implemented by executing the _S3D and _S3W ACPI methods. Linux follows the ACPI spec behaviour in that when _S3D is implemented and _S3W is not, Linux will not go into a power state deeper than the one returned by _S3D for a wakeup-enabled device. However, this same logic is being applied to the case when neither _S3D nor _S3W are present, and the result is that this function decides that the device must stay in D0 (fully on) state. This is breaking USB wakeups on Asus V222GA and Acer XC-830. _S3D and _S3W are not present, so the USB controller is left in the D0 running state during S3, and hence it is unable to generate a PME# wake event. The ACPI spec is unclear on which power states are permissable for wakeup-enabled devices when both _S3D and _S3W are missing. However, USB wakeups work fine on these platforms under Windows, where device manager shows that they are using D3 device state for the USB controller in S3. I assume that the "max = min" clamping done by the code here is specifically written for the _S3D but no _S3W case. By making the code true to those conditions, avoiding them on these platforms, the controller will be put into D3 state and USB wakeups start working. Additionally I feel that this change makes the code more directly mirror the wording of the ACPI spec and it's associated lack of clarity. Thanks to Mathias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake <drake@endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=Bv1XhXV_gY3bziOo_NPKA@mail.gmail.com https://phabricator.endlessm.com/T21410 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3487972d |
|
06-Dec-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / sleep: Avoid excess pm_runtime_enable() calls in device_resume() Middle-layer code doing suspend-time optimizations for devices with the DPM_FLAG_SMART_SUSPEND flag set (currently, the PCI bus type and the ACPI PM domain) needs to make the core skip ->thaw_early and ->thaw callbacks for those devices in some cases and it sets the power.direct_complete flag for them for this purpose. However, it turns out that setting power.direct_complete outside of the PM core is a bad idea as it triggers an excess invocation of pm_runtime_enable() in device_resume(). For this reason, provide a helper to clear power.is_late_suspended and power.is_suspended to be invoked by the middle-layer code in question instead of setting power.direct_complete and make that code call the new helper. Fixes: c4b65157aeef (PCI / PM: Take SMART_SUSPEND driver flag into account) Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
db68daff |
|
18-Nov-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Add support for DPM_FLAG_LEAVE_SUSPENDED to the ACPI PM domain by making it (a) set the power.may_skip_resume status bit for devices that, from its perspective, may be left in suspend after system wakeup from sleep and (b) return early from acpi_subsys_resume_noirq() for devices whose remaining resume callbacks during the transition under way are going to be skipped by the PM core. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ff165679 |
|
07-Nov-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock acpi_remove_pm_notifier() ends up calling flush_workqueue() while holding acpi_pm_notifier_lock, and that same lock is taken by by the work via acpi_pm_notify_handler(). This can deadlock. To fix the problem let's split the single lock into two: one to protect the dev->wakeup between the work vs. add/remove, and another one to handle notifier installation vs. removal. After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work() annotation" I was able to kill the machine (Intel Braswell) very easily with 'powertop --auto-tune', runtime suspending i915, and trying to wake it up via the USB keyboard. The cases when it didn't die are presumably explained by lockdep getting disabled by something else (cpu hotplug locking issues usually). Fortunately I still got a lockdep report over netconsole (trickling in very slowly), even though the machine was otherwise practically dead: [ 112.179806] ====================================================== [ 114.670858] WARNING: possible circular locking dependency detected [ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted [ 119.658101] ------------------------------------------------------ [ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command. [ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead [ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up [ 121.313485] usb 1-6: USB disconnect, device number 3 [ 121.313501] usb 1-6.2: USB disconnect, device number 4 [ 134.747383] kworker/0:2/47 is trying to acquire lock: [ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80 [ 139.721524] [ 139.721524] but task is already holding lock: [ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720 [ 147.184450] [ 147.184450] which lock already depends on the new lock. [ 147.184450] [ 154.604711] [ 154.604711] the existing dependency chain (in reverse order) is: [ 159.447888] [ 159.447888] -> #2 ((&dpc->work)){+.+.}: [ 164.183486] __lock_acquire+0x1255/0x13f0 [ 166.504313] lock_acquire+0xb5/0x210 [ 168.778973] process_one_work+0x1b9/0x720 [ 171.030316] worker_thread+0x4c/0x440 [ 173.257184] kthread+0x154/0x190 [ 175.456143] ret_from_fork+0x27/0x40 [ 177.624348] [ 177.624348] -> #1 ("kacpi_notify"){+.+.}: [ 181.850351] __lock_acquire+0x1255/0x13f0 [ 183.941695] lock_acquire+0xb5/0x210 [ 186.046115] flush_workqueue+0xdd/0x510 [ 190.408153] acpi_os_wait_events_complete+0x31/0x40 [ 192.625303] acpi_remove_notify_handler+0x133/0x188 [ 194.820829] acpi_remove_pm_notifier+0x56/0x90 [ 196.989068] acpi_dev_pm_detach+0x5f/0xa0 [ 199.145866] dev_pm_domain_detach+0x27/0x30 [ 201.285614] i2c_device_probe+0x100/0x210 [ 203.411118] driver_probe_device+0x23e/0x310 [ 205.522425] __driver_attach+0xa3/0xb0 [ 207.634268] bus_for_each_dev+0x69/0xa0 [ 209.714797] driver_attach+0x1e/0x20 [ 211.778258] bus_add_driver+0x1bc/0x230 [ 213.837162] driver_register+0x60/0xe0 [ 215.868162] i2c_register_driver+0x42/0x70 [ 217.869551] 0xffffffffa0172017 [ 219.863009] do_one_initcall+0x45/0x170 [ 221.843863] do_init_module+0x5f/0x204 [ 223.817915] load_module+0x225b/0x29b0 [ 225.757234] SyS_finit_module+0xc6/0xd0 [ 227.661851] do_syscall_64+0x5c/0x120 [ 229.536819] return_from_SYSCALL_64+0x0/0x7a [ 231.392444] [ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}: [ 235.124914] check_prev_add+0x44e/0x8a0 [ 237.024795] __lock_acquire+0x1255/0x13f0 [ 238.937351] lock_acquire+0xb5/0x210 [ 240.840799] __mutex_lock+0x75/0x940 [ 242.709517] mutex_lock_nested+0x1c/0x20 [ 244.551478] acpi_pm_notify_handler+0x2f/0x80 [ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c [ 248.194412] acpi_os_execute_deferred+0x14/0x30 [ 250.003925] process_one_work+0x1ec/0x720 [ 251.803191] worker_thread+0x4c/0x440 [ 253.605307] kthread+0x154/0x190 [ 255.387498] ret_from_fork+0x27/0x40 [ 257.153175] [ 257.153175] other info that might help us debug this: [ 257.153175] [ 262.324392] Chain exists of: [ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work) [ 262.324392] [ 267.391997] Possible unsafe locking scenario: [ 267.391997] [ 270.758262] CPU0 CPU1 [ 272.431713] ---- ---- [ 274.060756] lock((&dpc->work)); [ 275.646532] lock("kacpi_notify"); [ 277.260772] lock((&dpc->work)); [ 278.839146] lock(acpi_pm_notifier_lock); [ 280.391902] [ 280.391902] *** DEADLOCK *** [ 280.391902] [ 284.986385] 2 locks held by kworker/0:2/47: [ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720 [ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720 [ 289.727725] Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
05087360 |
|
27-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Take SMART_SUSPEND driver flag into account Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in its system suspend callbacks. [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in acpi_subsys_suspend_late/noirq() and acpi_subsys_freeze_late/noirq(). Moreover, if acpi_subsys_resume_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state going forward, so add a check for that too in there. In turn, if acpi_subsys_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. On top of the above, make the analogous changes in the acpi_lpss driver that uses the ACPI PM domain callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
08810a41 |
|
25-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags The motivation for this change is to provide a way to work around a problem with the direct-complete mechanism used for avoiding system suspend/resume handling for devices in runtime suspend. The problem is that some middle layer code (the PCI bus type and the ACPI PM domain in particular) returns positive values from its system suspend ->prepare callbacks regardless of whether the driver's ->prepare returns a positive value or 0, which effectively prevents drivers from being able to control the direct-complete feature. Some drivers need that control, however, and the PCI bus type has grown its own flag to deal with this issue, but since it is not limited to PCI, it is better to address it by adding driver flags at the core level. To that end, add a driver_flags field to struct dev_pm_info for flags that can be set by device drivers at the probe time to inform the PM core and/or bus types, PM domains and so on on the capabilities and/or preferences of device drivers. Also add two static inline helpers for setting that field and testing it against a given set of flags and make the driver core clear it automatically on driver remove and probe failures. Define and document two PM driver flags related to the direct- complete feature: NEVER_SKIP and SMART_PREPARE that can be used, respectively, to indicate to the PM core that the direct-complete mechanism should never be used for the device and to inform the middle layer code (bus types, PM domains etc) that it can only request the PM core to use the direct-complete mechanism for the device (by returning a positive value from its ->prepare callback) if it also has been requested by the driver. While at it, make the core check pm_runtime_suspended() when setting power.direct_complete so that it doesn't need to be checked by ->prepare callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
cbe25ce3 |
|
14-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Combine device suspend routines On top of a previous change getting rid of the PM QoS flag PM_QOS_FLAG_REMOTE_WAKEUP, combine two ACPI device suspend routines, acpi_dev_runtime_suspend() and acpi_dev_suspend_late(), into one, acpi_dev_suspend(), to eliminate some code duplication. It also avoids enabling wakeup for devices handled by the ACPI LPSS middle layer on driver removal. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
20f97caf |
|
13-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / QoS: Drop PM_QOS_FLAG_REMOTE_WAKEUP The PM QoS flag PM_QOS_FLAG_REMOTE_WAKEUP is not used consistently and the vast majority of code simply assumes that remote wakeup should be enabled for devices in runtime suspend if they can generate wakeup signals, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
c2ebf788 |
|
03-Oct-2017 |
Ulf Hansson <ulf.hansson@linaro.org> |
ACPI / PM: Split code validating need for runtime resume in ->prepare() Move the code dealing with validation of whether runtime resuming the device is needed during system suspend. In this way it becomes more clear for what circumstances ACPI is prevented from trying the direct_complete path. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e4da817d |
|
03-Oct-2017 |
Ulf Hansson <ulf.hansson@linaro.org> |
ACPI / PM: Restore acpi_subsys_complete() Commit 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware), made PCI's and ACPI's ->complete() callbacks to be assigned to a new API called pm_complete_with_resume_check(), which was introduced in the same change. Later it turned out that using pm_complete_with_resume_check() wasn't good enough for PCI, as it needed additional PCI specific checks, before deciding whether runtime resuming the device is needed when running the ->complete() callback. This leaves ACPI as the only user of pm_complete_with_resume_check(). Therefore let's restore ACPI's acpi_subsys_complete(), which was dropped in commit 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware). This enables us to remove the pm_complete_with_resume_check() API in a following change, but it also enables ACPI to add more ACPI specific checks in acpi_subsys_complete() if that turns out to be necessary. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
63705c40 |
|
10-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Combine two identical device resume routines Notice that acpi_dev_runtime_resume() and acpi_dev_resume_early() are actually literally identical after some more-or-less recent changes, so rename acpi_dev_runtime_resume() to acpi_dev_resume(), use it everywhere instead of acpi_dev_resume_early() and drop the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
020a6375 |
|
10-Aug-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Add debug statements to acpi_pm_notify_handler() Add statements to trace invocations of the ACPI PM notify handler and the work functions called by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1ba51a7c |
|
31-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup() The acpi_pci_propagate_wakeup() routine is there to handle cases in which PCI bridges (or PCIe ports) are expected to signal wakeup for devices below them, but currently it doesn't do that correctly. The problem is that acpi_pci_propagate_wakeup() uses acpi_pm_set_device_wakeup() for bridges and if that routine is called for multiple times to disable wakeup for the same device, it will disable it on the first invocation and the next calls will have no effect (it works analogously when called to enable wakeup, but that is not a problem). Now, say acpi_pci_propagate_wakeup() has been called for two different devices under the same bridge and it has called acpi_pm_set_device_wakeup() for that bridge each time. The bridge is now enabled to generate wakeup signals. Next, suppose that one of the devices below it resumes and acpi_pci_propagate_wakeup() is called to disable wakeup for that device. It will then call acpi_pm_set_device_wakeup() for the bridge and that will effectively disable remote wakeup for all devices under it even though some of them may still be suspended and remote wakeup may be expected to work for them. To address this (arguably theoretical) issue, allow wakeup.enable_count under struct acpi_device to grow beyond 1 in certain situations. In particular, allow that to happen in acpi_pci_propagate_wakeup() when wakeup is enabled or disabled for PCI bridges, so that wakeup is actually disabled for the bridge when all devices under it resume and not when just one of them does that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
99d8845e |
|
21-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Split acpi_device_wakeup() To prepare for a subsequent change and make the code somewhat easier to follow, do the following in the ACPI device wakeup handling code: * Replace wakeup.flags.enabled under struct acpi_device with wakeup.enable_count as that will be necessary going forward. For now, wakeup.enable_count is not allowed to grow beyond 1, so the current behavior is retained. * Split acpi_device_wakeup() into acpi_device_wakeup_enable() and acpi_device_wakeup_disable() and modify the callers of it accordingly. * Introduce a new acpi_wakeup_lock mutex to protect the wakeup enabling/disabling code from races in case it is executed more than once in parallel for the same device (which may happen for bridges theoretically). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
8370c2dc |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Drop pme_interrupt flag from struct pci_dev The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which returns as soon as it sees the pme_interrupt flag set while setting up "remote runtime wakeup". That is questionable, however, because in theory there may be PCIe devices using out-of-band PME signaling under root ports handled by the native PME code or devices requiring wakeup power setup to be carried out by AML. For such devices, ACPI wakeup should be invoked regardless of whether or not native PME signaling is used in general. For this reason, drop the pme_interrupt flag and rework the code using it which then allows the ACPI-based device wakeup handling in PCI to be consolidated to use one code path for both "runtime remote wakeup" and system wakeup (from sleep states). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
4d183d04 |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Consolidate device wakeup settings code Currently, there are two separate ways of handling device wakeup settings in the ACPI core, depending on whether this is runtime wakeup or system wakeup (from sleep states). However, after the previous commit eliminating the run_wake ACPI device wakeup flag, there is no difference between the two any more at the ACPI level, so they can be combined. For this reason, introduce acpi_pm_set_device_wakeup() to replace both acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it check the ACPI device object's wakeup.valid flag to determine whether or not the device can be set up to generate wakeup signals. Also notice that zpodd_enable/disable_run_wake() only call device_set_run_wake() because acpi_pm_device_run_wake() called device_run_wake(), which is not done by acpi_pm_set_device_wakeup(), so drop the now redundant device_set_run_wake() calls from there. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
cde1f95f |
|
05-Jun-2017 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
ACPI: Constify argument to acpi_device_is_present() This will be needed in constifying the fwnode API. The side effects the function had have been moved to the callers. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> 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>
|
#
190cab84 |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Change log level of wakeup-related message Change the log level of the "System wakeup enabled/disabled by ACPI" message in acpi_pm_device_sleep_wake() to "debug" to reduce to log noise level. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
64fd1c70 |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Run wakeup notify handlers synchronously The work functions provided by the users of acpi_add_pm_notifier() should be run synchronously before re-enabling the wakeup GPE in case they are used to clear the status and/or disable the wakeup signaling at the source. Otherwise, which is the case currently in the PCI bus type code, the same wakeup event may be signaled for multiple times while the execution of the work function in response to it has already been queued up. Fortunately, acpi_add_pm_notifier() is only used by PCI and by ACPI device PM code internally, so the change is relatively straightforward to make. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.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>
|
#
78a898d0 |
|
19-May-2016 |
Ulf Hansson <ulf.hansson@linaro.org> |
ACPI / PM: Export acpi_device_fix_up_power() Drivers that needs acpi_device_fix_up_power(), allow them to be built as modules by exporting this function. Cc: <stable@vger.kernel.org> # 4.5+ Tested-by: Laszlo Fiat <laszlo.fiat@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
989561de |
|
07-Jan-2016 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
PM / Domains: add setter for dev.pm_domain Adds a function that sets the pointer to dev_pm_domain in struct device and that warns if the device has already finished probing. The reason why we want to enforce that is because in the general case that can cause problems and also that we can simplify code quite a bit if we can always assume that. This patch also changes all current code that directly sets the dev.pm_domain pointer. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
58a1fbbb |
|
06-Oct-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / PCI / ACPI: Kick devices that might have been reset by firmware There is a concern that if the platform firmware was involved in the system resume that's being completed, some devices might have been reset by it and if those devices had the power.direct_complete flag set during the preceding suspend transition, they may stay in a reset-power-on state indefinitely (until they are runtime-resumed and then suspended again). That may not be a big deal from the individual device's perspective, but if the system is an SoC, it may be prevented from entering deep SoC-wide low-power states on idle because of that. The devices that are most likely to be affected by this issue are PCI devices and ACPI-enumerated devices using the general ACPI PM domain, so to prevent it from happening for those devices, force a runtime resume for them if they have their power.direct_complete flags set and the platform firmware was involved in the resume transition currently in progress. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
71b65445 |
|
28-Jul-2015 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / PM: Use target_state to set the device power state Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow ACPI 6") changed the device power management to use D3hot if the device in question does not have _PR3 method even if D3cold was requested by the caller. However, if the device has _PR3 device->power.state is also set to D3hot instead of D3Cold after power resources have been turned off because device->power.state will be assigned from "state" instead of "target_state". Next time the device is transitioned to D0, acpi_power_transition() will find that the current power state of the device is D3hot instead of D3cold which causes it to power down all resources required for the current (wrong) state D3hot. Below is a simplified ASL example of a real touch panel device which triggers the problem: Scope (TPL1) { Name (_PR0, Package (1) { \_SB.PCI0.I2C1.PXTC }) Name (_PR3, Package (1) { \_SB.PCI0.I2C1.PXTC }) ... } In both D0 and D3hot the same power resource is required. However, when acpi_power_transition() turns off power resources required for D3hot (as the device is transitioned to D0) it powers down PXTC which then makes the device to lose its power. Fix this by assigning "target_state" to the device power state instead of "state" that is always D3hot even for devices with valid _PR3. Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
712e960f |
|
27-Jul-2015 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / PM: Attach ACPI power domain only once Some devices, like MFD subdevices, share a single ACPI companion device so that they are able to access their resources and children. However, currently all these subdevices are attached to the ACPI power domain and this might cause that the power methods for the companion device get called more than once. In order to solve this we attach the ACPI power domain only to the first physical device that is bound to the ACPI companion device. In case of MFD devices, this is the parent MFD device itself. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
#
4c62dbbc |
|
26-Jun-2015 |
Jarkko Nikula <jarkko.nikula@linux.intel.com> |
ACPI: Remove FSF mailing addresses There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3d56402d |
|
09-Jun-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Add missing pm_generic_complete() invocation Add missing invocation of pm_generic_complete() to acpi_subsys_complete() to allow ->complete callbacks provided by the drivers of devices using the ACPI PM domain to be executed during system resume. Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
20dacb71 |
|
15-May-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Rework device power management to follow ACPI 6 The ACPI 6 specification has made some changes in the device power management area. In particular: * The D3hot power state is now supposed to be always available (instead of D3cold) and D3cold is only regarded as valid if the _PR3 object is present for the given device. * The required ordering of transitions into power states deeper than D0 is now such that for a transition into state Dx the _PSx method is supposed to be executed first, if present, and the states of the power resources the device depends on are supposed to be changed after that. * It is now explicitly forbidden to transition devices from lower-power (deeper) into higher-power (shallower) power states other than D0. Those changes have been made so the specification reflects the Windows' device power management code that the vast majority of systems using ACPI is validated against. To avoid artificial differences in ACPI device power management between Windows and Linux, modify the ACPI device power management code to follow the new specification. Add comments explaining the code flow in some unclear places. This only may affect some real corner cases in which the OS behavior expected by the firmware is different from the Windows one, but that's quite unlikely. The transition ordering change affects transitions to D1 and D2 which are rarely used (if at all) and into D3hot and D3cold for devices actually having _PR3, but those are likely to be validated against Windows anyway. The other changes may affect code calling acpi_device_get_power() or acpi_device_update_power() where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD (that's why the ACPI fan driver needs to be updated too) and since transitions into ACPI_STATE_D3_HOT may remove power now, it is better to avoid this one in acpi_pm_device_sleep_state() if the "no power off" PM QoS flag is set. The only existing user of acpi_device_can_poweroff() really cares about the case when _PR3 is present, so the change in that function should not cause any problems to happen too. A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT now and the compatibility with older systems should be covered automatically. In any case, if any real problems result from this, it still will be better to follow the Windows' behavior (which now is reflected by the specification too) in general and handle the cases when it doesn't work via quirks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8dcb52cb |
|
08-Feb-2015 |
Andreas Ruprecht <rupran@einserver.de> |
ACPI / PM: Remove unneeded nested #ifdef In commit 5de21bb998b8 ("ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core"), all occurrences of CONFIG_PM_RUNTIME were replaced with CONFIG_PM. This created the following structure of #ifdef blocks in the code: [...] #ifdef CONFIG_PM #ifdef CONFIG_PM /* always on / undead */ #ifdef CONFIG_PM_SLEEP [...] #endif #endif [...] #endif This patch removes the inner "#ifdef CONFIG_PM" block as it will always be enabled when the outer block is enabled. This inconsistency was found using the undertaker-checkpatch tool. Signed-off-by: Andreas Ruprecht <rupran@einserver.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1b1f3e16 |
|
01-Jan-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix PM initialization for devices that are not present If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
|
#
175f8e26 |
|
12-Dec-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Do not disable wakeup GPEs that have not been enabled In some cases acpi_device_wakeup() may be called to ensure wakeup power to be off for a given device even though that device's wakeup GPE has not been enabled so far. It calls acpi_disable_gpe() on a GPE that's not enabled and this causes ACPICA to return the AE_LIMIT status code from that call which then is reported as an error by the ACPICA's debug facilities (if enabled). This may lead to a fair amount of confusion, so introduce a new ACPI device wakeup flag to store the wakeup GPE status and avoid disabling wakeup GPEs that have not been enabled. Reported-and-tested-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5de21bb9 |
|
27-Nov-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM in the ACPI core code. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
75f9c293 |
|
24-Nov-2014 |
Huang Rui <ray.huang@amd.com> |
ACPI / PM: Fixed a typo in a comment Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
78579b7c |
|
18-Nov-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up As reported by Dmitry, on some Chromebooks there are devices with corresponding ACPI objects and with unusual system wakeup configuration. Namely, they technically are wakeup-capable, but the wakeup is handled via a platform-specific out-of-band mechanism and the ACPI PM layer has no information on the wakeup capability. As a result, device_may_wakeup(dev) called from acpi_dev_suspend_late() returns 'true' for those devices, but the wakeup.flags.valid flag is unset for the corresponding ACPI device objects, so acpi_device_wakeup() reproducibly fails for them causing acpi_dev_suspend_late() to return an error code. The entire system suspend is then aborted and the machines in question cannot suspend at all. Address the problem by ignoring the device_may_wakeup(dev) return value in acpi_dev_suspend_late() if the ACPI companion of the device being handled has wakeup.flags.valid unset (in which case it is clear that the wakeup is supposed to be handled by other means). This fixes a regression introduced by commit a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) as the affected systems could suspend and resume successfully before that commit. Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) Reported-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
67598a1d |
|
23-Oct-2014 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: invoke acpi_device_wakeup() with correct parameters Fix a bug that invokes acpi_device_wakeup() with wrong parameters. Fixes: f35cec255557 (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup) Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2bb3a2bf |
|
19-Nov-2013 |
Aaron Lu <aaron.lu@intel.com> |
ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant When we have the acpi_device pointer, there is no need to pass the device's handle to the acpi_bus_xxx_power functions to get/set/update the device's power state, instead, use the acpi_device_xxx_power functions directly. To make this happen for fan module, export acpi_device_update_power. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
#
91d66cd2 |
|
19-Sep-2014 |
Ulf Hansson <ulf.hansson@linaro.org> |
ACPI / PM: Convert acpi_dev_pm_detach() into a static function The ->detach() callback for the PM domain has now been fully adopted, thus there no users left of the acpi_dev_pm_detach() API. This allow us to convert it into a static function. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
86f1e15f |
|
19-Sep-2014 |
Ulf Hansson <ulf.hansson@linaro.org> |
ACPI / PM: Assign the ->detach() callback when attaching the PM domain As as preparation to simplify the detachment of devices from their PM domains, we assign the ->detach() callback to genpd_dev_pm_detach(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
17653a3e |
|
22-Jul-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Use ACPI_COMPANION() instead of ACPI_HANDLE() The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to return the handle of the device's ACPI companion, so it is much more straightforward and efficient to use ACPI_COMPANION() directly to obtain the device's ACPI companion object instead of using ACPI_HANDLE() and acpi_bus_get_device() on the returned handle for the same thing. Do that in three places in the ACPI device PM code. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f35cec25 |
|
22-Jul-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Always enable wakeup GPEs when enabling device wakeup Wakeup GPEs are currently only enabled when setting up devices for remote wakeup at run time. During system-wide transitions they are enabled by ACPICA at the very last stage of suspend (before asking the BIOS to take over). Of course, that only works for system sleep states supported by ACPI, so in particular it doesn't work for the "freeze" sleep state. For this reason, modify the ACPI core device PM code to enable wakeup GPEs for devices when setting them up for wakeup regardless of whether that is remote wakeup at runtime or system wakeup. That allows the same device wakeup setup routine to be used for both runtime PM and system-wide PM and makes it possible to reduce code size quite a bit. This make ACPI-based PCI Wake-on-LAN work with the "freeze" sleep state on my venerable Toshiba Portege R500 and should help other systems too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c072530f |
|
22-Jul-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Revork the handling of ACPI device wakeup notifications Since ACPI wakeup GPEs are going to be enabled during system suspend as well as for runtime wakeup by a subsequent patch and the same notify handlers will be used in both cases, rework the ACPI device wakeup notification framework so that the part specific to physical devices is always run asynchronously from the PM workqueue. This prevents runtime resume callbacks for those devices from being run during system suspend and resume which may not be appropriate, among other things. Also make ACPI device wakeup notification handling a bit more robust agaist subsequent removal of ACPI device objects, whould that ever happen, and create a wakeup source object for each ACPI device configured for wakeup so that wakeup notifications for those devices can wake up the system from the "freeze" sleep state. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4cf563c5 |
|
15-May-2014 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
ACPI / PM: Export rest of the subsys PM callbacks No reason for excluding the remaining ones. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Rebased and exported the new acpi_subsys_complete() too.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f25c0ae2 |
|
16-May-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend Rework the ACPI PM domain's PM callbacks to avoid resuming devices during system suspend (in order to modify their wakeup settings etc.) if that isn't necessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
92858c47 |
|
25-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Resume runtime-suspended devices later during system suspend Runtime-suspended devices are resumed during system suspend by acpi_subsys_prepare() for two reasons: First, because they may need to be reprogrammed in order to change their wakeup settings and, second, because they may need to be operatonal for their children to be successfully suspended. That is a problem, though, if there are many runtime-suspended devices that need to be resumed this way during system suspend, because the .prepare() PM callbacks of devices are executed sequentially and the times taken by them accumulate, which may increase the total system suspend time quite a bit. For this reason, move the resume of runtime-suspended devices up to the next phase of device suspend (during system suspend), except for the ones that have power.ignore_children set. The exception is made, because the devices with power.ignore_children set may still be necessary for their children to be successfully suspended (during system suspend) and they won't be resumed automatically as a result of the runtime resume of their children. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
79c0373f |
|
27-Jan-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices The ACPI device PM code in device_pm.c uses a special function, acpi_dev_pm_get_node(), to obtain an ACPI companion object of a given device. However, that is not necessary any more after recent changes that introduced the ACPI_COMPANION() macro serving exactly the same purpose, but working in a much more straightforward way. For this reason, drop acpi_dev_pm_get_node() and use ACPI_COMPANION() instead of it everywhere. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
202317a5 |
|
22-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / scan: Add acpi_device objects for all device nodes in the namespace Modify the ACPI namespace scanning code to register a struct acpi_device object for every namespace node representing a device, processor and so on, even if the device represented by that namespace node is reported to be not present and not functional by _STA. There are multiple reasons to do that. First of all, it avoids quite a lot of overhead when struct acpi_device objects are deleted every time acpi_bus_trim() is run and then added again by a subsequent acpi_bus_scan() for the same scope, although the namespace objects they correspond to stay in memory all the time (which always is the case on a vast majority of systems). Second, it will allow user space to see that there are namespace nodes representing devices that are not present at the moment and may be added to the system. It will also allow user space to evaluate _SUN for those nodes to check what physical slots the "missing" devices may be put into and it will make sense to add a sysfs attribute for _STA evaluation after this change (that will be useful for thermal management on some systems). Next, it will help to consolidate the ACPI hotplug handling among subsystems by making it possible to store hotplug-related information in struct acpi_device objects in a standard common way. Finally, it will help to avoid a race condition related to the deletion of ACPI namespace nodes. Namely, namespace nodes may be deleted as a result of a table unload triggered by _EJ0 or _DCK. If a hotplug notification for one of those nodes is triggered right before the deletion and it executes a hotplug callback via acpi_hotplug_execute(), the ACPI handle passed to that callback may be stale when the callback actually runs. One way to work around that is to always pass struct acpi_device pointers to hotplug callbacks after doing a get_device() on the objects in question which eliminates the use-after-free possibility (the ACPI handles in those objects are invalidated by acpi_scan_drop_device(), so they will trigger ACPICA errors on attempts to use them). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
3a83f992 |
|
14-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro Since DEVICE_ACPI_HANDLE() is now literally identical to ACPI_HANDLE(), replace it with the latter everywhere and drop its definition from include/acpi.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7b199811 |
|
11-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node Modify struct acpi_dev_node to contain a pointer to struct acpi_device associated with the given device object (that is, its ACPI companion device) instead of an ACPI handle corresponding to it. Introduce two new macros for manipulating that pointer in a CONFIG_ACPI-safe way, ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the ACPI_HANDLE() macro to take the above changes into account. Drop the ACPI_HANDLE_SET() macro entirely and rework its users to use ACPI_COMPANION_SET() instead. For some of them who used to pass the result of acpi_get_child() directly to ACPI_HANDLE_SET() introduce a helper routine acpi_preset_companion() doing an equivalent thing. The main motivation for doing this is that there are things represented by struct acpi_device objects that don't have valid ACPI handles (so called fixed ACPI hardware features, such as power and sleep buttons) and we would like to create platform device objects for them and "glue" them to their ACPI companions in the usual way (which currently is impossible due to the lack of valid ACPI handles). However, there are more reasons why it may be useful. First, struct acpi_device pointers allow of much better type checking than void pointers which are ACPI handles, so it should be more difficult to write buggy code using modified struct acpi_dev_node and the new macros. Second, the change should help to reduce (over time) the number of places in which the result of ACPI_HANDLE() is passed to acpi_bus_get_device() in order to obtain a pointer to the struct acpi_device associated with the given "physical" device, because now that pointer is returned by ACPI_COMPANION() directly. Finally, the change should make it easier to write generic code that will build both for CONFIG_ACPI set and unset without adding explicit compiler directives to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
|
#
2421ad48 |
|
17-Oct-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Drop two functions that are not used any more Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
644f17ad |
|
10-Oct-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / PM: allow child devices to ignore parent power state Some serial buses like I2C and SPI don't require that the parent device is in D0 before any of its children transitions to D0, but instead the parent device can control its own power independently from the children. This does not follow the ACPI specification as it requires the parent to be powered on before its children. However, Windows seems to ignore this requirement so I think we can do the same in Linux. Implement this by adding a new power flag 'ignore_parent' to struct acpi_device. If this flag is set the ACPI core ignores checking of the parent device power state when the device is powered on/off. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
593298e6 |
|
03-Aug-2013 |
Aaron Lu <aaron.lu@intel.com> |
ACPI / PM: Add state information to error message in acpi_device_set_power() The state information can be useful to know what the problem is when an error message about a device can not being set to a higher power state than its parent appeared, so this patch adds such state information for both the target state of the device and the current state of its parent. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7b4e0c4a |
|
31-Jul-2013 |
Aaron Lu <aaron.lu@intel.com> |
ACPI / PM: Remove redundant power manageable check from acpi_bus_set_power() Now that acpi_device_set_power() checks whether or not the given device is power manageable, it is not necessary to do this check in acpi_bus_set_power() any more, so remove it. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b69137a7 |
|
30-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Make messages in acpi_device_set_power() print device names Modify acpi_device_set_power() so that diagnostic messages printed by it to the kernel log always contain the name of the device concerned to make it possible to identify the device that triggered the message if need be. Also replace printk(KERN_WARNING ) with dev_warn() everywhere in that function. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
|
#
2c7d132a |
|
30-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Only set power states of devices that are power manageable Make acpi_device_set_power() check if the given device is power manageable before checking if the given power state is valid for that device. Otherwise it will print that "Device does not support" that power state into the kernel log, which may not make sense for some power states (D0 and D3cold are supported by all devices by definition). Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
91bdad0b |
|
04-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix corner case in acpi_bus_update_power() The role of acpi_bus_update_power() is to update the given ACPI device object's power.state field to reflect the current physical state of the device (as inferred from the configuration of power resources and _PSC, if available). For this purpose it calls acpi_device_set_power() that should update the power resources' reference counters and set power.state as appropriate. However, that doesn't work if the "new" state is D1, D2 or D3hot and the the current value of power.state means D3cold, because in that case acpi_device_set_power() will refuse to transition the device from D3cold to non-D0. To address this problem, make acpi_bus_update_power() call acpi_power_transition() directly to update the power resources' reference counters and only use acpi_device_set_power() to put the device into D0 if the current physical state of it cannot be determined. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
|
#
9b5c7a5a |
|
27-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state() After commit fa1675b (ACPI / PM: Rework and clean up acpi_dev_pm_get_state()) a NULL pointer dereference will take place if NULL is passed to acpi_pm_device_sleep_state() as the second argument. Fix that by avoiding to use the pointer that may be NULL until it's necessary to store a return value at the location pointed to by it (if not NULL). Reported-and-tested-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b9e95fc6 |
|
18-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / LPSS: Power up LPSS devices during enumeration Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fa1675b5 |
|
15-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Rework and clean up acpi_dev_pm_get_state() The acpi_dev_pm_get_state() function defined in device_pm.c is quite convoluted, which isn't really necessary, and it doesn't validate the values returned by the ACPI methods executed by it appropriately. To address these shortcomings modify it in the following way. (1) Make its return value only mean whether or not it succeeded and pass the device power states determined by it through pointers. (2) Drop the d_max_in argument, used by only one of its callers, from it, and move the code related to d_max_in into that caller, acpi_pm_device_sleep_state(). (3) Make it always check the return value of acpi_evaluate_integer() and handle failures as appropriate. Moreover, make it check if the values returned by the executed ACPI methods are not out of range. (4) Make it check if the values returned by the executed ACPI methods represent valid power states of the given device and handle situations in which that's not the case gracefully. Also update the kerneldoc comments of acpi_dev_pm_get_state() and acpi_pm_device_sleep_state() to reflect the code changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4c164ae7 |
|
15-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.c The two symbols ACPI_STATE_D3 and ACPI_STATE_D3_COLD actually represent the same number (4), but ACPI_STATE_D3 is slightly ambigugous, because it may not be clear that it really means D3cold and not D3hot at first sight. Remove that ambiguity from drivers/acpi/device_pm.c by making it use ACPI_STATE_D3_COLD everywhere instead of ACPI_STATE_D3. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b25c77ef |
|
15-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Rename function acpi_device_power_state() and make it static There is a name clash between function acpi_device_power_state() defined in drivers/acpi/device_pm.c and structure type acpi_device_power_state defined in include/acpi/acpi_bus.h, which may be resolved by renaming the function. Additionally, that funtion may be made static, because it is not used anywhere outside of the file it is defined in. Rename acpi_device_power_state() to acpi_dev_pm_get_state(), which better reflects its purpose, and make it static. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7cd8407d |
|
05-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com> Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
45f0a85c |
|
03-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / Runtime: Rework the "runtime idle" helper routine The "runtime idle" helper routine, rpm_idle(), currently ignores return values from .runtime_idle() callbacks executed by it. However, it turns out that many subsystems use pm_generic_runtime_idle() which checks the return value of the driver's callback and executes pm_runtime_suspend() for the device unless that value is not 0. If that logic is moved to rpm_idle() instead, pm_generic_runtime_idle() can be dropped and its users will not need any .runtime_idle() callbacks any more. Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and ata_port_runtime_idle(), respectively, as well as a few drivers' ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has been returned by the .runtime_idle() callback executed by it. To reduce overall code bloat, make the changes described above. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Kevin Hilman <khilman@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu>
|
#
ec4602a9 |
|
16-May-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Allow device power states to be used for CONFIG_PM unset Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of the functions defined in there are replaced with static inline stubs if that option is unset. However, CONFIG_PM means, roughly, "runtime PM or suspend/hibernation support" and some of those functions are useful regardless of that. For example, they are used by the ACPI fan driver for controlling fans and acpi_device_set_power() is called during device removal. Moreover, device initialization may depend on setting device power states properly. For these reasons, make the routines manipulating ACPI device power states defined in drivers/acpi/device_pm.c available for CONFIG_PM unset too. Reported-by: Zhang Rui <rui.zhang@intel.com> Reported-and-tested-by: Michel Lespinasse <walken@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
|
#
75eb2d13 |
|
24-Mar-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix potential problem in acpi_device_get_power() Theoretically, in some situations acpi_device_get_power() may return an incorrect result, because the settings of the power resources depended on by the device may indicate a power state shallower than the actual power state of the device. Say that two devices, A and B, depend on two power resources, X and Y, in such a way that _PR0 for both A and B list both X and Y and _PR3 for both A and B list power resource Y alone. Also suppose that _PS0 and _PS3 are present for both A and B. Then, if devices A and B are initially in D0, power resources X and Y are initially "on" and their reference counters are equal to 2. To put device A into power state D3hot the kernel will decrement the reference counter of power resource X, but that power resource won't be turned off, because it is still in use by device B (its reference counter is equal to 1). Next, _PS3 will be executed for device A. Afterward the configuration of the power resources will indicate that device A is in power state D0 (both X and Y are "on"), but in fact it is in D3hot (because _PS3 has been executed for it). In that situation, if acpi_device_get_power() is called to get the power state of device A, it will first execute _PSC for it which should return 3. That will cause acpi_device_get_power() to run acpi_power_get_inferred_state() for device A and the resultant power state will be D0, which is incorrect. To fix that change acpi_device_get_power() to first execute acpi_power_get_inferred_state() for the given device (if it depends on power resources) and to evaluate _PSC for it subsequently, so that the result inferred from the power resources configuration can be amended by the _PSC return value. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
|
#
511d5c42 |
|
03-Feb-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Handle missing _PSC in acpi_bus_update_power() If _PS0 is defined for an ACPI device node, but _PSC isn't and the device node doesn't use power resources for power management, acpi_bus_update_power() will fail to update the power state of it, because acpi_device_get_power() returns ACPI_STATE_UNKNOWN in that case. To handle that situation make acpi_bus_update_power() follow acpi_bus_init_power() and try to force the given device node into power state D0. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b3785492 |
|
01-Feb-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Do not power manage devices in unknown initial states In general, for ACPI device power management to work, the initial power states of devices must be known (otherwise, we wouldn't be able to keep track of power resources, for example). Hence, if it is impossible to determine the initial ACPI power states of some devices, they can't be regarded as power-manageable using ACPI. For this reason, modify acpi_bus_get_power_flags() to clear the power_manageable flag if acpi_bus_init_power() fails and add some extra fallback code to acpi_bus_init_power() to cover broken BIOSes that provide _PS0/_PS3 without _PSC for some devices. Verified to work on my HP nx6325 that has this problem. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Peter Wu <lekensteyn@gmail.com>
|
#
dde3bb41 |
|
30-Jan-2013 |
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> |
ACPI / PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e5656271 |
|
21-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Fix device power state value after transitions to D3cold When a transition to the D3cold power state is requested, acpi_device_set_power() first carries out a transition to D3hot and then turns off the device's power resources. However, it fails to update the device's power.state field appropriately and D3hot is stored in it as a result. Fix this, but make sure that the device's power state will be D3hot if its power resources cannot be turned off in the final step. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
898fee4f |
|
21-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Use string "D3cold" to represent ACPI_STATE_D3_COLD Make acpi_power_state_string() return "D3cold" as the string representation of ACPI power state D3cold instead of "D3" returned currently, which is confusing. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e78adb75 |
|
21-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Always evaluate _PSn after setting power resources The ACPI specitication (ACPI 5, Sections 7.2.8 - 7.2.11) requires that the _PSn (n = 0..3) method, if present, be executed after the power resources for the given device power state have been set appropriately. However, acpi_device_set_power() does that only if the new power state is going to be higher-power (lower-number) than the power state the device is in already. Otherwise, the ordering is reverse to protect against situations in which _PSn might access device registers unavailable after configuring the power resources for power state Dn (D3 meaning D3hot). Such situations are very unlikely to happen, though, and _PSn may actually be implemented with the assumption that power resources have been configured for power state Dn in advance, so change the code to follow the specification literally. This change was previously porposed in a different form by Lv Zheng. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9c0f45e3 |
|
21-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Introduce helper for executing _PSn methods To reduce code duplication between acpi_device_set_power() and acpi_bus_init_power(), introduce a new helper function for executing ACPI devices' _PSn (n = 0..3) methods, acpi_dev_pm_explicit_set(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a2367807 |
|
21-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Make acpi_bus_init_power() more robust The ACPI specification requires the _PSC method to be present under a device object if its power state cannot be inferred from the states of power resources used by it (ACPI 5, Section 7.6.2). However, it also requires that (for power states D0-D2 and D3hot) if the _PSn (n = 0, 1, 2, 3) method is present under the device object, it also must be executed after the power resources have been set appropriately for the device to go into power state Dn (D3 means D3hot in this case). Thus it is not clear from the specification whether or not the _PSn method should be executed if the initial configuraion of power resources used by the device indicates power state Dn and the _PSC method is not present. The current implementation of acpi_bus_init_power() is based on the assumption that it should not be necessary to execute _PSn in the above situation, but experience shows that in fact that assumption need not be satisfied. For this reason, make acpi_bus_init_power() always execute _PSn if the initial configuration of device power resources indicates power state Dn. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4d56410b |
|
14-Jan-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / PM: remove leading whitespace from #ifdef It is there probably due to an accident, get rid of it so that the format is consistent across the file. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9ce4e607 |
|
17-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Move device power management functions to device_pm.c Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bc9b6407 |
|
17-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Rework the handling of devices depending on power resources Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5cc36c72 |
|
16-Dec-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Do not apply ACPI_SUCCESS() to acpi_bus_get_device() result Since the return value of acpi_bus_get_device() is not of type acpi_status, ACPI_SUCCESS() should not be used for checking its return value. Fix that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
d2e5f0c1 |
|
22-Dec-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PCI: Rework the setup and cleanup of device wakeup Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
b88ce2a4 |
|
26-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Allow attach/detach routines to change device power states Make it possible to ask the routines used for adding/removing devices to/from the general ACPI PM domain, acpi_dev_pm_attach() and acpi_dev_pm_detach(), respectively, to change the power states of devices so that they are put into the full-power state automatically by acpi_dev_pm_attach() and into the lowest-power state available automatically by acpi_dev_pm_detach(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
e5cc8ef3 |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Provide ACPI PM callback routines for subsystems Some bus types don't support power management natively, but generally there may be device nodes in ACPI tables corresponding to the devices whose bus types they are (under ACPI 5 those bus types may be SPI, I2C and platform). If that is the case, standard ACPI power management may be applied to those devices, although currently the kernel has no means for that. For this reason, provide a set of routines that may be used as power management callbacks for such devices. This may be done in three different ways. (1) Device drivers handling the devices in question may run acpi_dev_pm_attach() in their .probe() routines, which (on success) will cause the devices to be added to the general ACPI PM domain and ACPI power management will be used for them going forward. Then, acpi_dev_pm_detach() may be used to remove the devices from the general ACPI PM domain if ACPI power management is not necessary for them any more. (2) The devices' subsystems may use acpi_subsys_runtime_suspend(), acpi_subsys_runtime_resume(), acpi_subsys_prepare(), acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their power management callbacks in the same way as the general ACPI PM domain does that. (3) The devices' drivers may execute acpi_dev_suspend_late(), acpi_dev_resume_early(), acpi_dev_runtime_suspend(), acpi_dev_runtime_resume() from their power management callbacks as appropriate, if that's absolutely necessary, but it is not recommended to do that, because such drivers may not work without ACPI support as a result. 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>
|
#
ec2cd81c |
|
01-Nov-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Move routines for adding/removing device wakeup notifiers ACPI routines for adding and removing device wakeup notifiers are currently defined in a PCI-specific file, but they will be necessary for non-PCI devices too, so move them to a separate file under drivers/acpi and rename them to indicate their ACPI origins. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|