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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot