Hi Sergei, et al.,
I have found that setting #define HZ 1000 in param.h breaks udelay()
calls...not sure why...anyone seen same? Fix?
Specifically, the udelay() returns without waiting at all...
HZ is used in the __udelay assembly code, but I'm not well enough versed
in arm assembly to figure out how this code may have gotten broken just
because HZ changed from 100 to 1000...
.globl __udelay
__udelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
sethi %hi(0x10c6), %o1
call .umul
or %o1, %lo(0x10c6), %o1 ! 2**32 / 1 000 000
call .umul
mov %i1, %o1 ! udelay_val
call .umul
mov HZ, %o0 ! >>32 earlier for wider range
delay_continue:
cmp %o0, 0x0
1:
bne 1b
subcc %o0, 1, %o0
ret
restore
Regards,
Randy
-----Original Message-----
From: Sergei Shtylyov [mailto:[email protected]]
Sent: Friday, October 16, 2009 11:08 AM
To: Roberts, Randy
Cc: Steve Chen; [email protected]
Subject: Re: jiffie resolution and usleep accuracy
Hello.
Steve Chen wrote:
>>Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of
>>10ms..
I'm not seeing this function in either recent kernels or MV's
2.6.10.
Perhaps you meant msleep()?
>>For DM6467, and other ARM Davinci linux implementations, 2.6.10 based
>>specifically, how does one get the jiffies to 1ms, instead of what
>>appears to be 10ms?
>>I believe I have HIGHRES timers enabled...
>>Anything else one needs to do to get usleep resolution 1ms instead of
>>10ms?
Try adding this to in include/asm-arm/arch-davinci/param.h:
#define HZ 1000
>>Scheduler config?
> What is the patch level? DM6467 HRT was not working correct. There
was
> a patch that fixed the problem.
I highly doubt that usleep() or msleep() uses clock_nanosleep(), so
whether HRT works or not shouldn't matter.
> Regards,
> Steve
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
