ipipe/timer: apply minimum delay on close timer shot
When programming the timer, eagerly raising a timer IRQ by software via the pipeline for close shots (i.e. below the clock chip's minimum delay) may cause such event to happen too early for the co-kernel to actually deliver it to any handler, which in turn may trigger yet another request for programming the timer with too close a delay, and so on, until the current time eventually matches some pending event date. In such a case, the system may spend a lot of time trying to converge on a proper trigger date by looping into the clock event handling logic, delaying the co-kernel by the same amount. To fix this, always go through the clock hardware for programming a close shot with the minimum acceptable delay, which ensures that we won't receive the next timer event too early.
Showing with 3 additions and 2 deletions