Messages in this thread | | | Date | Sun, 17 Mar 2013 20:05:43 +0000 | From | Will Deacon <> | Subject | 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 03:32:43AM +0000, chpoph wrote: > On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> 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 > message if the CPU delay loop is used in SMP. In my system, the wrong > delay interval fluctuated with CPU frequencies caused a control > problem.
I've been playing around with loops_per_jiffy recently, in an attempt to clean up the cpufreq scaling code so that the SMP-ness is in core code, rather than being duplicated by every architecture:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git lpj
With those changes, it's pretty easy to get different delays depending on the current CPU, but it would require preempt_{enable,disable} calls around the delay, which I haven't convinced myself about.
Do you actually have an ARM platform that can scale the CPU frequencies independently?
Will
| |