Hi! > > 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). I understand why you want to pass down "were we powered down info", but why do you want UNFREEZE/RESUME split? ... ahha, you mean having UNFREEZE sent during suspend and RESUME sent *instead* of UNFREEZE during resume? I actually do not think drivers care if it is UNFREEZE or RESUME *that* much. I'd rather have them doing RESUME processing every time they get UNFREEZE. > 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. Actually, even with software-only resume, you can echo reboot > /sys/power/sleep. Its usefull for testing, but it may be used as nasty counterexample, too :-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
