Re: udelay function delays the wrong time interval in multiprocessor system, if ARCH_HAS_READ_CURRENT_TIMER is not defined and on current timer is used.

On Sun, Mar 17, 2013 at 08:05:43PM +, Will Deacon wrote: >Do you actually have an ARM platform that can scale the CPU frequencies independently? Yes, my smart phone use Qualcomm's 8x25 and 8064 platform, which can scale the CPU frequencies independently. I test the delay loop, the phone can'

Re: udelay function delays the wrong time interval in multiprocessor system, if ARCH_HAS_READ_CURRENT_TIMER is not defined and on current timer is used.

On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux wrote: > We don't support different CPUs running at different frequencies with > the delay loop. Sorry. Does it means that a timer-based delay implementation must be used to get an accurate delay in SMP. I think it should print a warning

In SMP, every CPU has its own loops_per_jiffy value, __loop_const_udelay time period is not right if two cpus are running in different frequency.

in __loop_const_udelay function, the delayed time period is calculated according to loops_per_jiffy. In SMP, every CPU has its own loops_per_jiffy value, __loop_const_udelay time period is not right if two cpus are running in different frequency. the following is file arch/arm/lib/delay-loop.S /

In function cpu_stop_cpu_callback, BUG_ON(stopper->thread || stopper->enabled || !list_empty(&stopper->works)) is triggered while restarting sometimes.

In function cpu_stop_cpu_callback, BUG_ON(stopper->thread || stopper->enabled || !list_empty(&stopper->works)) is triggered sometimes. /* manage stopper for a cpu, mostly lifted from sched migration thread mgmt */ static int __cpuinit cpu_stop_cpu_callback(struct notifier_block *nfb,