Re: [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()

Rafael J. Wysocki
2006-04-26T20:37:42Z

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