On Wed, 16 Mar 2005, David Brownell wrote: > > Wether the system IRQs must be masked or not is one thing that is > > platform specific during suspend. Wether devices must stop their IRQ > > emission, well... > > What's a "system IRQ" as opposed to any other kind? Drivers don't > generally know or care how their IRQs are routed, they just care > that they get a callback. Given that on some platforms it's necessary to leave some IRQs enabled for remote wakeup to work, the definitions of FREEZE and SUSPEND need to be changed. A quiesced device does not perform DMA and does not generate interrupt requests _except_ that it may issue wakeup requests (which may be IRQs) if it is enabled for remote wakeup. I don't think this will cause any problems for Suspend To Disk. If a wakeup IRQ arrives before the system is asleep and is fielded by an interrupt handler, the handler will try to start a resume. But resume needs a process context to operate, and all processes will be frozen -- so nothing will happen. The case of Suspend To Ram, where processes may not be frozen, can be solved by suitable device locking. If the PM core locks all devices before initiating the sleep transition -- which it should in any case -- and unlocks them after waking up, and if resume processing involves acquiring the device lock, then again nothing will happen. Does this help clarify things? Alan Stern
