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

[Wolfgang Denk]

Dear Simon Glass,

In message <BANLkTinxp1wuA9+_EvC0ppK+7Uj89UkN-g at mail.gmail.com> you wrote:
>
> >> I guess you cannot, at least not in general.  In worst case that would
> >> mean we have to process 1e6 interrupts per second, which leaves little
> >> time for anything useful.
> 
> Sorry Wolfgang I don't really understand this. We would only process
> when we read it, and then hopefully only a simple multiple or shift,
> after compiler optimizations kick in. Probably I am just missing what
> you are saying.

You assume that there is a counter register that can be read.  This
may not be the case. You may have just a timer which fires an
interrupt every X time units, so you can implement a counter in the
ISR.  This is for examole how the tick is implemented on PPC now:  we
get an interrupt every millisecond and increment a counter then.

For a microsecond tick you need in such a setup one million
interrupts per second.

> I hope we can avoid integer division in the microsecond case. Someone
> stated that time delays are the main use for the timer, but some of us
> have performance-monitoring plans.
> 
> Re the atomicity of handling 64-bit numbers, how about just
> disable/enable interrupts around this? I think 64-bit is overkill but
> at least it is simple, and prefer a u64 to a struct { u32 lo, hi; }.

Enabling and disabling interrupts is not exactly performance-neutral
either.

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
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
         -- Tom Christiansen in <6bo3fr$pj8$5 at csnews.cs.colorado.edu>