From: Jon S. <jon...@ya...> - 2003-01-30 20:46:19
|
This one took me a long time to find. If these are int they will overflow and the delay will be too short. They need to be um_udelay_t which is a long. ===== time_kern.c 1.7 vs edited ===== 110c110 < int i, n; --- > um_udelay_t i, n; 118c118 < int i, n; --- > um_udelay_t i, n; ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Jon S. <jon...@ya...> - 2003-01-30 23:32:39
|
The udelay code will still overflow with long and sometime even with long long. We need to work out a better way to do this. The example I am working on needs a delay of 163 usec. loops_per_jiffy is 0x53C000 or 5,488,620. HZ is 100. #define udelay(n) (__builtin_constant_p(n) ? ((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : __udelay(n)) delay is multiplied by 0x10c6 before calling __const delay. So in my case the numerator is: 5,488,620 * 100 * 163 * 4296 = 3.8e14 ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Jon S. <jon...@ya...> - 2003-01-31 02:41:34
|
I fixed the udelay code by having it call nanosleep in the host. I'll include the code in the next patch I post. __udelay, __const_udelay, including asm/arch/delay.h from asm/delay.h all disappear. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |