Wolfgang, Bill This thread was getting a little long so I took the liberty to snip the lot ;)
Now, the way I see things we are looking at two entirely different issues - udelay() and the Timer API. Unfortunately, they are somewhat intertwined because: a) Some Architectures/SoCs/Boards etc do not implement udelay() in a manner that is either 'available early' or 'inaccurate' (or in some cases both) and b) There is a not insignificant amount of code that uses a counter/udelay combination to implement timeout detection I think for the moment I would like to concentrate solely on the Timer API and leave udelay out of it. I know some architectures use the existing Timer API for udelay, but if you look at my patch series, I never actually touched the existing architecture timer implementations. To date, the series has mostly been a rename and tidy-up of the Timer API and it's usage. So, I think it will be easier to progress if we forget about udelay for the moment. We can identify where it is broken/being abused as a separate task. I can expand the scope of this patch series to look at those instances where an incrementing loop counter with a udelay in the loop is being used where get_time() and friend(s) should be used instead. So in future, any architecture that can both initialise the timer sub-system 'early' and has a timer resolution of <= 1us can use the Timer API for udelay, otherwise, udelay will need an implementation (for that architecture) which is independent of the timer sub-system. As an aside, the x86 code _used_ to have a conditional udelay. If the timer sub-system was not initialised yet, udelay would be implemented as a NOP loop. After timers were available, they were used as they are more accurate. Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot