Add an extra millisecond delay to the EmbOS timer
Since the EmbOS timer is a millisecond tick based one, there is a
possibility that the timer can expire slightly ahead of schedule
(from CHRE's perspective) due to a clipping during the ms->ns
time factor conversion. Add an additional millisecond to the
requested delay to account for this.
Bug: 237819962
Test: Run timer world, verify that timers don't expire (a tiny
amount of time) before they are supposed to.
Change-Id: I5669827e4b444e09d20a6a699128f659f143673d
diff --git a/platform/embos/system_timer.cc b/platform/embos/system_timer.cc
index f0cf8ea..64d0677 100644
--- a/platform/embos/system_timer.cc
+++ b/platform/embos/system_timer.cc
@@ -49,10 +49,15 @@
// its timer create API if the values lie beyond the specified interval of
// 1 ≤ Period ≤ 0x7FFFFFFF. Since there's not return value to assess API
// call success, we clamp the delay to the supported interval.
+ // Note that since the EmbOS timer is a millisecond tick timer, an additional
+ // delay of 1ms is added to the requested delay to avoid clipping/zeroing
+ // during the time factor conversion.
+ // TODO(b/237819962): Investigate the possibility of a spare hardware timer
+ // available on SLSI that we can eventually switch to.
constexpr uint64_t kMinDelayMs = 1;
constexpr uint64_t kMaxDelayMs = INT32_MAX;
uint64_t delayMs = Milliseconds(delay).getMilliseconds();
- delayMs = std::min(std::max(delayMs, kMinDelayMs), kMaxDelayMs);
+ delayMs = std::min(std::max(delayMs + 1, kMinDelayMs), kMaxDelayMs);
OS_StopTimerEx(&mTimer);
OS_SetTimerPeriodEx(&mTimer, static_cast<OS_TIME>(delayMs));
