> S4 requires the OS to reinitialise peripherals.  Some comments I've seen 
> from the Linux folks suggest that we'll have to save and restore the PCI 
> configuration space as well.
> Basically, resume from S4 is not something that is going to be very easy 
> for us to implement.  It'll require every S4-OK driver to re-initialise 
> in the resume method.  (Note that we will also need to add suspend-to and 
> resume-from arguments to the relevant driver methods.)

Hmm, this has me thinking again about suspend/resume.  In the current 
context, can we expect a suspend veto from some function to actually 
DTRT? (ie. drivers that have been suspended get a resume call).

Or should we make two passes over the suspend method?  One with "
intention to suspend at this level", the second to actually perform the 
suspension once the first has been accepted?

This will allow non-ACPI-represented drivers to participate in 
determining which suspend level(s) can actually be supported by the 

\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime.             \\  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to