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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
