Add ARCH_PROVIDES_UDELAY config option

On SMP kernels, the loops_per_jiffy value is not scaled due to the possibility of one CPU affecting the speed of another CPU while the second CPU is in a udelay loop. ?Since loops_per_jiffy is calculated once on boot for SMP kernels, udelays are too long if the CPU frequency is scaled down from the boot frequency, or too short if the frequency is scaled up. ?Some SOCs have a timer with a constant tick rate that can be used to time udelays, similar to the TSC on x86. Provide a config flag to allow these SOCs to override the default ARM udelay implementation.

Signed-off-by Colin Cross <[email protected]>

---

?arch/arm/Kconfig ? ? ? ? ? ? | ? ?3 +++
?arch/arm/include/asm/delay.h | ? ?4 ++++
?arch/arm/lib/Makefile ? ? ? ?| ? ?6 +++++-

?3 files changed, 12 insertions(+), 1 deletions(-)

arch/arm/Kconfig +0 -0

index 33d2825..d9923b0 100644
@@ -175,6 +175,9 @@ config ARM_L1_CACHE_SHIFT_6

? ? ? ?help
? ? ? ? ?Setting ARM L1 cache line size to 64 Bytes.

arch/arm/Kconfig +3 -0

+config ARCH_PROVIDES_UDELAY
+ ?bool
+

?if OPROFILE

?config OPROFILE_ARMV6

arch/arm/include/asm/delay.h +0 -0

index b2deda1..57f1fa0 100644
@@ -8,6 +8,9 @@
 

?#include <asm/param.h> /* HZ */

arch/arm/include/asm/delay.h +3 -0

+#ifdef CONFIG_ARCH_PROVIDES_UDELAY
+#include <mach/delay.h>
+#else

?extern void __delay(int loops);

?/*

arch/arm/include/asm/delay.h +1 -0

@@ -40,5 +43,6 @@ extern void __const_udelay(unsigned long);
 ? ? ? ? ? ? ? ? ? ? ? ?__const_udelay((n) * ((2199023U*HZ)>>11))) : ? ?\
 ? ? ? ? ?__udelay(n))
 
+#endif /* defined(ARCH_PROVIDES_UDELAY) */

?#endif /* defined(_ARM_DELAY_H) */

arch/arm/lib/Makefile +1 -1

index 030ba72..aa449e3 100644
@@ -6,7 +6,7 @@
 
 ?lib-y ? ? ? ? ?:= backtrace.o changebit.o csumipv6.o csumpartial.o ? \
 ? ? ? ? ? ? ? ? ? csumpartialcopy.o csumpartialcopyuser.o clearbit.o \
- ? ? ? ? ? ? ? ? ?delay.o findbit.o memchr.o memcpy.o ? ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? ? ?findbit.o memchr.o memcpy.o ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ? ? ? ? ? ? memmove.o memset.o memzero.o setbit.o ? ? ? ? ? ? ?\
 ? ? ? ? ? ? ? ? ? strncpy_from_user.o strnlen_user.o ? ? ? ? ? ? ? ? \
 ? ? ? ? ? ? ? ? ? strchr.o strrchr.o ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \

@@ -17,6 +17,10 @@ lib-y ? ? ? ? ? ? ? ?:= backtrace.o changebit.o csumipv6.o csumpartial.o ? \
 

?mmu-y ?:= clear_user.o copy_page.o getuser.o putuser.o

arch/arm/lib/Makefile +4 -0

+ifneq ($(CONFIG_ARCH_PROVIDES_UDELAY),y)
+ ?lib-y += delay.o
+endif
+

?# the code in uaccess.S is not preemption safe and ?# probably faster on ARMv3 only
?ifeq ($(CONFIG_PREEMPT),y)
--
1.5.4.3

An alternative to this patch would be to add a config option to use sched_clock() to provide the counter instead of the cycle loop. The same loops_per_jiffy calibration could be done to determine the sched_clock frequency. Any machine with an available constant tick rate counter, which is likely to be used for sched_clock() already, can enable CONFIG_UDELAY_USES_SCHED_CLOCK.

Quoted 11 lines

On SMP kernels, the loops_per_jiffy value is not scaled due to the possibility of one CPU affecting the speed of another CPU while the second CPU is in a udelay loop. ?Since loops_per_jiffy is calculated once on boot for SMP kernels, udelays are too long if the CPU frequency is scaled down from the boot frequency, or too short if the frequency is scaled up. ?Some SOCs have a timer with a constant tick rate that can be used to time udelays, similar to the TSC on x86. Provide a config flag to allow these SOCs to override the default ARM udelay implementation.

Signed-off-by Colin Cross <[email protected]>

Quoted 6 lines · Colin Cross

An alternative to this patch would be to add a config option to use sched_clock() to provide the counter instead of the cycle loop. The same loops_per_jiffy calibration could be done to determine the sched_clock frequency. Any machine with an available constant tick rate counter, which is likely to be used for sched_clock() already, can enable CONFIG_UDELAY_USES_SCHED_CLOCK.

Or even better, why not have an option to use the clocksource which is most likely using the constant tick timer as well.

Kevin

Quoted 12 lines · Colin Cross

Quoted 11 lines

On SMP kernels, the loops_per_jiffy value is not scaled due to the possibility of one CPU affecting the speed of another CPU while the second CPU is in a udelay loop. Since loops_per_jiffy is calculated once on boot for SMP kernels, udelays are too long if the CPU frequency is scaled down from the boot frequency, or too short if the frequency is scaled up. Some SOCs have a timer with a constant tick rate that can be used to time udelays, similar to the TSC on x86. Provide a config flag to allow these SOCs to override the default ARM udelay implementation.

Signed-off-by Colin Cross <[email protected]>

Quoted 6 lines · Colin Cross

An alternative to this patch would be to add a config option to use sched_clock() to provide the counter instead of the cycle loop. The same loops_per_jiffy calibration could be done to determine the sched_clock frequency. Any machine with an available constant tick rate counter, which is likely to be used for sched_clock() already, can enable CONFIG_UDELAY_USES_SCHED_CLOCK.

Or even better, why not have an option to use the clocksource which is most likely using the constant tick timer as well.

Quoted 10 lines · Kevin Hilman

Quoted 6 lines · Colin Cross

An alternative to this patch would be to add a config option to use sched_clock() to provide the counter instead of the cycle loop. The same loops_per_jiffy calibration could be done to determine the sched_clock frequency. Any machine with an available constant tick rate counter, which is likely to be used for sched_clock() already, can enable CONFIG_UDELAY_USES_SCHED_CLOCK.

Or even better, why not have an option to use the clocksource which is most likely using the constant tick timer as well.

We may be running into the same problem which we did with the printk clock - that is using a machine provided sched_clock() or clocksource requires MMIO accesses, which can only be done after the IO mappings have been initialized.

Let's hope no one ever uses udelay() before the necessary IO mappings are present.

Quoted 7 lines · Russell King - ARM Linux

We may be running into the same problem which we did with the printk clock - that is using a machine provided sched_clock() or clocksource requires MMIO accesses, which can only be done after the IO mappings have been initialized.

Let's hope no one ever uses udelay() before the necessary IO mappings are present.

Is the patch that uses CONFIG_ARCH_PROVIDES_UDELAY acceptable? I don't care much for how each arch decides to implement it, but I think we should have this config to let each arch decide how they want to handle udelay.

I personally prefer not to use the sched clock source due to the unnecessary complexities. If you have a some kind of constant counter, it sounds much simpler to just use it instead of adding dependencies between udelay and sched clock.

Quoted 13 lines · Saravana Kannan

Quoted 7 lines · Russell King - ARM Linux

We may be running into the same problem which we did with the printk clock - that is using a machine provided sched_clock() or clocksource requires MMIO accesses, which can only be done after the IO mappings have been initialized.

Let's hope no one ever uses udelay() before the necessary IO mappings are present.

Is the patch that uses CONFIG_ARCH_PROVIDES_UDELAY acceptable? I don't care much for how each arch decides to implement it, but I think we should have this config to let each arch decide how they want to handle udelay.

Quoted 4 lines

I personally prefer not to use the sched clock source due to the unnecessary complexities. If you have a some kind of constant counter, it sounds much simpler to just use it instead of adding dependencies between udelay and sched clock.

My point is not specific to sched_clock, but to counters which on ARM are 99.9% always memory mapped, and therefore inaccessible during the very early kernel boot. sched_clock was merely an illustration of the problem.

My point is not specific to sched_clock, but to counters which on ARM are 99.9% always memory mapped, and therefore inaccessible during the very early kernel boot. sched_clock was merely an illustration of the problem.

Quoted 4 lines · Russell King - ARM Linux

My point is not specific to sched_clock, but to counters which on ARM are 99.9% always memory mapped, and therefore inaccessible during the very early kernel boot. sched_clock was merely an illustration of the problem.

Do you know any code which uses udelay that early? I can't imagine any non-driver code using udelay. If it's just drivers using udelay, then they need IO mapping to have been completed for the device register access to work and hence udelay won't have any problems.

-Saravana

Russel,

Would appreciate your thoughts on this.

Colin,

Are you continuing to use the approach used in your patch in your development tree? I just want to make sure we have a solution that everyone can agree to.

Thanks,
Saravana

Quoted 15 lines · Saravana Kannan

Quoted 5 lines · Russell King - ARM Linux

My point is not specific to sched_clock, but to counters which on ARM are 99.9% always memory mapped, and therefore inaccessible during the very early kernel boot. ?sched_clock was merely an illustration of the problem.

Do you know any code which uses udelay that early? I can't imagine any non-driver code using udelay. If it's just drivers using udelay, then they need IO mapping to have been completed for the device register access to work and hence udelay won't have any problems.

-Saravana