On Mon, 20 Sep 2004, David Brownell wrote: > Some basic rules need to exist, but the current one is annoying > even for PCI. Given numbers, I think "only goes up, or to zero" > is an OK policy, with the advantage that it's what PCI does.
The PM core isn't consistent about applying any policy. dpm_runtime_suspend() does the resume-before-changing-suspend-levels, but device_suspend() doesn't. > 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. > > 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. 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. 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. 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. 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
