On Thu, May 26, 2011 at 3:44 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk <w...@denx.de> wrote: >> Dear Simon Glass, >> >> In message <BANLkTikWwuymrJtMEHBZkvNgNBK1e=r...@mail.gmail.com> you wrote: >>> >>> Can we have a microsecond one also please? Some sort of microsecond >> >> 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. > > If we implemented a sync_us_timer(), we could either: > > a) Never kick it using an interrupt at all (only kick it in udelay()) > b) Kick it in a much slower interrupt (1ms+ period) > > Remember, the kicking of the sync function does not need to correlate to > the incrementing of the tick counter - Only to the roll-over period > of the tick counter. > > For a 64-bit sub microsecond tick counter, interrupts will probably not > ever be needed (unless the tick frequency is ludicrous - even a nanosecond > tick counter will take 213 days to wrap) so in this case, sync_us_timer() > would be fine Hi Graeme, Well yes, I feel that you either worry about rollover or you use 64-bits. Since you are using 64-bits it shouldn't matter. 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; }. Regards, Simon > > Regards, > > Graeme > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot