After the first loop, if loops_per_jiffy is equal to x, then we know that
the 'exact' value of it is actually between x and x/2. The second loop
helps us narrow this down to the actual value (upto LPS_PREC precision
bits) by starting loops_per_jiffy (and loopbits) at x/2 and adding x/4,
x/8, x/16 and so on if a clock tick passes inside __delay when loopbits is
at that particular value.
So I don't understand your question. Why will the second loop always
fail? It won't.
Maybe rereading the code will help :) And making sure that you are not
confusing & with && or > with >>.
If you still have doubts, send me an offlist mail and I can explain in
greater detail.
Regards,
-Saugata Chatterjee.
"matrix reloaded"
<matrix_reloaded18@redi To: kernelnewbies@xxxxxxxxxxxx
ffmail.com> cc:
Sent by: Subject: BogoMips confusion ?
kernelnewbies-bounce@nl
.linux.org
09/22/2004 07:17 AM
Please respond to
"matrix reloaded"
Hi,
I am going through the code for calculating BogoMips on i386 platform.
The
code is there in "init/main.c". The main function for this is
"calibrate_delay()". If you
go through the code for calibrate_delay(), you can see that it sets
loops_per_jiffies
to 4096 at the starting of the first while loop. Based on the processor's
speed, it
goes on incrementing [making it double] its value by (loops_per_delay <<=
1)... It
comes out of the first while loop, once there is a difference between new
jiffies and
old jiffies. Now the problem starts after this...
At the second while loop you can see that
while ( lps_precision-- && (loopbit >>= 1) ) {...
the aboce condition will fail always, as the starting value for
lps_precision is
LPS_PREC which has been defined to 8.
Why is this loop there, if it will never execute ? because loopbit value
will never be
< 4096...
TIA.
Sumit Sharma
IBM, Bangalore.
(Embedded image moved to file: pic20649.gif)
Attachment:
pic20649.gif
Description: GIF image
