Re: [PATCH 2/2] Fix console handling during suspend/resume

Linus Torvalds
2006-06-21T15:15:31Z

On Wed, 21 Jun 2006, Benjamin Herrenschmidt wrote:
>
> Not stopping queues but not servicing them instead ... hrm ... not that
> much difference if you ask me :)

A _huge_ difference.

You still don't seem to see it:

> In fact, there is very little difference in practice as far as the
> driver implementation is concerned. I don't care either way as long as
> the driver is hardened against incoming things (requests, ioctl,
> whatever) happening after it's been suspended...

The difference is _exactly_ on the driver level.

If you stop the queues, most drivers don't have to care any more. They are
quiescent _without_ any driver impact what-so-ever.

Really.

The freeze() operation should always just stop the DMA engine. 99% of
drivers don't have a DMA engine that keeps on going independently of the
queues, so for 99% fo the drivers, freeze() should do _nothing_.

The only remaining drivers?

Basically things like USB etc that do things on a "schedule", needs to
have their scheduler engine stopped, and devices that react to outside
events ("networking") need to be told to not do that.

Btw, the real connection between STD and STR is not the shutdown. It's
actually the resume part. In both "snapshot resume" and "suspend resume"
do you need to reset the hardware to the image you have.

So it's quite possible that the _resume_ codepath is to be shared. But I'm
pretty damn sure that there's absolutely no shared code in the "suspend"
path between STD and STR, exactly because they do fundamentally different
things, and from fundamentally different levels.

Linus