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 <ra...@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
>
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
