Please sign in to comment.
drivers/timer/nrf_rtc_timer: Fix round-up for rapid tick rates
When the tick rate was less than MIN_DELAY, bumping a "too soon" expiration by just one tick may not be enough and we could theoretically miss the counter. Instead, eliminate the MIN_DELAY computation and write to the spec: NRF guarantees that the RTC will generate an interrupt for a comparator value two cycles in the future. And further, we can test at the set point to see if we "just missed" the interrupt (i.e. zero cycles delay) and flag a synchronous interrupt. So we only need to miss a requested interrupt now for the special case of exactly one cycle in the future, and then we're only late by one cycle. That's optimal. Also fixes an off-by-one in the next cycle computation. By API convention, an ticks argument of one or less means "at the next tick" and not "right now". So we need to add one to the target cycle to avoid incorrectly triggering a synchronous interrupt. This was a non-issue when a tick is longer than a hardware cycle but is needed now. Also handles the edge case with zero latency interrupts (which are unmaskable) which might mess up timing. This was always a problem, but we're more sensitive now and it's comparatively more likely to occur. Signed-off-by: Andy Ross <email@example.com>
- Loading branch information...