Date: Tue, 27 Sep 2011 11:12:41 +0100 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: Choosing between DELAY(useconds) and pause() Message-ID: <1317118361.95805.7.camel@buffy.york.ac.uk> In-Reply-To: <201109260930.39309.jhb@freebsd.org> References: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> <201109222007.19182.hselasky@c2i.net> <1316791266.39972.3.camel@buffy.york.ac.uk> <201109260930.39309.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2011-09-26 at 09:30 -0400, John Baldwin wrote: > On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: > > On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: > > > On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: > > > > It appears that the pause() function cannot be used in driver functions > > > > which are invoked early in the boot process. Is there is a kernel api > > > > which a device driver can use to determine whether to use pause() or > > > > DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? > > > > > > Maybe you want to use something like this: > > > > > > if (cold) > > > DELAY() > > > else > > > pause() > > > > > > In your code. > > > > Note that this still shouldn't be done in your suspend/resume paths, as > > "cold" isn't set there, however there also appears to be no guarantee > > that pause() will ever return (as you could be running after the timer > > has been suspended, or before it resumes). > > > > I'm not sure what the correct answer is for suspend/resume code. > > Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() > pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this has > changed in HEAD though with the eventtimers stuff. I do think it is best > however, to use DELAY() in the suspend/resume path always regardless. I don't think head is any different from stable/8 in this respect - the same hack patch that fixes suspend/resume for me on head also fixes it on stable/8 (the patch basically fakes "cold" during USB suspend/resume). See my email to -usb a few months ago: http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 I'd really like some guidance as to the correct solution to this, I have four separate laptops which fail out of the box on 8 and 9, but suspend/resume perfectly with this hack. Thanks, Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1317118361.95805.7.camel>