summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRabin Vincent <rabin@rab.in>2010-05-02 15:20:51 +0530
committerAurelien Jarno <aurelien@aurel32.net>2010-05-27 15:52:52 +0200
commit72d3457e8d7c2e45d16acbc4b430c2cb566cedba (patch)
tree87114ced9782558290e72e92bd55b779a25c6e31
parentqemu-sockets: avoid strlen of NULL pointer (diff)
downloadqemu-kvm-72d3457e8d7c2e45d16acbc4b430c2cb566cedba.tar.gz
qemu-kvm-72d3457e8d7c2e45d16acbc4b430c2cb566cedba.tar.bz2
qemu-kvm-72d3457e8d7c2e45d16acbc4b430c2cb566cedba.zip
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> (cherry picked from commit d6759902cb467c002086853d2eb38fb969c29f7f)
-rw-r--r--hw/arm_timer.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/hw/arm_timer.c b/hw/arm_timer.c
index 9fef191cb..5b6947a16 100644
--- a/hw/arm_timer.c
+++ b/hw/arm_timer.c
@@ -113,7 +113,7 @@ static void arm_timer_write(void *opaque, target_phys_addr_t offset,
case 1: freq >>= 4; break;
case 2: freq >>= 8; break;
}
- arm_timer_recalibrate(s, 0);
+ arm_timer_recalibrate(s, s->control & TIMER_CTRL_ENABLE);
ptimer_set_freq(s->timer, freq);
if (s->control & TIMER_CTRL_ENABLE) {
/* Restart the timer if still enabled. */