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..
-- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot