There is new code (linux/arch/arm/lib.delay.S) in GIT that works for HZ 1000!
Sorry, for any noise... ________________________________ From: Roberts, Randy Sent: Wednesday, November 18, 2009 6:26 PM To: Roberts, Randy; 'Sergei Shtylyov' Cc: 'Steve Chen'; 'davinci-linux-open-source@linux.davincidsp.com' Subject: RE: jiffie resolution and usleep accuracy Apologies...the snippet I sent earlier was for Sparc... the code from linux/arch/arm/lib/delay.S is where __udelay() and __const_udelay() are found. They do not seem to be based upon the HZ value directly...but, are based upon loops_per_jiffy... Still searching for why udelay() behaves differently... Randy ________________________________ From: Roberts, Randy Sent: Wednesday, November 18, 2009 5:26 PM To: Roberts, Randy; Sergei Shtylyov Cc: Steve Chen; davinci-linux-open-source@linux.davincidsp.com Subject: RE: jiffie resolution and usleep accuracy In case it matters, I'm calling udelay(25)...which waits close to zero... If I use 100, I get a 100us delay...if I use 75, 8us... Is function below now somehow limited to minimum of 100 because of the change from HZ 100 to HZ 1000? Regards, Randy ________________________________ From: Roberts, Randy Sent: Wednesday, November 18, 2009 5:10 PM To: 'Sergei Shtylyov' Cc: 'Steve Chen'; 'davinci-linux-open-source@linux.davincidsp.com' Subject: RE: jiffie resolution and usleep accuracy 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:sshtyl...@ru.mvista.com] Sent: Friday, October 16, 2009 11:08 AM To: Roberts, Randy Cc: Steve Chen; davinci-linux-open-source@linux.davincidsp.com 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 Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source