Timur Tabi wrote:
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I
suggested adding a third parameter that would be a udelay(
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I suggested
adding a third parameter that would be a udelay() inserted into the
> No, not udelay. Or any delay for that matter. If spinning on a
> condition, then there is no advantage to burning cycles with a
> udelay(). Those cycles may as well be used to keep testing the
> condition so the loop can be exited faster. a udelay() would only
> serve to always make the busy
Timur Tabi wrote:
Scott Wood wrote:
> Or you can say that atomic context is outside the scope of this macro.
No, I don't want to say that. We have wait_event_timeout() for
larger-scale operations. I'm just looking for something that can
replace "while (!condition);"
wait_event_timeout()
Scott Wood wrote:
> Or you can say that atomic context is outside the scope of this macro.
No, I don't want to say that. We have wait_event_timeout() for larger-scale
operations. I'm just looking for something that can replace "while (!condition);"
--
Timur Tabi
Linux Kernel Developer @ Fre
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood wrote:
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the existence
of this macro would e
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood wrote:
> I was under the impression that we were only talking about timeouts, and
> that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the existence
of this macro would encourage people to
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood wrote:
One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
I was under the impression that we we
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood wrote:
> One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
Unfortunately, the driver may not have any choice in some
c
On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
>>
>> Alan did have one valid point though. Determining how long to loop
>> for is architecture-specific. Using jiffies is bad, because even one
>> jiffy is too long. Adding a u
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier wrote:
Are there really cases where spinning for 1 jiffy is too long of a
timeout?
If the result is a timeout, then I say no. A timeout is an error
condition, and the code will usually terminate.
[snip]
Two jiffies can be a
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier wrote:
> Are there really cases where spinning for 1 jiffy is too long of a
> timeout?
If the result is a timeout, then I say no. A timeout is an error
condition, and the code will usually terminate.
> It might make sense for the parameter passed
> Alan did have one valid point though. Determining how long to loop
> for is architecture-specific. Using jiffies is bad, because even one
> jiffy is too long. Adding a udelay() inside the loop means that it
> only checks he condition every microsecond. So the real solution is
> to use ke
On Wed, Mar 11, 2009 at 10:59:11AM +1100, Benjamin Herrenschmidt wrote:
>On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
>> > Timur Tabi wrote:
>> >> The macro spin_event_timeout() takes a condition and timeout value
>> >> (in micr
On Tue, Mar 10, 2009 at 05:58:58PM -0500, Scott Wood wrote:
> Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
>>> Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either t
On Tue, Mar 10, 2009 at 6:59 PM, Benjamin Herrenschmidt
wrote:
> And ? We can disagree with Alan...
If you guys want to argue with Alan on lkml, please go ahead. I could
use the support.
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using ji
On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
>
> Alan did have one valid point though. Determining how long to loop
> for is architecture-specific. Using jiffies is bad, because even one
> jiffy is too long. Adding a udelay() inside the loop means that it
> only checks he condition ever
On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
> > Timur Tabi wrote:
> >> The macro spin_event_timeout() takes a condition and timeout value
> >> (in microseconds) as parameters. It spins until either the condition is
> >> true
>
On Tue, 2009-03-10 at 17:11 -0500, Timur Tabi wrote:
> The macro spin_event_timeout() takes a condition and timeout value
> (in microseconds) as parameters. It spins until either the condition is true
> or the timeout expires. It returns zero if the timeout expires first,
> non-zero
> otherwise.
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeou
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
> Timur Tabi wrote:
>> The macro spin_event_timeout() takes a condition and timeout value
>> (in microseconds) as parameters. It spins until either the condition is true
>> or the timeout expires. It returns zero if the timeout expires f
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first, non-zero
otherwise.
This primary purpose of this macro is to p
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first, non-zero
otherwise.
This primary purpose of this macro is to poll on a hardware re
23 matches
Mail list logo
