Reinhard Meyer had written, on 10/25/2010 08:14 PM, the following:
Dear Nishanth Menon,
Having a loop with a counter is no timing guarentee for timing accuracy or compiler optimizations. For e.g. the same loop counter which runs when the MPU is running at 600MHz will timeout in around half the time when running at 1GHz. or the example where GCC 4.5 compiles with different optimization compared to GCC 4.4. use a udelay(10) to ensure we have a predictable delay. use an emperical number - 100000 uSec ~= 1sec for a worst case timeout. This should never happen, and is adequate imaginary condition for us to fail with timeout.
In such cases I prefer to use:
uint64_t etime; ... etime = get_ticks() + get_tbclk(); /* 1 second */ do { whatever; udelay (xx); } while (condition && get_ticks() <= etime);
That is far more accurate than calling udelay() 100000 times. (depending on implementation and granularity udelay of a few usecs might be rounded significantly) You can still call udelay inside the loop if you don't want to poll the condition too tightly...
hmmm.. almost like the jiffies in kernel ;).. timing wise, I see that the only benefit is that the approach gives a little more accuracy to the timeout delay - the other benefit is option to loop continuously instead of delaying with udelays - overall, at least the segments I saw had no reason to hit the registers so hard (alright we dont have much else to do.. but still).. I am very open to options from Sukumar(original author) as well..