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
