Driver support needed for suspend/resume

From: Pavel Machek (pavel@suse.cz)
Date: Thu Feb 07 2002 - 16:33:50 EST


<<Hi!

SUSPEND_NOTIFY/SUSPEND_SAVE_STATE/SUSPEND_POWER_DOWN are not adequate
for suspend-to-disk.

When doing suspend to disk, I need to stop all devices, do atomic copy
of state, and restart them to be able to write memory image to disk.

What do you think about this? [I do not think SAVE_STATE is what
typical driver will do. IMO typical driver will just do nothing on
suspend and reinit device on resume. This reflects it. For drivers
that need to save/resume, I propose they do it in STOP/START.]

Take long look at suspend-to-disk. It is pretty tricky.

                                                                Pavel

Following operations are needed for suspend/resume:

STOP_DEVICE
        brings device into silent state. (Called from process context,
        interrupts enabled.)

Silent state:
        * device may not do any DMA
        * when someone asks for operation, device may BUG()

START_DEVICE
        brings device back from silent state. Driver state (everything
        in memory; local variables, kernel state, everything) might be
        lost between STOP_DEVICE and START_DEVICE. (Called from process
        context, interrupts enabled.)

DEINIT_DEVICE
        bring device into such state that BIOS and/or operating system
        is able to initialize the device.

INIT_DEVICE
        initialize device from state after poweron to silent state or
        working state. If you bring it to the working state, make sure
        your START_DEVICE handler can survive that.

What is this all good for?

Normal boot:

* kernel initializes devices as it allways did and boots
* user presses Ctrl-Alt-Del
* DEINIT_DEVICE is called

Suspend to RAM:

* kernel initializes devices as it allways did and boots
* user asks for suspend-to-ram
* STOP_DEVICE is called
* DEINIT_DEVICE is called
* everything but RAM is powered down
* INIT_DEVICE is called
* START_DEVICE is called

Suspend to disk:

* kernel initializes devices as it allways did and boots
* user asks for suspend-to-disk
* kernel stops all userland tasks
* kernel frees enough memory
* STOP_DEVICE is called
* interrupts are disabled and atomic copy of memory is done
* START_DEVICE is called
* kernel writes copy of memory into swapspace
* DEINIT_DEVICE is called
* machine goes powerdown
* another (!) kernel initializes devices as it allways did and boots
* machine realizes it is resume, not normal boot at late stage of boot
* new kernel reads copy of old memory
* STOP_DEVICE is called in new kernel
* interrupts are disabled and memory is atomically copied back
* START_DEVICE is called in old kernel
* old kernel is up and running

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:23 EST