| Message ID | 1272793852-26260-1-git-send-email-rabin@rab.in |
|---|---|
| State | New |
| Headers | show |
On Sun, May 02, 2010 at 03:20:51PM +0530, Rabin Vincent wrote: > 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> Could these patches please be applied? What was then linux-next is now current Linux mainline, and it doesn't boot without this patch. Rabin
On Sun, May 02, 2010 at 03:20:51PM +0530, Rabin Vincent wrote: > 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> Thanks, applied. > --- > hw/arm_timer.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/arm_timer.c b/hw/arm_timer.c > index 9fef191..5b6947a 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. */ > -- > 1.7.0.4 > > > >
diff --git a/hw/arm_timer.c b/hw/arm_timer.c index 9fef191..5b6947a 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. */
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> --- hw/arm_timer.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)