* [PATCH v3 0/3] ACPI/PM D3Cold state support
@ 2012-03-29 6:09 Lin Ming
2012-03-29 6:09 ` [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD " Lin Ming
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Lin Ming @ 2012-03-29 6:09 UTC (permalink / raw)
To: Len Brown, Rafael J. Wysocki
Cc: Alan Stern, linux-acpi, linux-pm, linux-kernel
The ZPODD patch set involves 4 subsystems: ACPI, Generic PM, SATA and SCSI.
This makes it hard to push upstream.
So I decide to seprate it to two patch sets, one for ACPI/PM and the other
for SATA/SCSI.
You can find the SATA/SCSI part at:
[PATCH v3 0/7] SATA ZPODD support
https://lkml.org/lkml/2012/3/28/20
[PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD state support
[PATCH v3 2/3] ACPI: Add interface to register/unregister device to/from power resources
[PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data
Rafael,
Would you ack PATCH 3?
I renamed the flag to may_power_off according to Alan's suggestion.
Thanks,
Lin Ming
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD state support
2012-03-29 6:09 [PATCH v3 0/3] ACPI/PM D3Cold state support Lin Ming
@ 2012-03-29 6:09 ` Lin Ming
2012-03-31 15:31 ` Aaron Lu
2012-03-29 6:09 ` [PATCH v3 2/3] ACPI: Add interface to register/unregister device to/from power resources Lin Ming
2012-03-29 6:09 ` [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data Lin Ming
2 siblings, 1 reply; 7+ messages in thread
From: Lin Ming @ 2012-03-29 6:09 UTC (permalink / raw)
To: Len Brown, Rafael J. Wysocki
Cc: Alan Stern, linux-acpi, linux-pm, linux-kernel
From: Zhang Rui <rui.zhang@intel.com>
If a device has _PR3, it means the device supports D3_COLD.
Add the ability to validate and enter D3_COLD state in ACPI.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
drivers/acpi/power.c | 4 ++--
drivers/acpi/scan.c | 7 +++++++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 9ac2a9f..0d681fb 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -500,14 +500,14 @@ int acpi_power_transition(struct acpi_device *device, int state)
{
int result;
- if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3))
+ if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
return -EINVAL;
if (device->power.state == state)
return 0;
if ((device->power.state < ACPI_STATE_D0)
- || (device->power.state > ACPI_STATE_D3))
+ || (device->power.state > ACPI_STATE_D3_COLD))
return -ENODEV;
/* TBD: Resources must be ordered. */
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 8ab80ba..571396c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -885,6 +885,13 @@ static int acpi_bus_get_power_flags(struct acpi_device *device)
acpi_bus_add_power_resource(ps->resources.handles[j]);
}
+ /* The exist of _PR3 indicates D3Cold support */
+ if (i == ACPI_STATE_D3) {
+ status = acpi_get_handle(device->handle, object_name, &handle);
+ if (ACPI_SUCCESS(status))
+ device->power.states[ACPI_STATE_D3_COLD].flags.valid = 1;
+ }
+
/* Evaluate "_PSx" to see if we can do explicit sets */
object_name[2] = 'S';
status = acpi_get_handle(device->handle, object_name, &handle);
--
1.7.2.5
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v3 2/3] ACPI: Add interface to register/unregister device to/from power resources
2012-03-29 6:09 [PATCH v3 0/3] ACPI/PM D3Cold state support Lin Ming
2012-03-29 6:09 ` [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD " Lin Ming
@ 2012-03-29 6:09 ` Lin Ming
2012-03-29 6:09 ` [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data Lin Ming
2 siblings, 0 replies; 7+ messages in thread
From: Lin Ming @ 2012-03-29 6:09 UTC (permalink / raw)
To: Len Brown, Rafael J. Wysocki
Cc: Alan Stern, linux-acpi, linux-pm, linux-kernel
Devices may share same list of power resources in _PR0, for example
Device(Dev0)
{
Name (_PR0, Package (0x01)
{
P0PR,
P1PR
})
}
Device(Dev1)
{
Name (_PR0, Package (0x01)
{
P0PR,
P1PR
}
}
Assume Dev0 and Dev1 were runtime suspended.
Then Dev0 is resumed first and it goes into D0 state.
But Dev1 is left in D0_Uninitialised state.
This is wrong. In this case, Dev1 must be resumed too.
In order to hand this case, each power resource maintains a list of
devices which relies on it.
When power resource is ON, it will check if the devices on its list
can be resumed. The device can only be resumed when all the power
resouces of its _PR0 are ON.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
drivers/acpi/power.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++
include/acpi/acpi_bus.h | 2 +
2 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 0d681fb..7049a7d 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -40,9 +40,11 @@
#include <linux/init.h>
#include <linux/types.h>
#include <linux/slab.h>
+#include <linux/pm_runtime.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include "sleep.h"
+#include "internal.h"
#define PREFIX "ACPI: "
@@ -77,6 +79,20 @@ static struct acpi_driver acpi_power_driver = {
},
};
+/*
+ * A power managed device
+ * A device may rely on multiple power resources.
+ * */
+struct acpi_power_managed_device {
+ struct device *dev; /* The physical device */
+ acpi_handle *handle;
+};
+
+struct acpi_power_resource_device {
+ struct acpi_power_managed_device *device;
+ struct acpi_power_resource_device *next;
+};
+
struct acpi_power_resource {
struct acpi_device * device;
acpi_bus_id name;
@@ -84,6 +100,9 @@ struct acpi_power_resource {
u32 order;
unsigned int ref_count;
struct mutex resource_lock;
+
+ /* List of devices relying on this power resource */
+ struct acpi_power_resource_device *devices;
};
static struct list_head acpi_power_resource_list;
@@ -183,8 +202,26 @@ static int acpi_power_get_list_state(struct acpi_handle_list *list, int *state)
return 0;
}
+/* Resume the device when all power resources in _PR0 are on */
+static void acpi_power_on_device(struct acpi_power_managed_device *device)
+{
+ struct acpi_device *acpi_dev;
+ acpi_handle handle = device->handle;
+ int state;
+
+ if (acpi_bus_get_device(handle, &acpi_dev))
+ return;
+
+ if(acpi_power_get_inferred_state(acpi_dev, &state))
+ return;
+
+ if (state == ACPI_STATE_D0 && pm_runtime_suspended(device->dev))
+ pm_request_resume(device->dev);
+}
+
static int __acpi_power_on(struct acpi_power_resource *resource)
{
+ struct acpi_power_resource_device *device_list = resource->devices;
acpi_status status = AE_OK;
status = acpi_evaluate_object(resource->device->handle, "_ON", NULL, NULL);
@@ -197,6 +234,12 @@ static int __acpi_power_on(struct acpi_power_resource *resource)
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Power resource [%s] turned on\n",
resource->name));
+ while (device_list) {
+ acpi_power_on_device(device_list->device);
+
+ device_list = device_list->next;
+ }
+
return 0;
}
@@ -299,6 +342,125 @@ static int acpi_power_on_list(struct acpi_handle_list *list)
return result;
}
+static void __acpi_power_resource_unregister_device(struct device *dev,
+ acpi_handle res_handle)
+{
+ struct acpi_power_resource *resource = NULL;
+ struct acpi_power_resource_device *prev, *curr;
+
+ if (acpi_power_get_context(res_handle, &resource))
+ return;
+
+ mutex_lock(&resource->resource_lock);
+ prev = NULL;
+ curr = resource->devices;
+ while (curr) {
+ if (curr->device->dev == dev) {
+ if (!prev)
+ resource->devices = curr->next;
+ else
+ prev->next = curr->next;
+
+ kfree(curr);
+ break;
+ }
+
+ prev = curr;
+ curr = curr->next;
+ }
+ mutex_unlock(&resource->resource_lock);
+}
+
+/* Unlink dev from all power resources in _PR0 */
+void acpi_power_resource_unregister_device(struct device *dev, acpi_handle handle)
+{
+ struct acpi_device *acpi_dev;
+ struct acpi_handle_list *list;
+ int i;
+
+ if (!dev || !handle)
+ return;
+
+ if (acpi_bus_get_device(handle, &acpi_dev))
+ return;
+
+ list = &acpi_dev->power.states[ACPI_STATE_D0].resources;
+
+ for (i = 0; i < list->count; i++)
+ __acpi_power_resource_unregister_device(dev,
+ list->handles[i]);
+}
+
+static int __acpi_power_resource_register_device(
+ struct acpi_power_managed_device *powered_device, acpi_handle handle)
+{
+ struct acpi_power_resource *resource = NULL;
+ struct acpi_power_resource_device *power_resource_device;
+ int result;
+
+ result = acpi_power_get_context(handle, &resource);
+ if (result)
+ return result;
+
+ power_resource_device = kzalloc(
+ sizeof(*power_resource_device), GFP_KERNEL);
+ if (!power_resource_device)
+ return -ENOMEM;
+
+ power_resource_device->device = powered_device;
+
+ mutex_lock(&resource->resource_lock);
+ power_resource_device->next = resource->devices;
+ resource->devices = power_resource_device;
+ mutex_unlock(&resource->resource_lock);
+
+ return 0;
+}
+
+/* Link dev to all power resources in _PR0 */
+int acpi_power_resource_register_device(struct device *dev, acpi_handle handle)
+{
+ struct acpi_device *acpi_dev;
+ struct acpi_handle_list *list;
+ struct acpi_power_managed_device *powered_device;
+ int i, ret;
+
+ if (!dev || !handle)
+ return -ENODEV;
+
+ ret = acpi_bus_get_device(handle, &acpi_dev);
+ if (ret)
+ goto no_power_resource;
+
+ if (!acpi_dev->power.flags.power_resources)
+ goto no_power_resource;
+
+ powered_device = kzalloc(sizeof(*powered_device), GFP_KERNEL);
+ if (!powered_device)
+ return -ENOMEM;
+
+ powered_device->dev = dev;
+ powered_device->handle = handle;
+
+ list = &acpi_dev->power.states[ACPI_STATE_D0].resources;
+
+ for (i = 0; i < list->count; i++) {
+ ret = __acpi_power_resource_register_device(powered_device,
+ list->handles[i]);
+
+ if (ret) {
+ acpi_power_resource_unregister_device(dev, handle);
+ break;
+ }
+ }
+
+ return ret;
+
+no_power_resource:
+ printk(KERN_WARNING PREFIX "Invalid Power Resource to register!");
+ return -ENODEV;
+}
+
/**
* acpi_device_sleep_wake - execute _DSW (Device Sleep Wake) or (deprecated in
* ACPI 3.0) _PSW (Power State Wake)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 6cd5b64..e168fff 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -323,6 +323,8 @@ int acpi_bus_set_power(acpi_handle handle, int state);
int acpi_bus_update_power(acpi_handle handle, int *state_p);
bool acpi_bus_power_manageable(acpi_handle handle);
bool acpi_bus_can_wakeup(acpi_handle handle);
+int acpi_power_resource_register_device(struct device *dev, acpi_handle handle);
+void acpi_power_resource_unregister_device(struct device *dev, acpi_handle handle);
#ifdef CONFIG_ACPI_PROC_EVENT
int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int data);
int acpi_bus_generate_proc_event4(const char *class, const char *bid, u8 type, int data);
--
1.7.2.5
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data
2012-03-29 6:09 [PATCH v3 0/3] ACPI/PM D3Cold state support Lin Ming
2012-03-29 6:09 ` [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD " Lin Ming
2012-03-29 6:09 ` [PATCH v3 2/3] ACPI: Add interface to register/unregister device to/from power resources Lin Ming
@ 2012-03-29 6:09 ` Lin Ming
2012-03-30 5:49 ` Len Brown
2 siblings, 1 reply; 7+ messages in thread
From: Lin Ming @ 2012-03-29 6:09 UTC (permalink / raw)
To: Len Brown, Rafael J. Wysocki
Cc: Alan Stern, linux-acpi, linux-pm, linux-kernel
Parent device will check child's may_power_off flag to see if child device can
be powered off.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
include/linux/pm.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index e4982ac..c9953b4 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -465,6 +465,7 @@ struct pm_subsys_data {
#ifdef CONFIG_PM_GENERIC_DOMAINS
struct pm_domain_data *domain_data;
#endif
+ bool may_power_off;
};
struct dev_pm_info {
--
1.7.2.5
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data
2012-03-29 6:09 ` [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data Lin Ming
@ 2012-03-30 5:49 ` Len Brown
2012-03-30 7:49 ` huang ying
0 siblings, 1 reply; 7+ messages in thread
From: Len Brown @ 2012-03-30 5:49 UTC (permalink / raw)
To: Lin Ming
Cc: Rafael J. Wysocki, Alan Stern, linux-acpi, linux-pm, linux-kernel
Why?
-Len
On 03/29/2012 02:09 AM, Lin Ming wrote:
> Parent device will check child's may_power_off flag to see if child device can
> be powered off.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
> include/linux/pm.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index e4982ac..c9953b4 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -465,6 +465,7 @@ struct pm_subsys_data {
> #ifdef CONFIG_PM_GENERIC_DOMAINS
> struct pm_domain_data *domain_data;
> #endif
> + bool may_power_off;
> };
>
> struct dev_pm_info {
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data
2012-03-30 5:49 ` Len Brown
@ 2012-03-30 7:49 ` huang ying
0 siblings, 0 replies; 7+ messages in thread
From: huang ying @ 2012-03-30 7:49 UTC (permalink / raw)
To: Len Brown
Cc: Lin Ming, Rafael J. Wysocki, Alan Stern, linux-acpi, linux-pm,
linux-kernel
On Fri, Mar 30, 2012 at 1:49 PM, Len Brown <lenb@kernel.org> wrote:
> Why?
1) To support something like pm-qos. power off device may have more
exit.latency than normal low power state (such as D3Hot). Some device
may disable may_power_off based on that. It can be used to implement
the logic like, only power off SSD, not HDD.
2) Whether to go to power off should be determined by leaf device
(such as SATA disk), but that may be done by its parent device (such
as SATA port). It's a way for leaf device to tell its parent device
whether it want to go to power off.
Best Regards,
Huang Ying
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD state support
2012-03-29 6:09 ` [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD " Lin Ming
@ 2012-03-31 15:31 ` Aaron Lu
0 siblings, 0 replies; 7+ messages in thread
From: Aaron Lu @ 2012-03-31 15:31 UTC (permalink / raw)
To: Lin Ming
Cc: Len Brown, Rafael J. Wysocki, Alan Stern, linux-acpi, linux-pm,
linux-kernel
Hi,
On Thu, Mar 29, 2012 at 02:09:38PM +0800, Lin Ming wrote:
> From: Zhang Rui <rui.zhang@intel.com>
>
> If a device has _PR3, it means the device supports D3_COLD.
> Add the ability to validate and enter D3_COLD state in ACPI.
Since we are going to support two D3 states, I think maybe we should
clear their meanings in Linux. So D3 means D3 hot, right?
If so, I think the following code has problems:
static int acpi_bus_get_power_flags(struct acpi_device *device)
{
... ...
/* Set defaults for D0 and D3 states (always valid) */
device->power.states[ACPI_STATE_D0].flags.valid = 1;
device->power.states[ACPI_STATE_D0].power = 100;
device->power.states[ACPI_STATE_D3].flags.valid = 1;
device->power.states[ACPI_STATE_D3].power = 0;
}
The problem is, D3's valid flag shouldn't be set and its power shouldn't
be 0 since it's D3 hot. It feels like D3_COLD should be used instead.
What do you think? Thanks.
-Aaron
>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
> drivers/acpi/power.c | 4 ++--
> drivers/acpi/scan.c | 7 +++++++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index 9ac2a9f..0d681fb 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -500,14 +500,14 @@ int acpi_power_transition(struct acpi_device *device, int state)
> {
> int result;
>
> - if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3))
> + if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
> return -EINVAL;
>
> if (device->power.state == state)
> return 0;
>
> if ((device->power.state < ACPI_STATE_D0)
> - || (device->power.state > ACPI_STATE_D3))
> + || (device->power.state > ACPI_STATE_D3_COLD))
> return -ENODEV;
>
> /* TBD: Resources must be ordered. */
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 8ab80ba..571396c 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -885,6 +885,13 @@ static int acpi_bus_get_power_flags(struct acpi_device *device)
> acpi_bus_add_power_resource(ps->resources.handles[j]);
> }
>
> + /* The exist of _PR3 indicates D3Cold support */
> + if (i == ACPI_STATE_D3) {
> + status = acpi_get_handle(device->handle, object_name, &handle);
> + if (ACPI_SUCCESS(status))
> + device->power.states[ACPI_STATE_D3_COLD].flags.valid = 1;
> + }
> +
> /* Evaluate "_PSx" to see if we can do explicit sets */
> object_name[2] = 'S';
> status = acpi_get_handle(device->handle, object_name, &handle);
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-03-31 7:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-29 6:09 [PATCH v3 0/3] ACPI/PM D3Cold state support Lin Ming
2012-03-29 6:09 ` [PATCH v3 1/3] ACPI: Introduce ACPI D3_COLD " Lin Ming
2012-03-31 15:31 ` Aaron Lu
2012-03-29 6:09 ` [PATCH v3 2/3] ACPI: Add interface to register/unregister device to/from power resources Lin Ming
2012-03-29 6:09 ` [PATCH v3 3/3] PM / Runtime: Add may_power_off flag to subsys data Lin Ming
2012-03-30 5:49 ` Len Brown
2012-03-30 7:49 ` huang ying
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox