On Thursday, February 10, 2011, Ian Campbell wrote: > On Thu, 2011-02-10 at 11:00 -0500, Alan Stern wrote: > > On Thu, 10 Feb 2011, Ian Campbell wrote: > > > > > On Wed, 2011-02-09 at 23:42 +0000, Alan Stern wrote: > > > > In fact there already is a "fast suspend & resume" path in the PM core. > > > > It's the freeze/thaw procedure used when starting to hibernate. The > > > > documentation specifically says that drivers' freeze methods are > > > > supposed to quiesce their devices but not change power levels. In > > > > addition, the thaw method is invoked as part of recovery from a failed > > > > hibernation attempt, so it already has the "cancel" semantics that xen > > > > seems to want. > > > > > > Sounds like that would work and I would much prefer to simply make > > > correct use of the core functionality. > > > > It seems like a reasonable approach. Whether it will actually _work_ > > is a harder question... :-) > > Heh. > > > > So PMSG_FREEZE is balanced by either PMSG_RECOVER or PMSG_THAW depending > > > on whether the suspend was cancelled or not? > > > > Basically yes. It is also "balanced" by PMSG_RESTORE, which is used > > after a memory image has been restored (although this isn't relevant to > > your snapshotting). See the comments in include/linux/pm.h. > > The documentation of the individual events in pm.h is good. Is there a > reference for the sequence of events for the different types of > suspend/hibernate/etc? > > > > So the sequence of events > > > is something like: > > > dpm_suspend_start(PMSG_FREEZE); > > > > > > dpm_suspend_noirq(PMSG_FREEZE); > > > > > > sysdev_suspend(PMSG_QUIESCE); > > > > This should say sysdev_suspend(PMSG_FREEZE). > > > > > cancelled = suspend_hypercall() > > > > At this point swsusp_arch_suspend() is called. If that translates to > > suspend_hypercall() in your setting, then yes. > > > > > sysdev_resume(); > > > > > > dpm_resume_noirq(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > > > > dpm_resume_end(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > ? > > > > Yes. > > Both of those call ->thaw ->complete. Did I mean "cancelled ? > PMSG_THAW : PMSG_RESTORE"? (or s/THAW/RECOVER?) > > If the suspend was cancelled then we want the devices to simply pickup > where they were before the freeze, wereas if we really did suspend (or > migrate or whatever) then they need to do a more complete reset and > reconnect operation so we want some sort of indication to the driver > which happened. In that case you should probably use PMSG_THAW (or PMSG_RECOVER) for the "cancel" case and PMSG_RESTORE for the "success" case (pretty much what hibernation does). And please don't forget to update the comments in pm.h to cover your usage case. :-) > > > (For comparison we currently have: > > > > > > dpm_suspend_start(PMSG_SUSPEND); > > > > > > > > > > > > dpm_suspend_noirq(PMSG_SUSPEND); > > > > > > > > > > > > sysdev_suspend(PMSG_SUSPEND); > > > > > > /* suspend hypercall */ > > > > > > sysdev_resume(); > > > > > > > > > > > > dpm_resume_noirq(PMSG_RESUME); > > > > > > > > > > > > dpm_resume_end(PMSG_RESUME); > > > ) > > > > Right. The sequence of calls is the same, but the PMSG_ argument is > > different so drivers are expected to act differently in response. > > The drivers don't actually see the PMSG_* though right? They only see a > differing sequence of hooks from dev_pm_ops called. That's correct. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
