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:5.230 / U:0.572 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site