Date: Tue, 27 Sep 2011 10:39:44 -0600 From: Julian Elischer <julian@freebsd.org> To: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> 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: <4E81FC50.5040409@freebsd.org> In-Reply-To: <1317118361.95805.7.camel@buffy.york.ac.uk> References: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> <201109222007.19182.hselasky@c2i.net> <1316791266.39972.3.camel@buffy.york.ac.uk> <201109260930.39309.jhb@freebsd.org> <1317118361.95805.7.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/27/11 4:12 AM, Gavin Atkinson wrote: > 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. code for timers should have a generally readable state that says if they are useable or not, and we should test that instead of 'cold' > Thanks, > > Gavin > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E81FC50.5040409>