[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[Graeme Russ <graeme.russ@gmail.com>]

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