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

2011-09-27 Thread Kostik Belousov
On Tue, Sep 27, 2011 at 10:39:44AM -0600, Julian Elischer wrote:
> 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'

I think that this should be encapsulated into the usable function,
instead of being directly exposed to the driver authors.
With the my lack of imagination, I propose driver_delay() that
would do if (cold) ... inside.


pgp30errILlUx.pgp
Description: PGP signature


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

2011-09-27 Thread Julian Elischer

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"


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

2011-09-27 Thread Gavin Atkinson
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

___
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"


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

2011-09-26 Thread John Baldwin
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.

-- 
John Baldwin
___
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"


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

2011-09-23 Thread Gavin Atkinson
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.

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"


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

2011-09-22 Thread Warner Losh
if (cold)
DELAY()
else
pause()

On Sep 22, 2011, at 11:55 AM, 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 ?
> 
> Cheers,
> David S.
> 
> 
> 
> This message and any attached documents contain information from QLogic 
> Corporation or its wholly-owned subsidiaries that may be confidential. If you 
> are not the intended recipient, you may not read, copy, distribute, or use 
> this information. If you have received this transmission in error, please 
> notify the sender immediately by reply e-mail and then delete this message.
> ___
> freebsd-driv...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-drivers
> To unsubscribe, send any mail to "freebsd-drivers-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"


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

2011-09-22 Thread Hans Petter Selasky
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.

--HPS
___
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"