b1280108a2
The logic about minimal sleep sizes due to "tick" aliasing was correct, but drivers also have similar behavior with "cycle" aliasing too. When cycles are 3-4 orders of magnitude faster than ticks, it's undetectable noise. But now on nRF they're exactly the same and we need to correct for that, essentially doubling the number of ticks a usleep() might wait for. The logic here was simply too strict, basically. Fast tick rates can't guarantee what the test promised. Note that this relaxes the test bounds on the other side of the equation too: it's no longer an error to usleep() for only one tick (i.e. an improved sleep/timeout implementation no longer gets detected as a test failure). Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| main.c | ||
| usleep.c | ||