summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
diff options
context:
space:
mode:
authorBruce Ashfield <bruce.ashfield@windriver.com>2010-11-30 11:51:46 -0500
committerSaul Wold <Saul.Wold@intel.com>2010-12-10 22:01:38 -0800
commitaac5f5c7883595e55e35474ec08033444e13f710 (patch)
treef287e066b12b3034932669845ce027b3ceb1d77a /meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
parent48d00ad8d5134b5bf3215df4faca7c7fd01154eb (diff)
downloadpoky-aac5f5c7883595e55e35474ec08033444e13f710.tar.gz
qemu: update arm timer handling
commit e388771458b4ff3ad81ab70e390b24d069647da4 in the upstream kernel factored/cleaned the SP804 timer code. This commit exposed issues in the qemu timer emulation that was dependent on the old behaviour. As a result, no kernel past 2.6.34 would boot on qemu-system-arm. The quick fix is to backport two patches from the latest qemu repositories that fix the timer handling under emulation. Long term, these will be dropped when qemu is upreved. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Diffstat (limited to 'meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch')
-rw-r--r--meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch40
1 files changed, 40 insertions, 0 deletions
diff --git a/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
new file mode 100644
index 0000000000..1890e21e60
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
@@ -0,0 +1,40 @@
1From d6759902cb467c002086853d2eb38fb969c29f7f Mon Sep 17 00:00:00 2001
2From: Rabin Vincent <rabin@rab.in>
3Date: Sun, 2 May 2010 15:20:51 +0530
4Subject: [PATCH] arm_timer: reload timer when enabled
5
6commit id: d6759902cb467c002086853d2eb38fb969c29f7f in git://git.sv.gnu.org/qemu.git
7
8Reload the timer when TimerControl is written, if the timer is to be
9enabled. Otherwise, if an earlier write to TimerLoad was done while
10periodic mode was not set, s->delta may incorrectly still have the value
11of the maximum limit instead of the value written to TimerLoad.
12
13This problem is evident on versatileap on current linux-next, which
14enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling
15periodic mode and starting the timer. This causes the first periodic
16tick to be scheduled to occur after 0xffffffff periods, leading to a
17perceived hang while the kernel waits for the first timer tick.
18
19Signed-off-by: Rabin Vincent <rabin@rab.in>
20Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
21---
22 hw/arm_timer.c | 2 +-
23 1 files changed, 1 insertions(+), 1 deletions(-)
24
25diff --git a/hw/arm_timer.c b/hw/arm_timer.c
26index 9fef191..5b6947a 100644
27--- a/hw/arm_timer.c
28+++ b/hw/arm_timer.c
29@@ -113,7 +113,7 @@ static void arm_timer_write(void *opaque, target_phys_addr_t offset,
30 case 1: freq >>= 4; break;
31 case 2: freq >>= 8; break;
32 }
33- arm_timer_recalibrate(s, 0);
34+ arm_timer_recalibrate(s, s->control & TIMER_CTRL_ENABLE);
35 ptimer_set_freq(s->timer, freq);
36 if (s->control & TIMER_CTRL_ENABLE) {
37 /* Restart the timer if still enabled. */
38--
391.6.5.2
40