On Wednesday 26 April 2006 21:06, Alan Stern wrote: > 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. Ah, my bad. I wasn't referring to this definition, sorry for the confusion. > > 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. Agreed. Greetings, Rafael
