lkml.org 
[lkml]   [2001]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] New Driver Model for 2.5
From
Hi,

Am I correct in thinking that the current "state of play" after these recent
discussions is a 3 step suspend process, following an algorithm similar to:

if (suspend_prepare(device_list) == failed) {
suspend_cancel(device_list);
return failed;
}

if (suspend_save_state(device_list) == failed) {
suspend_cancel(device_list);
return failed;
}

write_out_state();
suspend_now(device_list);

Where these operations on the drivers are defined as:

suspend_prepare:
Allocate any memory needed for saving of state, suspending & resuming
device. LAST CHANCE TO ALLOCATE MEMORY.

suspend_save_state:
Stop accepting requests.
Save state of device.

suspend_now:
Turn off device.

suspend_cancel:
Free any memory that may have been allocated for saving of state.
Resume normal operation.

...and write_out_state() somehow stores the saved (in memory) state of the
devices to nonvolatile storage.

If this is approximately the right idea, then how will write_out_state work if
the device(s) that this operation uses aren't accepting requests anymore
(because they've done suspend_save_state)? Is it that "Stop accepting
requests" is actually "Stop accepting requests that will cause a change in the
device state"? In that case, devices that can have the state written out to
them will be limited to those where the act of writing it out will never cause
such a request, right?

- Kevin.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.048 / U:3.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site