Hi, Ralf, This is a problem, but it seems not a very big problem. Because X86 also use percpu's loops_per_jiffy to implement udelay(), and percpu's loops_per_jiffy also adjusted after cpufreq transition. Please look at arch/x86/lib/delay.c, arch/x86/kernel/tsc.c. Huacai On Thu, Mar 26, 2015 at 9:05 PM, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote: > On Fri, Mar 13, 2015 at 10:30:36AM +0800, Huacai Chen wrote: > >> Loongson-3A/3B support frequency scaling. But due to hardware >> limitation, Loongson-3A's frequency scaling is not independent for >> each core, we suggest enable Loongson-3A's CPUFreq only when there is >> one core online. Loongson-3B can adjust frequency independently for >> each core, so it can be always enabled. >> >> Each package has only one register (ChipConfig or FreqCtrl) to control >> frequency, so we need spinlocks to protect register access for multi- >> cores. However, we cannot use spinlock when a core becomes into "wait" >> status (frequency = 0), so we only enable "wait" when there is one core >> in a package online. >> >> arch/mips/kernel/smp.c is modified to guarantee udelay_val has the >> correct value while both CPU hotplug and CPUFreq are enabled. > > With clockscaling you have a fundamental problem with udelay. If the clock > is increased for a CPU that already has computed the number of iterations > of the delay loop for the old, lower clock rate, it is possible that > udelay won't wait for long enough. > > The opposite case would result in waiting too long but that's not a big > problem as udelay only guarantees a minimum waiting time. > > So you probably need a different delay mechanism than the classic delay > loop on SMP with clockscaling. > > Ralf >
