On 07:25 Tue 31 Mar , Mike Frysinger wrote:
On Tuesday 31 March 2009 06:28:23 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
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).
hrm, i can see that. but you agree that most use of ticks in common code can be converted to get_timer() ? on Blackfin systems (and it isnt alone going by a grep), the ticks interface simply returns get_timer(0), so clearly we should be able to convert common code to all use get_timer(0). that'd leave the ticks interface as optional ... for the systems that need early time sources, they can implement/use it as they need without bringing down everyone else.
i wouldnt mind starting a patch series for post 2009.05 to clean this up ...
I've in mind too maybe I'll send a first version within few days for a arm soc and a blackfin based on u-boot-v2
Best Regards, J.