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.
Yes, you are right. Some days ago I found that no proper documentation for the ticks/timer related code is there, too.
From looking at the existing code for some ARM boards (OSK, DaVinci, OMAP3) my idea of this code is:
my understanding is that:
- get_ticks - return some notion of "cpu ticks"
Yes. Returns the number of cpu ticks since power up. I.e. with 1000 ticks per second (CONFIG_SYS_HZ) the number of elapsed ms since power up.
- get_tbclk - return number of "cpu ticks" that elapse in one second
Yes. Some implementations just return CONFIG_SYS_HZ which is supposed to be 1000.
- timer_init - setup a core timer
Some implementations do this in interrupt_init(), too.
- get_timer(x) - not really sure what this is supposed to represent, or how
"x" is used
This is similar to get_ticks(), i.e. returns the number of ticks since power up. Parameter x is used as a base which is subtracted from ticks. With x == 0 this function is the same as get_ticks(). If x != 0 the value returned is
number of ticks since power up - x
- reset_timer - reset core timer to 0
Some implementations don't reset the timer (hw device) itself. They just reset the timestamp counter (sw variable) which counts the ticks since power up (i.e. that is returned by get_ticks()).
- 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)
CONFIG_SYS_HZ is supposed to be 1000
Does this make sense?
Best regards
Dirk