On Sun, Jan 16, 2011 at 15:38, loody <firstname.lastname@example.org> wrote:
> hi wu, winfred:
> Thanks for your reply ;)
> 2011/1/14 wu zhangjin <email@example.com>:
>> On Thu, Jan 13, 2011 at 6:02 PM, loody <firstname.lastname@example.org> wrote:
>>> hi all:
>>> If i trace source in the correct place, I found udelay(100) is
>>> implemented as a loop which decrease 1 per iteration until the count,
>>> 100, as 0.
>>> What makes me confused is since the speed of cpus are different and
>>> that will make udelay not precise on different platform, right?
>> Yeah, it may be not precise, so, some processors, like Cavium octeon
>> have added their own timestamp register based delay functions, please
>> refer to:
>> The delay_tsc() for X86 defined in arch/x86/lib/delay.c is similar.
>> But both of them are 64bit timestamp registers.
>> We can also apply similar method to add the precise delays for the
>> other CPUs, but we may need to take extra notice:
>> 1. If the CPU only provides 32bit timestamp registers(e.g R4K MIPS),
>> overflow should be considered.
>> 2. If the CPU support dynamic CPU frequency and the frequency of the
>> timestamp binds to the CPU's frequency, the scaled down timestamp
>> should be converted to the real timestamp.
> below is the formula about calculating the delay
> (us * 0x000010c7 * HZ * lpj )) >> 32)
> I cannot figure out why we need to multiply 0x10c7, and what lpj mean?
> Does lpj mean if jiffies increase 1, how many "subu %0, 1" may need?
Yep, lpj = loops per jiffy.
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- email@example.com
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds