Dear Mike Frysinger,
In message 200903310513.09082.vapier@gentoo.org you wrote:
...
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.
Correct. We definitely do not need the full capabilities of the Linux framework. Any new implementation will be checked against the current code, and memory foot print is something we will check carefully.
OTOH, I think Sascha's u-boot-v2 uses code that was derived from the Linux code, but in a pretty lean way. It may be interesting to check there...
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.
Agreed (except that we probably cannot completely throw away the tick; IIRC there are cases in early startup when nothing else is available yet).
Best regards,
Wolfgang Denk