[U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell <jwilliamcampbell@comcast.net>]

On 5/22/2011 6:42 PM, Graeme Russ wrote:
> OK, so in summary, we can (in theory) have:
>   - A timer API in /lib/ with a single u32 get_timer(u32 base) function
>   - A HAL with two functions
>     - u32 get_raw_ticks()
>     - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>       max's out at just after 4GHz)
>   - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
>     and get_tick_rate() to correctly maintain the ms counter used by
>     get_timer() - This function can be weak (so next point)
>   - If the hardware supports a native 32-bit ms counter, get_raw_ms()
>     can be overridden to simply return the hardware counter. In this case,
>     get_raw_ticks() would return 1
>   - Calling of get_raw_ticks() regularly in the main loop (how ofter will
>     depend on the raw tick rate, but I image it will never be necessary
>     to call more often than once every few minutes)
>   - If the hardware implements a native 32-bit 1ms counter, no call in
>     the main loop is required
>   - An optional HAL function u32 get_raw_us() which can be used for
>     performance profiling (must wrap correctly)
Hi All,
       Graeme, I think you have stated exactly what is the "best" 
approach to this problem.  I will provide a version of "get_raw_ms" that 
is  initialized using get_raw_tick_rate that will work for all 
"reasonable" values of raw_tick_rate. This will be the "generic" 
solution. Both the initialization function and the get_raw_ms function 
can be overridden if there is reason to do so, like "exact" clock rates. 
I will do the same with get_raw_us. This will be posted sometime on 
Monday for people to review, and to make sure I didn't get too far off 
base. Thank you to both Graeme and Reinhard for looking at/working on 
this.. Hopefully, this solution will put this timing issue to rest for 
all future ports as well as the presently existing ones.
        On a different note, the "graylisting" application is causing 
some (about half) of my replies to the list from showing up. The 
messages are going to the specified individuals correctly, but not 
always to the list. This is apparently because my ISP has so many 
different network address available that the probability of using the 
same one (or same subnet) is not very high. Is there anything that can 
be done about this?

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
>
>