From 7c4e9ced424be4d36df6a3e3825763e97ee97607 Mon Sep 17 00:00:00 2001 From: Joonsoo Kim Date: Sat, 9 Feb 2013 05:52:45 +0100 Subject: ARM: 7643/1: sched: correct update_sched_clock() If we want load epoch_cyc and epoch_ns atomically, we should update epoch_cyc_copy first of all. This notify reader that updating is in progress. If we update epoch_cyc first like as current implementation, there is subtle error case. Look at the below example. cyc = 9 ns = 900 cyc_copy = 9 == CASE 1 == write cyc = 10 read cyc = 10 read ns = 900 write ns = 1000 write cyc_copy = 10 read cyc_copy = 10 output = (10, 900) == CASE 2 == read cyc = 9 write cyc = 10 write ns = 1000 read ns = 1000 read cyc_copy = 9 write cyc_copy = 10 output = (9, 1000) If atomic read is ensured, output should be (9, 900) or (10, 1000). But, output in example case are not. So, change updating sequence in order to correct this problem. Cc: Signed-off-by: Joonsoo Kim Signed-off-by: Russell King --- arch/arm/kernel/sched_clock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'arch/arm/kernel') diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c index fc6692e2b603..bd6f56b9ec21 100644 --- a/arch/arm/kernel/sched_clock.c +++ b/arch/arm/kernel/sched_clock.c @@ -93,11 +93,11 @@ static void notrace update_sched_clock(void) * detectable in cyc_to_fixed_sched_clock(). */ raw_local_irq_save(flags); - cd.epoch_cyc = cyc; + cd.epoch_cyc_copy = cyc; smp_wmb(); cd.epoch_ns = ns; smp_wmb(); - cd.epoch_cyc_copy = cyc; + cd.epoch_cyc = cyc; raw_local_irq_restore(flags); } -- cgit v1.2.3 From 70264367a243a68b1d5636ffb570183449803cbe Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Mon, 18 Feb 2013 16:36:13 +0100 Subject: ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock When udelay() is implemented using an architected timer, it is wrong to scale loops_per_jiffy when changing the CPU clock frequency since the timer clock remains constant. The lpj should probably become an implementation detail relevant to the CPU loop based delay routine only and more confined to it. In the mean time this is the minimal fix needed to have expected delays with the timer based implementation when cpufreq is also in use. Reported-by: Viresh Kumar Signed-off-by: Nicolas Pitre Tested-by: Viresh Kumar Acked-by: Liviu Dudau Cc: stable@vger.kernel.org Signed-off-by: Russell King --- arch/arm/kernel/smp.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'arch/arm/kernel') diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 84f4cbf652e5..58af91c2a2f7 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -693,6 +693,9 @@ static int cpufreq_callback(struct notifier_block *nb, if (freq->flags & CPUFREQ_CONST_LOOPS) return NOTIFY_OK; + if (arm_delay_ops.const_clock) + return NOTIFY_OK; + if (!per_cpu(l_p_j_ref, cpu)) { per_cpu(l_p_j_ref, cpu) = per_cpu(cpu_data, cpu).loops_per_jiffy; -- cgit v1.2.3