Date: Mon, 19 Jun 2000 11:03:49 -0600 From: Warner Losh <imp@village.org> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ACPI project progress report Message-ID: <200006191703.LAA61037@harmony.village.org> In-Reply-To: Your message of "Mon, 19 Jun 2000 10:07:26 PDT." <200006191707.KAA08746@mass.osd.bsdi.com> References: <200006191707.KAA08746@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006191707.KAA08746@mass.osd.bsdi.com> Mike Smith writes: : 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). If the BIOS allows us to do that, yes. I'm fairly sure that doug did the right thing here. The only issue that I ever ran into was that the APM bios shut the machine down anyway, even when we tried to tell it not to. Funny thing about batteries, or something like that:-) : 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? No comment. : This will allow non-ACPI-represented drivers to participate in : determining which suspend level(s) can actually be supported by the : hardware... That's true. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006191703.LAA61037>