[PATCH v2 3/4] Implement clockevents driver for powerpc

[Paul Mackerras]

Gabriel Paubert writes:

> I'd really wish there were a guarantee of a minimum timebase 
> frequency, for anything above ~10MHz, we are splitting hairs
> about an off-by-one error that never accumulates, but if systems
> with very low TB freq exist, you have to be very careful.

Exactly.  In looking through the generic clockevents code, there are a
few places where counts are rounded down.  For example,
clockevents_program_event does this to convert from nanoseconds (in
"delta") to the count value for the clock event device:

	clc = delta * dev->mult;
	clc >>= dev->shift;

Here the right shift can lose up to a whole count.  If the clock
frequency of the device is very slow, say 1kHz, then this could lose
up to 999999 nanoseconds.  Then, on Book E, putting 1 into the
decrementer could result in an interrupt anywhere from straight away to
1 millisecond later (assuming 1kHz timebase frequency, again).

The net result is that delta = 1999999 nanoseconds could result in the
interrupt coming in immediately, i.e. almost 2ms early.

I believe the clockevents framework has not been designed for use with
very slow one-shot clock event devices.  If it is to be used with very
low clock rates, then there are several points where I think the
rounding/truncation issues need to be carefully thought through.

In any case, the code we have at the moment won't work with timebase
clock rates below 15.258kHz, because decrementer_clockevent.mult will
become zero.

Regards,
Paul.