__ndelay and __udelay have not been delaying >= specified time.
The problem with __ndelay has been tacked down to the rounding of the
multiplier constant. By changing this, delays > app 18us are correctly
calculated.
The problem with __udelay has also been tracked down to rounding issues.
Changing the multiplier constant (to match that used in sparc64) corrects
for large delays and adding in a rounding constant corrects for trunctaion
errors in the claculations for short delays.
Many short delays will return without looping. This is not an error as there
is the fixed delay of doing all the maths to calculate the loop count.
Signed-off-by: Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx>
---
Patch also attahced as the inline version will probably get mangled by
my mailer.
The investigation was prompted by David Miller while I was looking at SCSI
driver issues. Changing the code does not apear to have helped with the
SCSI driver issue I am having but fixing it eliminates a potential cause of
problems.
The __udelay and __ndelay functions can be improved for accuracy for many
delays but this will be at the expense of accuracy for some of the short
delays due to the extra instructions needed to calculate the loop count.
I decided that it would be best to make the minimum of changes required to
ensure the delays do not get too short so I have not put in any
instruction count corrections or the __udelay HZ multiply correction (for
full accuracy, it needs a 64bit x HZ multiply, not a 32bit x HZ multiply).
--- linux-2.6/arch/sparc/kernel/entry.S 2007-07-21 03:26:40.000000000 +0100
+++ linux-test/arch/sparc/kernel/entry.S 2007-07-21 17:01:17.000000000 +0100
@@ -1749,8 +1749,8 @@ fpload:
__ndelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
- call .umul
- mov 0x1ad, %o1 ! 2**32 / (1 000 000 000 / HZ)
+ call .umul ! round multiplier up so large ns ok
+ mov 0x1ae, %o1 ! 2**32 / (1 000 000 000 / HZ)
call .umul
mov %i1, %o1 ! udelay_val
ba delay_continue
@@ -1760,11 +1760,17 @@ __ndelay:
__udelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
- sethi %hi(0x10c6), %o1
+ sethi %hi(0x10c7), %o1 ! round multiplier up so large us ok
call .umul
- or %o1, %lo(0x10c6), %o1 ! 2**32 / 1 000 000
+ or %o1, %lo(0x10c7), %o1 ! 2**32 / 1 000 000
call .umul
mov %i1, %o1 ! udelay_val
+ sethi %hi(0x028f4b62), %l0 ! Add in rounding constant * 2**32,
+ or %g0, %lo(0x028f4b62), %l0
+ addcc %o0, %l0, %o0 ! 2**32 * 0.009 999
+ bcs,a 3f
+ add %o1, 0x01, %o1
+3:
call .umul
mov HZ, %o0 ! >>32 earlier for wider range
Regards
Mark Fortescue.
On Sat, 21 Jul 2007, Mark Fortescue wrote:
On Fri, 20 Jul 2007, David Miller wrote:
I think these reports all point to a problem with the sparc32
kernel far outside of the drivers in question.
We have no reports like this on sparc64.
My running theory is that things like msleep() are returning
immediately on sparc32, or at least too fast, instead of delaying
the minimum necessary amount.
This will screw up the scsi reset settle delay, and the devices will
return scsi command status's that the SCSI bus probe will consider not
good enough to recognize the device.
This is exactly what tracing from Tom Callaway has shown in the past.
So this is a sparc32 kernel bug of some sort, most likely, not a
driver bug.
From: Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx>
__ndelay and __udelay have not been delayung >= specified time.
The problem with __ndelay has been tacked down to the rounding of the
multiplier constant. By changing this, delays > app 18us are correctly
calculated.
The problem with __udelay has also been tracked down to rounding issues.
Changing the multiplier constant (to match that used in sparc64) corrects
for large delays and adding in a rounding constant corrects for trunctaion
errors in the claculations.
Many short delays will return without looping. This is not an error as there
is the fixed delay of doing all the maths to calculate the loop count.
Signed-off-by: Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx>
---
--- linux-2.6/arch/sparc/kernel/entry.S 2007-07-21 03:26:40.000000000 +0100
+++ linux-test/arch/sparc/kernel/entry.S 2007-07-21 17:01:17.000000000 +0100
@@ -1749,8 +1749,8 @@ fpload:
__ndelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
- call .umul
- mov 0x1ad, %o1 ! 2**32 / (1 000 000 000 / HZ)
+ call .umul ! round multiplier up so large ns ok
+ mov 0x1ae, %o1 ! 2**32 / (1 000 000 000 / HZ)
call .umul
mov %i1, %o1 ! udelay_val
ba delay_continue
@@ -1760,11 +1760,17 @@ __ndelay:
__udelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
- sethi %hi(0x10c6), %o1
+ sethi %hi(0x10c7), %o1 ! round multiplier up so large us ok
call .umul
- or %o1, %lo(0x10c6), %o1 ! 2**32 / 1 000 000
+ or %o1, %lo(0x10c7), %o1 ! 2**32 / 1 000 000
call .umul
mov %i1, %o1 ! udelay_val
+ sethi %hi(0x028f4b62), %l0 ! Add in rounding constant * 2**32,
+ or %g0, %lo(0x028f4b62), %l0
+ addcc %o0, %l0, %o0 ! 2**32 * 0.009 999
+ bcs,a 3f
+ add %o1, 0x01, %o1
+3:
call .umul
mov HZ, %o0 ! >>32 earlier for wider range
