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 ... -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
