Alan Stern wrote:
On Mon, 20 Sep 2004, David Brownell wrote:
There's also "power off" (ACPI D3), but until that's supported usbcore only
has analogues of ACPI D0 (on) and D2 (low power suspend) for devices.
No matter what the "upper" level code asks for, that's all that'll work.
I suppose you would implement "power off" in usbcore by turning off the
power to the parent hub's downstream port? That might not actually reduce
power usage for a self-powered device, but if it's sufficiently green it
ought to do the right thing.
It'd certainly reduce power usage by the host, since the peripheral
wouldn't be drawing current on VBUS. The peripheral would manage
its own power in all cases; not the host's problem.
To fix these problems will require getting a consensus among a reasonably
large number of people. Do you know of anyone actively working on it?
On that particular issue? Not any more; my question is who will merge
the patch to fixes that issue! Maybe it'll be part of a short set of updates
to make USB_SUSPEND behave OK with swsusp. (It was in the bunch I
just sent.)
I meant all the weaknesses in the PM subsystem. Fixing them will probably
require changes throughout the kernel.
Right. But for the moment, I think the focus is necessarily on
trying to make the current model be more usable.
As one example, consider the problem you've been having with deadlocks
involving dpm_sem. That entire design is misconceived. It forces dpm_sem
to be a single chokepoint for the whole driver model.
Right. The deadlocks are because the PM lists are protected using
that semaphore, rather than a spinlock, and because the pmcore code
uses the semaphore for too many other things. The (bogus) assumption
is that those other things never involve changing those lists (like
by adding/removing devices). Ergo self-deadlock.
The fact is, a driver for a hot-pluggable bus needs to guarantee that
certain operations will be serialized: probe, disconnect, suspend, resume,
add child, remove child. To do this requires locking either the
individual device during these events (as usbcore now does) or locking
_every_ device in the driver model (as dpm_sem does). This would work --
slowly perhaps, but without deadlock -- if dpm_sem were locked uniformly
whenever one of these events occurs, but it isn't.
I'll disagree about dpm_sem; uniformity isn't the problem, it's lock scope.
Per-device locking of some kind is certainly needed to handle device power
management (lest tasks interfere on a given device).
In the end, it may turn out to be necessary for the entire driver model to
adopt the form of locking that usbcore now uses, or something very similar
to it.
Wouldn't surprise me at all. But getting there by incremental improvements
isn't going to be straightforward. And locking is subsidiary to having a
usable/correct model.
- Dave
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
