Hi! Looks mostly good... > This adds a new pm_message_t event type to use when preparing to switch > into a swsusp snapshot. Devices that have been initialized by Linux > after resume (rather than left in power-up-reset state) may need to be > reset; this new event type gives drivers the chance to do that. > > The drivers that will care about this are those which understand more > hardware states than just "on" and "reset", and read the hardware state > during resume(). Hardware state during resume() should be either the > state left by the preceding suspend(), or a power-lost reset. When > the swsusp freeze/thaw mechanism kicks in, a troublesome third state > could exist: one state set up by a different kernel instance, before > a snapshot image is resumed. This mechanism helps eliminate that state. ...should this go to Documentation/ somewhere? > + * ON Driver starts working again, responding to hardware events > + * and software requests. The hardware may have gone through > + * a power-off reset, or it may have maintained state from the > + * previous suspend() which the driver will rely on while > + * resuming. On most platforms, there are no restrictions on > + * availability of resources like clocks during resume(). > + * > + * Other transitions are triggered by messages sent using suspend(). All > + * these transitions quiesce the driver, so that I/O queues are inactive. > + * That commonly entails turning off IRQs and DMA; there may be rules Actually all DMAs must always be turned off. Otherwise swsusp can't get consistent image. IRQs can be disabled or not (they usually are), however driver prefers... but DMA must be off. Pavel -- Thanks for all the (sleeping) penguins.
