Dear Simon Glass,
In message <[email protected]> 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: [email protected]
The use of Microsoft crippleware systems is a sin that carries with
it its own punishment.
-- Tom Christiansen in <[email protected]>
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
