lkml.org 
[lkml]   [2007]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-pm] driver power operations (was Re: suspend2 merge)
Date
On Friday, 27 April 2007 16:34, Alan Stern wrote:
> On Fri, 27 Apr 2007, Johannes Berg wrote:
>
> > Look at it now:
> >
> > * FREEZE Quiesce operations so that a consistent image can be saved;
> > * but do NOT otherwise enter a low power device state, and do
> > * NOT emit system wakeup events.
> > *
> > * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring
> > * the system from a snapshot taken after an earlier FREEZE.
> > * Some drivers will need to reset their hardware state instead
> > * of preserving it, to ensure that it's never mistaken for the
> > * state which that earlier snapshot had set up.
> >
> > Why is prethaw even necessary? As far as I can tell it's only necessary
> > because resume() can't tell you whether you just want to thaw or need to
> > reset since it doesn't tell you at what point it's invoked.
>
> I think you're wrong here. It's a little hard to say because the
> terminology is confusing and not yet standardized.
>
> For the sake of argument, let's call the stages of STD and STR by these
> names (also noted are the current PSMG values):
>
> Suspend to disk:
> "prepare to create snapshot" (= FREEZE)
> "continue after snapshot" (= RESUME)
>
> Resume from disk:
> "prepare to restore snapshot" (= PRETHAW)
> "continue after restore" (= RESUME)
>
> Suspend to RAM:
> "suspend" (= SUSPEND)
> "resume" (= RESUME)
>
> The real reason for adding PRETHAW was that drivers couldn't distinguish
> between "continue after restore" and "resume", other than by examining the
> device's state -- since the PM core doesn't pass any information to the
> resume() method.
>
> I suppose we could have modified the "prepare to create snapshot" code
> instead, but doing so would mean that "continue after snapshot" and
> "continue after restore" would always do the same thing, which is not
> necessarily a good idea.
>
> Anyway, based on this analysis it seems reasonable to have Six (6) method
> pointers. Suggested names (in the same order as above):
>
> pre_snaphot()
> post_snapshot()
> pre_restore()
> post_restore()
> suspend()
> resume()
>
> People apparently assume that pre_snapshot() and pre_restore() would
> always do the same thing and hence be redundant. I'm not so sure; time
> will tell. Doing it this way certainly is more clear.

How do we differentiate between post_snapshot() and post_restore()?
I mean, after the restore we're entering the same code path as after the
snapshot, so do we use a global var for this purpose?

Rafael
-
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/

\
 
 \ /
  Last update: 2007-04-27 17:19    [W:0.992 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site