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.