> 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
hardware...
--
\\ 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
