2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* acpi_power.c - ACPI Bus Power Management ($Revision: 39 $)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or (at
|
|
|
|
* your option) any later version.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ACPI power-managed devices may be controlled in two ways:
|
|
|
|
* 1. via "Device Specific (D-State) Control"
|
|
|
|
* 2. via "Power Resource Control".
|
|
|
|
* This module is used to manage devices relying on Power Resource Control.
|
|
|
|
*
|
|
|
|
* An ACPI "power resource object" describes a software controllable power
|
|
|
|
* plane, clock plane, or other resource used by a power managed device.
|
|
|
|
* A device may rely on multiple power resources, and a power resource
|
|
|
|
* may be shared by multiple devices.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/types.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 02:04:11 -06:00
|
|
|
#include <linux/slab.h>
|
2012-03-29 00:09:39 -06:00
|
|
|
#include <linux/pm_runtime.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <acpi/acpi_bus.h>
|
|
|
|
#include <acpi/acpi_drivers.h>
|
2009-09-08 15:15:31 -06:00
|
|
|
#include "sleep.h"
|
2012-03-29 00:09:39 -06:00
|
|
|
#include "internal.h"
|
2009-09-08 15:15:31 -06:00
|
|
|
|
2009-07-28 14:45:54 -06:00
|
|
|
#define PREFIX "ACPI: "
|
|
|
|
|
2008-11-07 16:57:45 -07:00
|
|
|
#define _COMPONENT ACPI_POWER_COMPONENT
|
2007-02-12 20:42:12 -07:00
|
|
|
ACPI_MODULE_NAME("power");
|
2005-04-16 16:20:36 -06:00
|
|
|
#define ACPI_POWER_CLASS "power_resource"
|
|
|
|
#define ACPI_POWER_DEVICE_NAME "Power Resource"
|
|
|
|
#define ACPI_POWER_FILE_INFO "info"
|
|
|
|
#define ACPI_POWER_FILE_STATUS "state"
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_OFF 0x00
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_ON 0x01
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_UNKNOWN 0xFF
|
2008-08-11 00:57:50 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_dependent_device {
|
|
|
|
struct list_head node;
|
|
|
|
struct acpi_device *adev;
|
|
|
|
struct work_struct work;
|
2012-03-29 00:09:39 -06:00
|
|
|
};
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
struct acpi_power_resource {
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_device device;
|
2013-01-17 06:11:06 -07:00
|
|
|
struct list_head list_node;
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
struct list_head dependent;
|
2013-01-17 06:11:05 -07:00
|
|
|
char *name;
|
2005-08-04 22:44:28 -06:00
|
|
|
u32 system_level;
|
|
|
|
u32 order;
|
2010-10-21 18:35:54 -06:00
|
|
|
unsigned int ref_count;
|
2007-02-15 23:47:06 -07:00
|
|
|
struct mutex resource_lock;
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
static LIST_HEAD(acpi_power_resource_list);
|
|
|
|
static DEFINE_MUTEX(power_resource_list_lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Power Resource Management
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
static struct acpi_power_resource *acpi_power_get_context(acpi_handle handle)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_device *device;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return NULL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
return container_of(device, struct acpi_power_resource, device);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
static int acpi_power_get_state(acpi_handle handle, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
acpi_status status = AE_OK;
|
2008-10-10 00:22:59 -06:00
|
|
|
unsigned long long sta = 0;
|
2008-12-16 02:02:22 -07:00
|
|
|
char node_name[5];
|
|
|
|
struct acpi_buffer buffer = { sizeof(node_name), node_name };
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
if (!handle || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (ACPI_FAILURE(status))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-10-22 04:19:09 -06:00
|
|
|
*state = (sta & 0x01)?ACPI_POWER_RESOURCE_STATE_ON:
|
|
|
|
ACPI_POWER_RESOURCE_STATE_OFF;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-12-16 02:02:22 -07:00
|
|
|
acpi_get_name(handle, ACPI_SINGLE_NAME, &buffer);
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Resource [%s] is %s\n",
|
2008-12-16 02:02:22 -07:00
|
|
|
node_name,
|
2008-10-27 02:04:53 -06:00
|
|
|
*state ? "on" : "off"));
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
static int acpi_power_get_list_state(struct acpi_handle_list *list, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2011-01-06 15:38:57 -07:00
|
|
|
int cur_state;
|
|
|
|
int i = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!list || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* The state of the list is 'on' IFF all resources are 'on'. */
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
for (i = 0; i < list->count; i++) {
|
2011-01-06 15:38:57 -07:00
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
acpi_handle handle = list->handles[i];
|
|
|
|
int result;
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
resource = acpi_power_get_context(handle);
|
|
|
|
if (!resource)
|
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-01-06 15:38:57 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
|
|
|
result = acpi_power_get_state(handle, &cur_state);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-01-06 15:38:57 -07:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
if (cur_state != ACPI_POWER_RESOURCE_STATE_ON)
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Resource list is %s\n",
|
2011-01-06 15:38:57 -07:00
|
|
|
cur_state ? "on" : "off"));
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-01-06 15:38:57 -07:00
|
|
|
*state = cur_state;
|
|
|
|
|
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
static void acpi_power_resume_dependent(struct work_struct *work)
|
2012-03-29 00:09:39 -06:00
|
|
|
{
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_dependent_device *dep;
|
|
|
|
struct acpi_device_physical_node *pn;
|
|
|
|
struct acpi_device *adev;
|
2012-03-29 00:09:39 -06:00
|
|
|
int state;
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
dep = container_of(work, struct acpi_power_dependent_device, work);
|
|
|
|
adev = dep->adev;
|
|
|
|
if (acpi_power_get_inferred_state(adev, &state))
|
2012-03-29 00:09:39 -06:00
|
|
|
return;
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
if (state > ACPI_STATE_D0)
|
2012-03-29 00:09:39 -06:00
|
|
|
return;
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
mutex_lock(&adev->physical_node_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(pn, &adev->physical_node_list, node)
|
|
|
|
pm_request_resume(pn->dev);
|
|
|
|
|
|
|
|
list_for_each_entry(pn, &adev->power_dependent, node)
|
|
|
|
pm_request_resume(pn->dev);
|
|
|
|
|
|
|
|
mutex_unlock(&adev->physical_node_lock);
|
2012-03-29 00:09:39 -06:00
|
|
|
}
|
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
static int __acpi_power_on(struct acpi_power_resource *resource)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
acpi_status status = AE_OK;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_ON", NULL, NULL);
|
2010-10-21 18:35:54 -06:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
/* Update the power resource's _device_ power state */
|
2013-01-17 06:11:05 -07:00
|
|
|
resource->device.power.state = ACPI_STATE_D0;
|
2010-10-21 18:35:54 -06:00
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Power resource [%s] turned on\n",
|
|
|
|
resource->name));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_power_on(acpi_handle handle)
|
|
|
|
{
|
|
|
|
int result = 0;
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_resource *resource;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
resource = acpi_power_get_context(handle);
|
|
|
|
if (!resource)
|
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-02-15 23:47:06 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
if (resource->ref_count++) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Power resource [%s] already on",
|
|
|
|
resource->name));
|
|
|
|
} else {
|
|
|
|
result = __acpi_power_on(resource);
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
if (result) {
|
2010-11-24 16:03:32 -07:00
|
|
|
resource->ref_count--;
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
} else {
|
|
|
|
struct acpi_power_dependent_device *dep;
|
2012-09-13 16:26:33 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
list_for_each_entry(dep, &resource->dependent, node)
|
|
|
|
schedule_work(&dep->work);
|
|
|
|
}
|
2012-09-13 16:26:33 -06:00
|
|
|
}
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
2012-09-13 16:26:33 -06:00
|
|
|
|
2010-11-24 16:03:32 -07:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2011-01-06 15:38:04 -07:00
|
|
|
static int acpi_power_off(acpi_handle handle)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-05-21 17:28:53 -06:00
|
|
|
int result = 0;
|
2005-08-04 22:44:28 -06:00
|
|
|
acpi_status status = AE_OK;
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_resource *resource;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
resource = acpi_power_get_context(handle);
|
|
|
|
if (!resource)
|
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-02-15 23:47:06 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2010-10-21 18:35:54 -06:00
|
|
|
|
|
|
|
if (!resource->ref_count) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Power resource [%s] already off",
|
|
|
|
resource->name));
|
|
|
|
goto unlock;
|
2007-02-15 23:47:06 -07:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
if (--resource->ref_count) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Power resource [%s] still in use\n",
|
|
|
|
resource->name));
|
|
|
|
goto unlock;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_OFF", NULL, NULL);
|
2010-10-21 18:35:54 -06:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
result = -ENODEV;
|
|
|
|
} else {
|
|
|
|
/* Update the power resource's _device_ power state */
|
2013-01-17 06:11:05 -07:00
|
|
|
resource->device.power.state = ACPI_STATE_D3;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Power resource [%s] turned off\n",
|
|
|
|
resource->name));
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
unlock:
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-11-24 16:06:09 -07:00
|
|
|
static void __acpi_power_off_list(struct acpi_handle_list *list, int num_res)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = num_res - 1; i >= 0 ; i--)
|
2011-01-06 15:38:04 -07:00
|
|
|
acpi_power_off(list->handles[i]);
|
2010-11-24 16:06:09 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_power_off_list(struct acpi_handle_list *list)
|
|
|
|
{
|
|
|
|
__acpi_power_off_list(list, list->count);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_power_on_list(struct acpi_handle_list *list)
|
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < list->count; i++) {
|
|
|
|
result = acpi_power_on(list->handles[i]);
|
|
|
|
if (result) {
|
|
|
|
__acpi_power_off_list(list, i);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
static void acpi_power_add_dependent(acpi_handle rhandle,
|
|
|
|
struct acpi_device *adev)
|
2012-03-29 00:09:39 -06:00
|
|
|
{
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_dependent_device *dep;
|
|
|
|
struct acpi_power_resource *resource;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
if (!rhandle || !adev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
resource = acpi_power_get_context(rhandle);
|
|
|
|
if (!resource)
|
2012-03-29 00:09:39 -06:00
|
|
|
return;
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
list_for_each_entry(dep, &resource->dependent, node)
|
|
|
|
if (dep->adev == adev)
|
|
|
|
goto out;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
|
|
|
|
if (!dep)
|
|
|
|
goto out;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
dep->adev = adev;
|
|
|
|
INIT_WORK(&dep->work, acpi_power_resume_dependent);
|
|
|
|
list_add_tail(&dep->node, &resource->dependent);
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
out:
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2012-03-29 00:09:39 -06:00
|
|
|
}
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
static void acpi_power_remove_dependent(acpi_handle rhandle,
|
|
|
|
struct acpi_device *adev)
|
2012-03-29 00:09:39 -06:00
|
|
|
{
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_dependent_device *dep;
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
struct work_struct *work = NULL;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
if (!rhandle || !adev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
resource = acpi_power_get_context(rhandle);
|
|
|
|
if (!resource)
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
return;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
list_for_each_entry(dep, &resource->dependent, node)
|
|
|
|
if (dep->adev == adev) {
|
|
|
|
list_del(&dep->node);
|
|
|
|
work = &dep->work;
|
|
|
|
break;
|
|
|
|
}
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
if (work) {
|
|
|
|
cancel_work_sync(work);
|
|
|
|
kfree(dep);
|
|
|
|
}
|
2012-03-29 00:09:39 -06:00
|
|
|
}
|
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
void acpi_power_add_remove_device(struct acpi_device *adev, bool add)
|
2012-03-29 00:09:39 -06:00
|
|
|
{
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
if (adev->power.flags.power_resources) {
|
|
|
|
struct acpi_device_power_state *ps;
|
|
|
|
int j;
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
ps = &adev->power.states[ACPI_STATE_D0];
|
|
|
|
for (j = 0; j < ps->resources.count; j++) {
|
|
|
|
acpi_handle rhandle = ps->resources.handles[j];
|
2012-03-29 00:09:39 -06:00
|
|
|
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
if (add)
|
|
|
|
acpi_power_add_dependent(rhandle, adev);
|
|
|
|
else
|
|
|
|
acpi_power_remove_dependent(rhandle, adev);
|
2012-03-29 00:09:39 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Device Power Management
|
|
|
|
-------------------------------------------------------------------------- */
|
2012-03-29 00:09:39 -06:00
|
|
|
|
2008-07-06 19:33:34 -06:00
|
|
|
/**
|
|
|
|
* acpi_device_sleep_wake - execute _DSW (Device Sleep Wake) or (deprecated in
|
|
|
|
* ACPI 3.0) _PSW (Power State Wake)
|
|
|
|
* @dev: Device to handle.
|
|
|
|
* @enable: 0 - disable, 1 - enable the wake capabilities of the device.
|
|
|
|
* @sleep_state: Target sleep state of the system.
|
|
|
|
* @dev_state: Target power state of the device.
|
|
|
|
*
|
|
|
|
* Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present. On failure reset the device's
|
|
|
|
* wakeup.flags.valid flag.
|
|
|
|
*
|
|
|
|
* RETURN VALUE:
|
|
|
|
* 0 if either _DSW or _PSW has been successfully executed
|
|
|
|
* 0 if neither _DSW nor _PSW has been found
|
|
|
|
* -ENODEV if the execution of either _DSW or _PSW has failed
|
|
|
|
*/
|
|
|
|
int acpi_device_sleep_wake(struct acpi_device *dev,
|
|
|
|
int enable, int sleep_state, int dev_state)
|
|
|
|
{
|
|
|
|
union acpi_object in_arg[3];
|
|
|
|
struct acpi_object_list arg_list = { 3, in_arg };
|
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to execute _DSW first.
|
|
|
|
*
|
|
|
|
* Three agruments are needed for the _DSW object:
|
|
|
|
* Argument 0: enable/disable the wake capabilities
|
|
|
|
* Argument 1: target system state
|
|
|
|
* Argument 2: target device state
|
|
|
|
* When _DSW object is called to disable the wake capabilities, maybe
|
|
|
|
* the first argument is filled. The values of the other two agruments
|
|
|
|
* are meaningless.
|
|
|
|
*/
|
|
|
|
in_arg[0].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[0].integer.value = enable;
|
|
|
|
in_arg[1].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[1].integer.value = sleep_state;
|
|
|
|
in_arg[2].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[2].integer.value = dev_state;
|
|
|
|
status = acpi_evaluate_object(dev->handle, "_DSW", &arg_list, NULL);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
return 0;
|
|
|
|
} else if (status != AE_NOT_FOUND) {
|
|
|
|
printk(KERN_ERR PREFIX "_DSW execution failed\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Execute _PSW */
|
|
|
|
arg_list.count = 1;
|
|
|
|
in_arg[0].integer.value = enable;
|
|
|
|
status = acpi_evaluate_object(dev->handle, "_PSW", &arg_list, NULL);
|
|
|
|
if (ACPI_FAILURE(status) && (status != AE_NOT_FOUND)) {
|
|
|
|
printk(KERN_ERR PREFIX "_PSW execution failed\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Prepare a wakeup device, two steps (Ref ACPI 2.0:P229):
|
|
|
|
* 1. Power on the power resources required for the wakeup device
|
2008-07-06 19:33:34 -06:00
|
|
|
* 2. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2008-07-06 19:33:34 -06:00
|
|
|
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-09-08 15:15:31 -06:00
|
|
|
int i, err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-06 19:33:34 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (dev->wakeup.prepare_count++)
|
|
|
|
goto out;
|
2008-07-06 19:34:11 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Open power resource */
|
|
|
|
for (i = 0; i < dev->wakeup.resources.count; i++) {
|
2010-10-21 18:35:54 -06:00
|
|
|
int ret = acpi_power_on(dev->wakeup.resources.handles[i]);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (ret) {
|
2006-06-26 21:41:38 -06:00
|
|
|
printk(KERN_ERR PREFIX "Transition power state\n");
|
2005-04-16 16:20:36 -06:00
|
|
|
dev->wakeup.flags.valid = 0;
|
2009-09-08 15:15:31 -06:00
|
|
|
err = -ENODEV;
|
|
|
|
goto err_out;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-07-06 19:33:34 -06:00
|
|
|
/*
|
|
|
|
* Passing 3 as the third argument below means the device may be placed
|
|
|
|
* in arbitrary power state afterwards.
|
|
|
|
*/
|
2008-07-06 19:34:11 -06:00
|
|
|
err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
|
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
err_out:
|
|
|
|
if (err)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
2008-07-06 19:34:11 -06:00
|
|
|
return err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Shutdown a wakeup device, counterpart of above method
|
2008-07-06 19:33:34 -06:00
|
|
|
* 1. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-16 16:20:36 -06:00
|
|
|
* 2. Shutdown down the power resources
|
|
|
|
*/
|
2005-08-04 22:44:28 -06:00
|
|
|
int acpi_disable_wakeup_device_power(struct acpi_device *dev)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-09-08 15:15:31 -06:00
|
|
|
int i, err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-06 19:33:34 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (--dev->wakeup.prepare_count > 0)
|
|
|
|
goto out;
|
|
|
|
|
2008-07-06 19:34:11 -06:00
|
|
|
/*
|
2009-09-08 15:15:31 -06:00
|
|
|
* Executing the code below even if prepare_count is already zero when
|
|
|
|
* the function is called may be useful, for example for initialisation.
|
2008-07-06 19:34:11 -06:00
|
|
|
*/
|
2009-09-08 15:15:31 -06:00
|
|
|
if (dev->wakeup.prepare_count < 0)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
2008-07-06 19:34:11 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
err = acpi_device_sleep_wake(dev, 0, 0, 0);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* Close power resource */
|
|
|
|
for (i = 0; i < dev->wakeup.resources.count; i++) {
|
2011-01-06 15:38:04 -07:00
|
|
|
int ret = acpi_power_off(dev->wakeup.resources.handles[i]);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (ret) {
|
2006-06-26 21:41:38 -06:00
|
|
|
printk(KERN_ERR PREFIX "Transition power state\n");
|
2005-04-16 16:20:36 -06:00
|
|
|
dev->wakeup.flags.valid = 0;
|
2009-09-08 15:15:31 -06:00
|
|
|
err = -ENODEV;
|
|
|
|
goto out;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
|
|
|
return err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-11-24 16:05:17 -07:00
|
|
|
int acpi_power_get_inferred_state(struct acpi_device *device, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
int result = 0;
|
|
|
|
struct acpi_handle_list *list = NULL;
|
|
|
|
int list_state = 0;
|
|
|
|
int i = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-11-24 16:05:17 -07:00
|
|
|
if (!device || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We know a device's inferred power state when all the resources
|
|
|
|
* required for a given D-state are 'on'.
|
|
|
|
*/
|
2012-05-20 05:58:00 -06:00
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++) {
|
2005-04-16 16:20:36 -06:00
|
|
|
list = &device->power.states[i].resources;
|
|
|
|
if (list->count < 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
result = acpi_power_get_list_state(list, &list_state);
|
|
|
|
if (result)
|
2006-06-26 22:41:40 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (list_state == ACPI_POWER_RESOURCE_STATE_ON) {
|
2010-11-24 16:05:17 -07:00
|
|
|
*state = i;
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-24 16:05:17 -07:00
|
|
|
*state = ACPI_STATE_D3;
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-11-24 16:06:55 -07:00
|
|
|
int acpi_power_on_resources(struct acpi_device *device, int state)
|
|
|
|
{
|
|
|
|
if (!device || state < ACPI_STATE_D0 || state > ACPI_STATE_D3)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return acpi_power_on_list(&device->power.states[state].resources);
|
|
|
|
}
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
int acpi_power_transition(struct acpi_device *device, int state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-17 16:39:35 -06:00
|
|
|
int result = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2012-03-29 00:09:38 -06:00
|
|
|
if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-11-24 16:02:36 -07:00
|
|
|
if (device->power.state == state)
|
|
|
|
return 0;
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
if ((device->power.state < ACPI_STATE_D0)
|
2012-03-29 00:09:38 -06:00
|
|
|
|| (device->power.state > ACPI_STATE_D3_COLD))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* TBD: Resources must be ordered. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First we reference all power resources required in the target list
|
2010-11-24 16:06:09 -07:00
|
|
|
* (e.g. so the device doesn't lose power while transitioning). Then,
|
|
|
|
* we dereference all power resources used in the current list.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-17 16:39:35 -06:00
|
|
|
if (state < ACPI_STATE_D3_COLD)
|
|
|
|
result = acpi_power_on_list(
|
|
|
|
&device->power.states[state].resources);
|
|
|
|
|
|
|
|
if (!result && device->power.state < ACPI_STATE_D3_COLD)
|
2010-11-24 16:06:09 -07:00
|
|
|
acpi_power_off_list(
|
|
|
|
&device->power.states[device->power.state].resources);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-11-24 16:06:09 -07:00
|
|
|
/* We shouldn't change the state unless the above operations succeed. */
|
|
|
|
device->power.state = result ? ACPI_STATE_UNKNOWN : state;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-06-26 22:41:40 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
static void acpi_release_power_resource(struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = to_acpi_device(dev);
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
|
|
|
|
resource = container_of(device, struct acpi_power_resource, device);
|
2013-01-17 06:11:06 -07:00
|
|
|
|
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
list_del(&resource->list_node);
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
|
|
|
|
|
|
|
acpi_free_ids(device);
|
2013-01-17 06:11:05 -07:00
|
|
|
kfree(resource);
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
void acpi_add_power_resource(acpi_handle handle)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
struct acpi_device *device = NULL;
|
2005-08-04 22:44:28 -06:00
|
|
|
union acpi_object acpi_object;
|
|
|
|
struct acpi_buffer buffer = { sizeof(acpi_object), &acpi_object };
|
2013-01-17 06:11:05 -07:00
|
|
|
acpi_status status;
|
|
|
|
int state, result = -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
acpi_bus_get_device(handle, &device);
|
|
|
|
if (device)
|
|
|
|
return;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (!resource)
|
2013-01-17 06:11:05 -07:00
|
|
|
return;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
device = &resource->device;
|
|
|
|
acpi_init_device_object(device, handle, ACPI_BUS_TYPE_POWER,
|
|
|
|
ACPI_STA_DEFAULT);
|
2007-02-15 23:47:06 -07:00
|
|
|
mutex_init(&resource->resource_lock);
|
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>
2013-01-17 06:11:05 -07:00
|
|
|
INIT_LIST_HEAD(&resource->dependent);
|
2013-01-17 06:11:05 -07:00
|
|
|
resource->name = device->pnp.bus_id;
|
2005-04-16 16:20:36 -06:00
|
|
|
strcpy(acpi_device_name(device), ACPI_POWER_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_POWER_CLASS);
|
|
|
|
|
|
|
|
/* Evalute the object to get the system level and resource order. */
|
2013-01-17 06:11:05 -07:00
|
|
|
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2013-01-17 06:11:05 -07:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
resource->system_level = acpi_object.power_resource.system_level;
|
|
|
|
resource->order = acpi_object.power_resource.resource_order;
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
result = acpi_power_get_state(handle, &state);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (result)
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-10-22 04:19:09 -06:00
|
|
|
switch (state) {
|
2005-04-16 16:20:36 -06:00
|
|
|
case ACPI_POWER_RESOURCE_STATE_ON:
|
|
|
|
device->power.state = ACPI_STATE_D0;
|
|
|
|
break;
|
|
|
|
case ACPI_POWER_RESOURCE_STATE_OFF:
|
|
|
|
device->power.state = ACPI_STATE_D3;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
device->power.state = ACPI_STATE_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
printk(KERN_INFO PREFIX "%s [%s] (%s)\n", acpi_device_name(device),
|
2007-10-22 04:19:09 -06:00
|
|
|
acpi_device_bid(device), state ? "on" : "off");
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
device->flags.match_driver = true;
|
|
|
|
result = acpi_device_register(device, acpi_release_power_resource);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (result)
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2005-08-04 22:44:28 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
list_add(&resource->list_node, &acpi_power_resource_list);
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
2013-01-17 06:11:05 -07:00
|
|
|
return;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
err:
|
|
|
|
acpi_release_power_resource(&device->dev);
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
#ifdef CONFIG_ACPI_SLEEP
|
|
|
|
void acpi_resume_power_resources(void)
|
2007-02-15 23:47:06 -07:00
|
|
|
{
|
2010-10-21 18:35:54 -06:00
|
|
|
struct acpi_power_resource *resource;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&power_resource_list_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
list_for_each_entry(resource, &acpi_power_resource_list, list_node) {
|
|
|
|
int result, state;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
result = acpi_power_get_state(resource->device.handle, &state);
|
|
|
|
if (!result && state == ACPI_POWER_RESOURCE_STATE_OFF
|
|
|
|
&& resource->ref_count) {
|
|
|
|
dev_info(&resource->device.dev, "Turning ON\n");
|
|
|
|
__acpi_power_on(resource);
|
|
|
|
}
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
}
|
2010-10-21 18:35:54 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_unlock(&power_resource_list_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
}
|
2012-08-09 15:00:02 -06:00
|
|
|
#endif
|