On 二, 2012-02-14 at 23:36 +0100, Rafael J. Wysocki wrote:

quoted

quoted

quoted

+ */
+struct acpi_powered_device {
+	struct list_head node;
+	struct device *dev;
+};
+
 /* --------------------------------------------------------------------------
                              Power Resource Management
    -------------------------------------------------------------------------- */

@@ -455,6 +470,118 @@ int acpi_disable_wakeup_device_power(struct acpi_device *dev)
                              Device Power Management
    -------------------------------------------------------------------------- */
 
+int acpi_power_resource_register_device(struct device *dev, acpi_handle handle)
+{
+	struct acpi_power_resource *resource;
+	struct acpi_device *acpi_dev, *res_dev;
+	acpi_handle res_handle = NULL;
+	struct acpi_powered_device *apd;
+	int i;
+	int ret;
+
+	if (!handle || !dev)
+		return -EINVAL;
+
+	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;
+
+	for (i = 0; i <= ACPI_STATE_D3; i++) {
+		struct acpi_device_power_state *ps = &acpi_dev->power.states[i];
+
+		if (!ps->flags.valid)
+			continue;
+
+		if (ps->resources.count > 1)
+			return 0;
+
+		if (!res_handle)
+			res_handle = ps->resources.handles[0];
+		else if (res_handle != ps->resources.handles[0])
+			return 0;
+	}

I'm not sure what the above checks are needed for.  It seems that this function
will only be called from acpi_bus_add_power_resource() (which needs to be
modified for this purpose, BTW), so it doesn't need to check all those things
(those checks have been made already).

No. These two APIs are introduced to support the runtime D3_COLD remote
wakeup. And they should be invoked by drivers, either in driver code or
via bus layer code.

Say, ATA port, who has _PR3 in its ACPI node, knows that it can enter
D3_COLD at run time, and it supports remote wakeup in D3_COLD because it
has _S0W (return value 4).
When remote wakeup event is triggered, there is an ACPI event sent to
the ATA controller/port, which sets the ATA controller/port back to D0
state.
At this time, what we actually need is to resume the ZPODD, rather than
the ATA controller/port. To follow the runtime PM model (runtime resume
starts from leaf devices),

Well, this isn't the case.  Parents are always resumed first.

Well, I mean runtime resume request issued by leaf devices first.

quoted

ATA code can use these two APIs to tell ACPI
to runtime resume ZPODD device directly, because ZPODD is powered by
this Power Resource as well.

I'm not exactly sure what you're trying to achieve and what you mean by
"resume a device directly"?  Do you want to run the device's resume
callback at the time when another device is being resumed?

I mean, wakeup event is sent to ATA port, but our goal is to resume
ZPODD after receiving this wakeup event.
Ideally, it is ACPI that resumes ATA port. And then, the ATA port
runtime resumes ZPODD. But this does not look good to runtime resume a
child device in the parent's .runtime_resume callback.
So I introduced these two APIs so that an runtime_resume request can be
sent to ZPODD directly and the runtime PM core can resume all the
parents of ZPODD automatically.

thanks,
rui