| commit | d6759902cb467c002086853d2eb38fb969c29f7f | |
| author | Rabin Vincent <rabin@rab.in> | |
| Sun, 2 May 2010 09:50:51 +0000 (2 15:20 +0530) | ||
| committer | Aurelien Jarno <aurelien@aurel32.net> | |
| Fri, 21 May 2010 10:00:22 +0000 (21 12:00 +0200) | ||
| tree | f62f98c19ad44496248f42fa1342cfc10745e4e7 | treesnapshot (tar.gz zip) |
| parent | 0b2ec6fcfdad1dd9ce74c50e2d752afbb627b0d0 | commitdiff |
arm_timer: reload timer when enabled
Reload the timer when TimerControl is written, if the timer is to be
enabled. Otherwise, if an earlier write to TimerLoad was done while
periodic mode was not set, s->delta may incorrectly still have the value
of the maximum limit instead of the value written to TimerLoad.
This problem is evident on versatileap on current linux-next, which
enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling
periodic mode and starting the timer. This causes the first periodic
tick to be scheduled to occur after 0xffffffff periods, leading to a
perceived hang while the kernel waits for the first timer tick.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reload the timer when TimerControl is written, if the timer is to be
enabled. Otherwise, if an earlier write to TimerLoad was done while
periodic mode was not set, s->delta may incorrectly still have the value
of the maximum limit instead of the value written to TimerLoad.
This problem is evident on versatileap on current linux-next, which
enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling
periodic mode and starting the timer. This causes the first periodic
tick to be scheduled to occur after 0xffffffff periods, leading to a
perceived hang while the kernel waits for the first timer tick.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
| hw/arm_timer.c | diffblobblamehistory |