2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-19 10:44:14 +08:00
Commit Graph

8 Commits

Author SHA1 Message Date
Rafael J. Wysocki
5cc36c724e 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>
2013-01-03 13:10:21 +01:00
Rafael J. Wysocki
b88ce2a415 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>
2012-11-26 10:03:06 +01:00
Rafael J. Wysocki
e5cc8ef312 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>
2012-11-15 00:15:18 +01:00
Rafael J. Wysocki
a6ae7594b1 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>
2012-11-15 00:15:18 +01:00
Rafael J. Wysocki
dee8370cc8 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>
2012-11-15 00:15:17 +01:00
Rafael J. Wysocki
cd7bd02d31 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>
2012-11-15 00:15:17 +01:00
Rafael J. Wysocki
86b3832c64 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>
2012-11-15 00:15:16 +01:00
Rafael J. Wysocki
ec2cd81ccf 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>
2012-11-15 00:15:16 +01:00