On Wed, 20 Feb 2008, Jesse Barnes wrote:
quoted text
> 
> The current callback system looks like this (according to Rafael and the last 
> time I looked):
>   ->suspend(PMSG_FREEZE)
>   ->resume()
>   ->suspend(PMSG_SUSPEND)
>   *enter S3 or power off*
>   ->resume()

Yes, it's very messy.

It's messy for a few different reasons:

 - the one you hit: a driver actually has a really hard time telling what 
   PMSG_SUSPEND really means.

 - more importantly, we generally don't want to "suspend/resume" the 
   hardware at all around a power-off, because we're going to resume with 
   the state at the time of the PMSG_FREEZE, which means that the hardware 
   has actually *changed* and been used in between!

that second case is very fundamental for things like USB devices, which in 
theory you can hold alive over a real suspend event (ie a STR event), but 
which absolutely MUST NOT be resumed over a suspend-to-disk event, because 
all the low-level request state is bogus!

So the "->resume" really isn't a resume at all. It's much closer to a 
"->reset".

Of course, the "solution" to this all right now is that we have to reset 
everything even if it *is* a suspend event, so it basically means that STR 
ends up using the much weaker model that snapshot-to-disk uses.

The fundamental problem being that the two really have nothing 
what-so-ever to do with each other. They aren't even similar. Never were.

quoted text
> And in the long term we could have:
>   ->suspend()
>   *enter S3*
>   ->resume()

Yes, apart from all the complexities (suspend_late/resume_early). So in 
reality it's more than that, but the suspend/resume things are clearly 
nesting, and they have the potential to actually keep state around 
(because we *know* this machine is not going to mess with the devices in 
between).

IOW, here we actually can have as an option "assume the device is there 
when you return".

quoted text
> or:
>   ->hibernate()
>   *kexec to another kernel to save image*
>   *power off*
>   ->return_from_hibernate() (or somesuch)

Enough people don't trust kexec that I suspect the right thing simply is

	->freeze()		// stop dma, synchronize device state
	*snapshot*
	->unfreeze();		// resume dma
	*save image*
	[ optionally ->poweroff() ]	// do we really care? I'd say no
	*power off*
	->restore()		// reset device to the frozen one

which may have four entry-points that can be illogically mapped to the 
suspend/resume ones like we do now, but they really have nothing to do 
with suspending/resuming.

And notice how while "freeze/restore" kind of pairs like a 
"suspend/resume", it really shouldn't be expected to realistically restore 
the same state at all. The "restore" part is generally much better seen as 
a "reset hardware" than a "resume" thing. Because we literally cannot 
trust *anything* about the state since we froze it - we might have booted 
a different OS in between etc. Very different from suspend/resume.

			Linus
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/