[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

Wolfgang Denk
2011-05-26T20:27:13Z

Dear "J. William Campbell",

In message <4DDEAFE0.8060905@comcast.net> you wrote:
>
> I certainly agree using 64 bits for all calculations is vast overkill.
> In fact, I think using 64 bit calculations on systems that have only a
> 32 bit or less timer register is probably overkill. :-) However, to
> date,AFAIK, no processor has exceeded the u32 in ticks per second. As I

Not yet. But it makes no sense to start a new design with settings
already in critical range, especially since there is zero problem
with breaking it down by a factor of 1000 or 1e6.

> pointed out in a previous e-mail, if they ever do this, we can just drop
> one or 2 bits off the 64 bit counter and in millisecond resolution,
> nobody will ever know. Also as previously pointed out, usec2ticks is

No. I will not accept a design that is so close on the edge of
breaking.

What is your exact problem with the existing interfaces ticks2usec()
and usec2ticks() ?

> not present yet in lots of implementations. Also, if the fundamental
> clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is
> 0! This probably rules out using it to get ticks per millisec or ticks
> per sec.

The statement "usec2ticks is 0" makes absolutely no sense as long as
you don't say which argument you pass in. You get a return value of
0 even for a tick rate in the GHz range if you pass 0 as argument.

Hoewver, usec2ticks(1000) or maybe usec2ticks(100000) will probably
return pretty useful values.

[Note that by passing properly scaled arguments you can also avoid a
number of rounding errors.]

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke