Re: Choosing between DELAY(useconds) and pause()

From: Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk>
Date: Tue, 27 Sep 2011 11:12:41 +0100
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
Received on Tue Sep 27 2011 - 08:12:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC