> > > > > Later on, when the system wakes up and the image is restored, > > > > > drivers are asked to > > > > > resume the devices. The problem is that now the drivers think > > > > > the devices are in FREEZE when in fact they are really in SUSPEND. > > > > > The difference is significant and it can cause errors in the > > > > > resume procedure. > > > > > > > > No; devices are in FREEZE if their driver was in kernel, and in some kind > > > > of power up state when not. Drivers should just handle both. > > > > > > For USB, that "some kind of power up state" will in fact be SUSPEND. > > > > Excuse me taking a step back, but I think you guys might be solving a > > problem that doesn't exist... I see the problem as being the latest definition of FREEZE: FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from scratch. That probably means ... SUSPEND -- like FREEZE, but also put hardware into low-power state. Definitions like those are "probably" imprecise enough to be useless to implementors. And since drivers are free to put hardware into low power states any time it's convenient to them, there is really no practical difference between those two notions. (This is different from earlier notions of FREEZE I remember being discussed. In particular the one that viewed it as just quiescing.) > > How do USB drivers get into a suspend state? There's driver state ... and there's device state. For USB the two are very cleanly separated, since drivers are bound to usb_interface objects, while only usb_device objects (or root hubs) can have real power state. > > At suspend time, before the > > atomic copy is made they have been told to FREEZE. At resume time, prior > > to the atomic restore, they have been told to FREEZE. The state > > They have been told to freeze _if you have usb built in_, and not > modular. Pavel, there's no such "is it built in" logic I've seen anywhere in the PM framework. It may be appropriate to add some at some point; but that'd notion would need to be decently thought through. > Imagine kernel with usb as a module, doing resume from kernel > command line. usb will be in "just powered on" state. Well, "from kernel command line" all but guarantees a reset has been done, and so the USB devices will not be suspended. Remember, you may be typing that command line on a USB keyboard, which BIOS had to re-initialize. Linux and BIOS won't share USB device state. Now if it's a real resume transition -- from suspend-to-RAM, or something similar that doesn't load a new Linux kernel -- then hardware can often maintain the USB suspend state while the system is in its low power state. The cost is normally 500 uA per device, though some may consume a bit more. - Dave
