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

Graeme Russ
2011-05-23T05:25:58Z

On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
<jwilliamcampbell@comcast.net> wrote:
> 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.

Great - I am in the middle of cleaning up the current usages of the timer
API, reducing it all down to get_timer() - I will then 'libify'
get_timer() and setup the hooks into the HAL get_raw_ticks() and
get_raw_tick_rate() API

I think there will need to be a lot of cleanup, especially in arch/arm to
get this to all fit

Regards,

Graeme