kernel: time: Fix accuracy for low resolution timer
timer wheel calculates the index for any timer based on the expiry
value and level granularity of the timer. Due to the level granularity
timer will not fire at the exact time instead expire at a time value
expires + granularity. This is done in the timer code when the index for
each timer is calculated based on the expiry and granularity at each
level:
expires = (expires + LVL_GRAN(lvl)) >> LVL_SHIFT(lvl);
For devfreq drivers the requirement is to fire the timer at the exact
time. If the timer does not expire at the exact time then it'll take
much longer to react and increase the device frequency. Devfreq driver
registers timer for 10ms expiry and due to slack in timer code the
expirty happens at 20 ms. For eg: Frame rendering time is 16ms.
If devfreq driver reacts after 20ms instead of 10ms, that's
way past a frame rendering time.
Timers with 10ms to 630ms expiry fall under level 0, to overcome the
granularity issue for level 0 with low expirty values do not add the
granularity by introducing a new function calc_index_min_granularity.
With the above approach if the timer interrupt on the cpu is delayed for
a long time then there is a chance of missing the timer if base clk is
forwarded to jiffies. In order to account for this corner case modify
the nex_pending_bucket function to choose the least of expiry.
The next_pending_bucket starts at the index based on base clk value and
increments till the end of the bucket.
------------------------------
| | | | | |
| 0 | 1 | -----------| | 63 |
| | | | | |
------------------------------
^
[start] | [pos] [end]
Above pos is the position based on the current base clk value, current
code looks for first pending timer from pos to end. But there is a
chance that there is pending timer from start to pos which could have
lesser expiry. Modify the implementation to pick the least of the
expiries.
Change-Id: I60f6f4394de4b5f409829de9734645e1a0d7659e
Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
1 file changed