On Tuesday 31 March 2009 04:17:06 Jean-Christophe PLAGNIOL-VILLARD wrote: > 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
the clocksource framework in linux sounds like extreme overkill for u-boot. where do you see realistic usage of more than one timer ? u-boot is pretty much a single threaded app that polls. > 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 do you have real use cases here ? i'd actually propose the opposite: kill off the notion of "ticks", "cycles", and "hz". i dont think ndelay() is really necessary, and mdelay() is a simple macro on top of udelay(). that leaves us with really only the three functions we have today: timer_init(), get_timer(), and reset_timer(). we clarify that the function operates in terms of milliseconds and blam, it's all so simple now. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
