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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
