[U-Boot] core ticks/timer code

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:30 Fri 27 Mar     , Mike Frysinger wrote:
> the Blackfin core tick/timer code has been around since the start of the 
> original port, but i'm not sure it's entirely correct.  some common code that 
> uses timers seems to be misbehaving in that the timeout is pretty much 
> immediate.  makes me think that we've spent time on making udelay() work, but 
> then just glossed over the rest.
> 
> unfortunately, there doesnt seem to be any docs on what exactly these 
> functions do so it's hard for me to verify/change any of it.
> 
> my understanding is that:
>  - get_ticks - return some notion of "cpu ticks"
>  - get_tbclk - return number of "cpu ticks" that elapse in one second
>  - timer_init - setup a core timer
>  - get_timer(x) - not really sure what this is supposed to represent, or how 
> "x" is used
>  - reset_timer - reset core timer to 0
>  - CONFIG_SYS_HZ - no idea how this relates to ticks/timer in U-Boot as in the 
> Linux world, this is the core timer (scheduler) frequency (how many times to 
> execute per second)

I've take a look on the current timer API and I've a lot of limitation on it
as example on bitbanging we can not generate a clock over 200Khz or near
as you said the API is dark

I've in mind to partially import the clocksource linux API or create a new
U-Boot api devired from it's design

I'll propose a new design with the following Requierement

Generic delay function implementation
 - ndelay()
 - udelay()
 - mdelay()

Generic helper
 - khz2cycles()
 - hz2cycles()
 - cs2ns()

Timer API
 - timer_init()		- setup the timer
 - timer_reset()	- reset the timer (use in case of overflow)
 - get_ticks()		- return the current ticks
 - get_cycles()		- return the ticks frequency in ns

Best Regards,
J.