[CC list trimmed.]
On Sunday 24 January 2010, Alan Stern wrote:
> On Sun, 24 Jan 2010, Rafael J. Wysocki wrote:
>
> > The async threads started for different devices as a result of
> > calling async_schedule() are synchronized with each other and with
> > the main suspend/resume thread with the help of completions, in the
> > following way:
> > (1) There is a completion, power.completion, for each device object.
> > (2) Each device's completion is reset before calling async_schedule()
> > for the device or, in the case of devices with the
> > power.async_suspend flags unset, before executing the device's
> > suspend and resume callbacks.
> > (3) During suspend, right before running the bus type, device type
> > and device class suspend callbacks for the device, the PM core
> > waits for the completions of all the device's children to be
> > completed.
> > (4) During resume, right before running the bus type, device type and
> > device class resume callbacks for the device, the PM core waits
> > for the completion of the device's parent to be completed.
> > (5) The PM core completes power.completion for each device right
> > after the bus type, device type and device class suspend (or
> > resume) callbacks executed for the device have returned.
>
> ...
>
> > /**
> > + * dpm_wait - Wait for a PM operation to complete.
> > + * @dev: Device to wait for.
> > + * @async: If unset, wait only if the device's power.async_suspend flag is set.
> > + */
> > +static void dpm_wait(struct device *dev, bool async)
> > +{
> > + if (!dev)
> > + return;
> > +
> > + if (async || dev->power.async_suspend)
> > + wait_for_completion(&dev->power.completion);
> > +}
>
> There needs to be a public interface to this function available for
> drivers that have non-tree constraints. The arguments should be the
> device to wait for and the device doing the waiting (needed only to
> determine whether the caller is running synchronously or not).
Something like the patch below?
> This will be necessary for USB. In fact, your current code (with patch
> 7/8 applied) is subject to a race that will sometimes cause a
> non-high-speed USB device to fail to resume from hibernation.
That's the kind of information I need at this point. What exactly should be
added to patch 7/8 to avoid this problem?
Rafael
---
drivers/base/power/main.c | 11 +++++++++++
include/linux/pm.h | 2 ++
2 files changed, 13 insertions(+)
Index: linux-2.6/drivers/base/power/main.c
===================================================================
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -1050,3 +1050,14 @@ void __suspend_report_result(const char
printk(KERN_ERR "%s(): %pF returns %d\n", function, fn, ret);
}
EXPORT_SYMBOL_GPL(__suspend_report_result);
+
+/**
+ * device_pm_wait_for_dev - Wait for suspend/resume of a device to complete.
+ * @dev: Device to wait for.
+ * @subordinate: Device that needs to wait for @dev.
+ */
+void device_pm_wait_for_dev(struct device *subordinate, struct device *dev)
+{
+ dpm_wait(dev, subordinate->power.async_suspend);
+}
+EXPORT_SYMBOL_GPL(device_pm_wait_for_dev);
Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -512,6 +512,7 @@ extern void __suspend_report_result(cons
__suspend_report_result(__func__, fn, ret); \
} while (0)
+extern void device_pm_wait_for_dev(struct device *sub, struct device *dev);
#else /* !CONFIG_PM_SLEEP */
#define device_pm_lock() do {} while (0)
@@ -524,6 +525,7 @@ static inline int dpm_suspend_start(pm_m
#define suspend_report_result(fn, ret) do {} while (0)
+static inline void device_pm_wait_for_dev(struct device *a, struct device *b) {}
#endif /* !CONFIG_PM_SLEEP */
/* How to reorder dpm_list after device_move() */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
