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> Signed-off-by:
Prasad Sodagudi <psodagud@codeaurora.org>
Loading
Please register or sign in to comment