On Tuesday 27 June 2006 22:06, Larry Finger wrote:
> John,
>
> I would like to find a diplomatic solution to this impasse between Michael
> and Jeff, which is why
> I'm writing to you privately. Michael is correct in that the loop in question
> will not usually delay
private?
> long; however, on some hardware it takes longer than on his. On mine, I have
> seen delays as long as
> 550 usec.
What's the chip?
> In any case, I think that the following code fragment would work and pass
> Jeff's criticism:
>
> for (i=5000; i; i--) {
> ..........
> usleep(1);
usleep? Can't find that in my kernel tree.
In fact, I think the lowest possible sleep time
depends on HZ and is 1msec on 1000HZ.
Additionally, we are holding a spinlock at this time, so it is
not as easy as simply replacing udelay() by some sleeping function.
> This would make the worst-case delay be 5 msec, but would provide a cushion
> of 10X the longest I
> have seen and should be safe.
>
> Do you have any suggestions on what should be done next?
Leave it as is and find out why it takes so long for your strange card. ;)
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
