On Wed, 26 Apr 2006, Rafael J. Wysocki wrote: > > > It just shouldn't be necessary. Actually I think the resume device shouldn't > > > be frozen too. > > > > Well, you wouldn't want it doing DMA to unknown memory areas while you're > > trying to place the image data in those same areas, would you? And when > > the image is reactivated, you wouldn't want the device generating > > interrupt requests while its driver still thinks it is suspended. (Or if > > it doesn't even have a driver in the image.) > > I think it'll always have a driver in the image, because we use it on suspend > to save the image. True. > Also IMHO, theoretically, the driver need not think the > device is suspended. It does have to think the device is frozen, however. The device _has_ to be frozen while the memory image is created, for the same reasons as mentioned before: it mustn't do DMA or generate IRQs. > I think at least some devices may be told not to do DMA and/or generate IRQs > without being reset or put into a low(er) power state. That is in fact the very definition of FREEZE. From Documentation/power/devices.txt: FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from scratch. Agreed, general devices do not need to be reset or put into a lower power state when they enter FREEZE. > Ayway, as of today, we have no infrastructure allowing us to handle resume > devices in a special way. However, if we decide to reset all devices before > restoring the image, we'll probably make such things harder to implement > in the future. Given the definition above, if a driver that has problems resuming from a FREEZE when the device has been reset then the driver is wrong. Alan Stern
