On Wed, 3 Nov 2004, Benjamin Herrenschmidt wrote: > > Presumably SUSPEND includes FREEZE. What then about wakeup IRQs? Clearly > > they need to be enabled on wakeup-capable devices when the system is > > suspended. Should they be enabled during a FREEZE? The fact that SUSPEND > > includes FREEZE argues that it should be legal to enable wakeup interrupts > > during FREEZE. > > That is totally orthogonal, but FREEZE doesn't imply a system low power > state, so there should be no need for enabling wakeup events. FREEZE is > used for snapshotting the system memory image, and for APM & kexec. APM > is totally under BIOS control and kexec doesn't require wakeup events. > > I think wakeup events are only needed for STANDBY and SUSPEND Right, they're only _needed_ for STANDBY and SUSPEND. But are wakeup/resume IRQs _legal_ for FREEZE? (Since the system won't be suspended during a FREEZE, the IRQs should actually be called resume requests, not wakeup requests. For some devices there's a difference and for others there isn't. The nomenclature here has a weak aspect; what the device actually _does_ depends on how the device is configured, but the _name_ we use depends on what the system is doing rather than what the device does.) One of the main points of FREEZE is to make sure everything is quiet so that a logically consistent memory image can be prepared for STD. This can't be done if there are interrupt requests being handled at the same time. On the other hand, given that interrupts will be disabled while the memory image is prepared, maybe it doesn't matter if some devices send wakeup/resume IRQs during FREEZE. In short, should devices be allowed to send wakeup/resume IRQs during FREEZE? Pro: Yes, because they are allowed to do so during SUSPEND and FREEZE should be less restrictive than SUSPEND. Con: No, because a frozen device shouldn't do anything that would disturb the system, including sending an IRQ. ? Alan Stern
