[I removed Patrick Mochel from the CC: list since he doesn't seem to be interested in this thread.]
On Mon, 27 Sep 2004, David Brownell wrote: > > This should be subsumed under a policy setting such as PM_SNAPSHOT. > > Snapshotting is not a policy, it's an action involved in one kind of > system PM state change (not all of them). You're right, of course. I've been calling these things policy settings (not policies) but it would be good to have a more suitable term. "System power state" maybe -- although one of them is SELECTIVE_SUSPEND, which is hardly system-wide. It's also not clear to what extent these things refer to states or actions. Really they are both: requests to take action by preparing to change to a new state. > > Drivers must understand that as meaning that the device should be idle > > (i.e., no DMA, no IRQs, and presumably in some known good state) and that > > when they resume from the SNAPSHOT a resume-from-disk may have intervened. > > I think it'd be fair to say that if a driver is really idle, then by > definition its state can be snapshotted. True equally of > polled (timer-driven?) or IRQ/DMA drivers. Idleness, as I'm using it here, is a property of devices, not drivers. It means specifically that the device isn't changing the contents of memory (DMA write), relying on the contents of memory (DMA read) or trying to change the flow of control (IRQ). It also means that the device is in some "good" state from which the driver can go back to normal operation, even if the device has lost power in the meantime. > > That's right. Although it is appropriate to _use_ the driver model as a > > vehicle for allowing the user or other drivers to enable/disable/query > > wakeup settings. > > Only the policy settings, not the settings relating to hardware capability. I'm not sure what you mean here. As an example, a user would want to know whether a device supports remote wakeup. And the user might want to be able to specify whether or not remote wakeup should be disabled when the device is suspended. > Given autosuspend mechanisms, the policy setting needs to be saved > away. And once it's saved, it wouldn't be needed as an input to the > suspend_tree() primitive... It sounds like you're suggesting a separate enable_wakeup() callback, like already exists in the PCI implementation. Or did you have something else in mind? I don't quite understand exactly what you want "policy settings" to cover. > There are two devices involved there, the root hub and the PCI device > (for PCI based host controllers). For the root hub, there's no issue. Right, the root hub can be treated pretty much like any other USB device. > The issue is that for the PCI device, wakeup through PME# currently > only applies during system resume. That still seems buglike to me > (the hardware signal is generated, something's just ignoring it), > but for now it means the HC must stay in PCI_D0 until the final stage > of a system suspend operation. That rule can be enforced several > ways, including ugly (global state) as well as clean (only system PM > transitions changing power state, PME# working better, etc). Are you worried that if the PCI device is put into D3 too early and it generates a PME# wakeup signal, then Linux will receive the signal but ignore it? What would happen -- how would the signal be turned off? Provided things can be arranged so that the PME# persists until the system is asleep (at which point it would reawaken immediately) there shouldn't be a problem. Is there any possibility of implementing the PME# handler the same as every other shared interrupt handler, with drivers registering interrupt routines? 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
