On Thu, 8 May 2014, Russell King - ARM Linux wrote:
> If you're in a preempt or SMP environment, provide a timer for udelay().
> IF you're in an environment with IRQs which can take a long time, use
> a timer for udelay(). If you're in an environment where the CPU clock
> can change unexpectedly, use a timer for udelay().
Longer delays are normally not a problem. If they are, then simply
disabling IRQs may solve it if absolutely required. With much shorter
delays than expected this is another story.
What about the following:
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada440..10030cc5a0 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -682,6 +682,15 @@ static int cpufreq_callback(struct notifier_block *nb,
cpufreq_scale(per_cpu(l_p_j_ref, cpu),
per_cpu(l_p_j_ref_freq, cpu),
freq->new);
+ /*
+ * Another CPU might have called udelay() just before LPJ
+ * and a shared CPU clock is increased. That other CPU still
+ * looping on the old LPJ value would return significantly
+ * sooner than expected. The actual fix is to provide a
+ * timer based udelay() implementation instead.
+ */
+ if (freq->old < freq->new)
+ pr_warn_once("*** udelay() on SMP is racy and may be
much shorter than expected ***\n");
}
return NOTIFY_OK;
}
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
