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. Then there's the question of having early_ and late_ versions of some of these things (i.e., one called with interrupts enabled, the other with interrupts disabled). I don't know to what extent that would be necessary; perhaps the each method call should occur in two phases with the interrupt-enable status changed in between. Then the interrupt-enable setting could be passed as an argument. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
