On Mon, Sep 05, 2005 at 09:32:21AM +0100, Russell King wrote:
> When you have a timer which constantly increments from 0 to MAX and
> wraps, and you can set the value to match to cause an interrupt,
> it makes more sense to handle it the way we're doing it (which
> incidentally leads to no loss of precision.)
> Calculating the number of ticks missed, updating the kernel time,
> and updating the timer match will cause problems with these - if
> the timer has already past the number of ticks you originally
> calculated, you may not get another interrupt for a long time.
>
> So I don't actually think that your proposal will work for these
> (SA11x0 and PXA).
I presume you are referring to code as in omap_32k_timer_interrupt
which calculates lost ticks as well as updates wall-time and
sets up the next interrupt (BTW doesnt 'now' need to be
refreshed everytime in the loop otherwise will cause the problem
you cite - may not get interrupt for a long time?). Tony,
that may have cause slow bootups for you :)
I am not saying that all the above be done from the callee. In fact
in case of ARM, the same handler can be called from dyn_tick_interrupt.
Having some form of 'dyn_tick_interrupt' makes sense because
it encapsulates functionalities like:
- If CPU is not sleeping currently, return (which can happen in SMP)
- Reset the CPU from the bitmap, under the cover of a spinlock
- Recover wall-time if we are coming out of 'all-cpus-were-asleep'
state. In case of ARM, dyn_tick_timer->handler could be called
for this purpose.
> This seems to only recover one tick. What if multiple ticks were lost?
cur_timer->mark_offset() recovers the rest.
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
