On Fri, 2004-11-05 at 10:53 -0500, Alan Stern wrote: > I'm trying to get my mind around what's needed for drivers (USB drivers in > particular) to implement the new PM model. Several aspects are still > unclear. > > First, a couple of questions. Is it guaranteed that the FREEZE events > are only sent by the PM core, always to every device in the tree, and only > for system-wide state changes? There doesn't seem to be any reason to use > it for partial-tree selective suspends. None that I can foresee, but why should it matter to your driver ? > Would it be a good idea to store in dev->power a flag indicating whether > or not the device is currently frozen? Unlike the power_state, being > frozen has a reasonably well-defined meaning for every device. Agreed. But we also need to cut the ties with sysfs here, it makes no sense for userland to explicitely freeze the device, though it would make some sense to understand some "words" echo'd to that "power" file and pass them along to the device as notifications, typically to trigger local PM of the device. > How should the USB system handle these things? FREEZE means: > > A. Make sure the device is idle, not doing anything non-trivial; > > B. Make sure the device is not doing DMA or issuing IRQs; > > C. Be prepared to resume from some weird state, not necessarily > the same one the device was left in; > > D. No change in power level is needed. Yes, the above basically. That is in the case of OHCI, basically stop list processing and eventually hold the controller in reset state (to avoid it touching the hcca). A pci_save_state() is good too. But no need to suspend the bus. However, that's where we need more infos on resume. Since the devices themselves will have been notified of FREEZE, and not suspend, they haven't setup the device for a bus suspend (like enabling remote wakeup or that sort of thing). This is done later, on the last step of STD. But the memory image that gets resumed is from the FREEZE state, which means on resume, drivers may be confused (if they have to deal in special ways with a device coming out of suspend). This is why I think, resume() must take a PM message argument too, and we may want to split the resume messages into UNFREEZE, and RESUME. (the 2 cases that matter, other details can go to flags). > USB device drivers would want to do A. B is vacuous because USB devices > (real ones, not virtual root hubs) cannot do DMA or issue IRQs. C is > pretty much meaningless because if the state changes in any way it will > show up as a disconnect event. As for D... see below. Unanswered is > whether or not the driver should cancel all its outstanding URBs and > refuse to issue any more. No, C is not meaningless. And yes, the driver should cancel outstanding URBs and it's expected that the HCD will error attempts to issue more. C isn't meaningless because of this possible sequence of events (the same I described just above more quickly): - FREEZE - snapshot memory image - UNFREEZE - write memory image - SUSPEND (S4/S5) ... /... - boot of loader kernel (USB devices may start beeing probed) - in the middle of the above (since USB probing is asynchronous and can take time), the loader kernel finishes loading the suspend image and sends a FREEZE - image restored - RESUME/UNFREEZE The above case is nasty. The USB devices may or may not have been disconnected, I'm not sure. On machines using totally software implementation of STD, they will be. On machines with BIOS support for STD with some kind of special S4/S5 state, the devices are just suspended when the machine goes down, I'm not sure what happens to them on wakeup. In all cases, the device state on the last RESUME/UNFREEZE is whatever has been done by the driver of the loader kernel (provided it has time to probe/init that device) on it's FREEZE call, and may not match the state that was originally saved. I think this is all quite dodgy, and I wonder if we should force a disconnection/reconnection of all on the transition from loader kernel -> saved kernel. That seem the only sane way imho... > Now what about a USB HCD? In order to avoid doing DMA the controller must > not be executing its schedule. For UHCI at least that means the > controller must be stopped, not even sending out SOF packets. This will > cause a bus-wide suspend (what the USB specification refers to as a > "global suspend"). Hrm... there is no other way ? Hrm... can't we keep the SOF's going without doing DMA ? That's a problem because some devices don't support that the bus goes into suspend state and will disconnect > So whenever the HCD gets a FREEZE message, the entire bus will unavoidably > go into a low-power suspend state. Should USB devices behave the same > way, suspending whenever they get a FREEZE? It doesn't seem necessary. > On the other hand, there's a question about when to enable remote wakeup. > I don't see anything wrong with leaving it enabled even when the device > isn't suspended -- but that's not how the code works now. At what point > during STR or STD (or even STANDBY) should remote wakeup be enabled? > (Note that this isn't an issue if we leave it enabled all the time.) > > Still unanswered is whether URBs should remain queued during FREEZE. > Obviously they won't get sent since the bus is suspended, but I don't see > anything wrong with allowing them to sit in the schedule. If usbcore > implements FREEZE by explicitly suspending devices then of course there > won't be any outstanding URBs. > > This is related to the question of whether FREEZE is ever sent to a > partial subtree. What should happen if some USB devices get a FREEZE but > their parent HCD doesn't? They would just stop issuing URBs and processing upstream requests, like they would do in the normal case. Ben.
