kernel.git/arch/arm/lib/delay.c, branch linux-3.8.y

ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock

2013-03-14T18:26:09Z

commit 70264367a243a68b1d5636ffb570183449803cbe upstream. 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 Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: export default read_current_timer

2012-10-09T18:24:36Z

read_current_timer is used by get_cycles since "ARM: 7538/1: delay: add registration mechanism for delay timer sources", and get_cycles can be used by device drivers in loadable modules, so it has to be exported. Without this patch, building imote2_defconfig fails with ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined! Signed-off-by: Arnd Bergmann Cc: Stephen Boyd Cc: Jonathan Austin Cc: Will Deacon Cc: Russell King

ARM: 7538/1: delay: add registration mechanism for delay timer sources

2012-09-26T21:57:52Z

The current timer-based delay loop relies on the architected timer to initiate the switch away from the polling-based implementation. This is unfortunate for platforms without the architected timers but with a suitable delay source (that is, constant frequency, always powered-up and ticking as long as the CPUs are online). This patch introduces a registration mechanism for the delay timer (which provides an unconditional read_current_timer implementation) and updates the architected timer code to use the new interface. Reviewed-by: Stephen Boyd Signed-off-by: Jonathan Austin Signed-off-by: Will Deacon Signed-off-by: Russell King

ARM: 7452/1: delay: allow timer-based delay implementation to be selected

2012-07-09T16:42:23Z

This patch allows a timer-based delay implementation to be selected by switching the delay routines over to use get_cycles, which is implemented in terms of read_current_timer. This further allows us to skip the loop calibration and have a consistent delay function in the face of core frequency scaling. To avoid the pain of dealing with memory-mapped counters, this implementation uses the co-processor interface to the architected timers when they are available. The previous loop-based implementation is kept around for CPUs without the architected timers and we retain both the maximum delay (2ms) and the corresponding conversion factors for determining the number of loops required for a given interval. Since the indirection of the timer routines will only work when called from C, the sa1100 sleep routines are modified to branch to the loop-based delay functions directly. Tested-by: Shinya Kuribayashi Reviewed-by: Stephen Boyd Signed-off-by: Will Deacon Signed-off-by: Russell King