During testing it was discovered that mdelay() didn't provide as long
delay as it should. The reason is that __const_udelay() should have
stored the result of (loops_per_jiffy * HZ * xloops) in a 64-bit
register pair but didn't.
Fix the problem by doing a 32 x 32 => 64 bit multiplication in inline
assembly. This could probably have been solved by some casting, but IMO
the inline asm makes the intention more clear. As an added bonus, the
new code looks more like the i386 code.
Signed-off-by: Haavard Skinnemoen <[email protected]>
---
arch/avr32/lib/delay.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.18-avr32/arch/avr32/lib/delay.c
===================================================================
--- linux-2.6.18-avr32.orig/arch/avr32/lib/delay.c 2006-09-15 10:27:02.000000000 +0200
+++ linux-2.6.18-avr32/arch/avr32/lib/delay.c 2006-09-15 10:33:08.000000000 +0200
@@ -37,7 +37,9 @@ inline void __const_udelay(unsigned long
{
unsigned long long loops;
- loops = (current_cpu_data.loops_per_jiffy * HZ) * xloops;
+ asm("mulu.d %0, %1, %2"
+ : "=r"(loops)
+ : "r"(current_cpu_data.loops_per_jiffy * HZ), "r"(xloops));
__delay(loops >> 32);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
