On Sat, 6 Nov 2004, Benjamin Herrenschmidt wrote: > > 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 ? Can't remember at the moment. But consider that if a USB HCD is also frozen then it will fail all attempts to queue an URB, so a frozen device driver wouldn't have to consciously avoid submitting URBs. Partly I'm trying to figure out what a USB device driver should do for a FREEZE and a SUSPEND. Maybe it should do the same thing for both, the only difference being that a SUSPEND will cause the bus driver to actually suspend the device. > 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 Yes, I see the problem. During the final RESUME the device may be in its FROZEN state, or it may be suspended, or it may be in whatever state the BIOS left it during the reboot, or it may be in some other weird intermediate state. > 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... This would have to be done extremely carefully. The model used in the USB subsystem is that when a device is disconnected it goes away completely. Even if it reconnects, the code doesn't recognize it as the same device -- it's treated as a totally new device. This is particularly relevant for USB mass storage devices; a disconnect followed by reconnect would break mounted filesystems, for example. > > 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 Unfortunately UHCI controllers aren't very smart. They're either running or stopped, and whenever they run they do DMA. If some devices disconnect when they find the bus is suspended, then they'll be gone when we resume from the FREEZE. Nothing we can do about it. Alan Stern
