[lkml]   [2007]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Wed, 4 Jul 2007, Paul Mackerras wrote:

> Alan Stern writes:
> > > Most drivers suspended their hardware in the second call. If they are
> > > in the middle of a conversation with their device that *has* to be
> > > completed, they can do that by polling.
> >
> > Ugh. That will cause problems when you try to integrate runtime
> > suspend. In fact this whole approach is unsuitable for runtime PM and
> > it obscures the similarities between runtime PM and STR.
> Yes there are similarities, but it would be a big mistake to say that
> a requirement for STR is that all drivers do runtime PM.

That's not what I'm saying. What I'm saying is that it would be a big
mistake to force all drivers which implement runtime PM to do it using
a separate code path from system PM.

> The main attraction of the late-suspend call is that it really does,
> reliably, guarantee that the driver's I/O request methods won't get
> called between the late-suspend call and the early-resume call.

For some drivers (like USB), carrying out an actual suspend requires a
delay. Right now we implement those delays using wait_event(),
wait_for_completion(), and so on. Would you have us check at runtime
whether or not a system suspend is underway and in each case use a
busy-loop instead if it is?

What happens if, in order to carry out the late-suspend, a driver needs
to acquire a mutex which happens to be held by some other task? That
other task won't be able to run and release the mutex, so you will

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-04 17:07    [W:0.038 / U:5.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site