Date: Mon, 19 Jun 2000 10:07:26 -0700 From: Mike Smith <msmith@freebsd.org> To: Mike Smith <msmith@freebsd.org> Cc: Warner Losh <imp@village.org>, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ACPI project progress report Message-ID: <200006191707.KAA08746@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 19 Jun 2000 09:42:10 PDT." <200006191642.JAA08637@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006191707.KAA08746>