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. - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
