Patchwork [1/2] arm_timer: reload timer when enabled

login
register
mail settings
Submitter Rabin Vincent
Date May 2, 2010, 9:50 a.m.
Message ID <1272793852-26260-1-git-send-email-rabin@rab.in>
Download mbox | patch
Permalink /patch/51462/
State New
Headers show

Comments

Rabin Vincent - May 2, 2010, 9:50 a.m.
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(-)
Rabin Vincent - May 20, 2010, 5:27 p.m.
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
Aurelien Jarno - May 21, 2010, 10 a.m.
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
> 
> 
> 
>

Patch

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.  */