On Sunday 26 September 2004 9:43 am, Alan Stern wrote: > On Sun, 26 Sep 2004, David Brownell wrote: > > > I think some of the definitions are system-specific, and all of the > > relevant specifications are weasel-worded to support that. Key > > point: if RAM is powered, some devices could be too; and the > > wakeup devices (USB, network, keyboard, etc) probably need it. > > So you're saying that I need to add a fourth power level to my scheme, > call it STR, between Low and Off. Some drivers might implement STR the > same as Low, others might implement it the same as Off.
No, I'm saying your model has to be more flexible about the way it accomodates policy constraints. STR is a system policy transition, not a device power level. The current PM framework has big problems because it doesn't even recognize the current distinctions there (e.g. PM_SUSPEND_* vs PCI_D2 etc). One device might be completely "off" in STR. Another might be significantly more active. Both can be fine, it's entirely up to how that system has been built. You've been assuming everything must be "off", precluding other types of system. (Current PMcore may be making that assumption for you...) At a driver level, STR vs STD shouldn't matter. The fact that it currently seems to matter is IMO a problem with the way the PM problem is currently factored ... should be fixed. > Calling these things power levels is no longer appropriate. "Logical > power level" would be a better term. I've been calling them "policies". One person used the analogy of cpufreq "governors" -- implementing some policy in the way making sense on that particular system. And in fact, a governor more or less manages a device power level, if you have a device framework general enough to view CPUs as just different kinds of bus-mastering controllers. (Running Linux firmware.) > > > So resume-from-disk requires detecting, initializing, and enumerating > > > every USB device, pretty much like usb_reset_device() does now. > > > > Only on boards that don't provide USB suspend current. > > Or where Linux can't leverage it, because ACPI or BIOS > > support is lacking. > > Let's suppose there is USB suspend current available during STD. How does > the kernel know that the current wasn't interrupted while power was off? The root hub reports that. Otherwise there'd be no point in providing the suspend current. Changes in D+/D- pullup state might be wakeup events too ... also something for the root hub to report. > If the USB drivers are linked into the kernel, what happens when they > start initializing devices during the resume-from-disk bootup? What about > the early-HC-disable patch that was recently added? Systems that rely on that patch are systems where the BIOS (or SMM) already screws around with the root hub state on resume. And the patch forces a reset, which the root hub reports ... the only result of USB_SUSPEND is to let remote wakeup trigger a resume, that patch trashes the entire device tree (all devices got reset, it's nothing like a resume). > Even if we can get away without initializing and enumerating devices under > favorable conditions, the code to do it still has to be there in order to > handle unfavorable conditions. Since the code has to be there, why not > use it for resume-from-power-off? When the power really did go off, sure. I've never said otherwise. But you shouldn't be planning that power always goes off. - Dave ------------------------------------------------------- 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
