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
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
