udelay() broken for SMP cores?

[pavel@ucw.cz (Pavel Machek)]

Hi!

> > Is this an ARM specific decision? Cpufreq certainly supports per cpu scaling
> > and x86 udelay uses per-CPU data. So your concern should apply for x86
> > too. I had the same concern and was planning on bring it up in the cpufreq
> > mailing list after I made sure I didn't misunderstand anything.
> 
> Well, x86 looks buggy in this regard as well - the loops_per_jiffy
> value used is for a CPU which may not run the delay loop.

x86 assumes all cores to be essentially same.

> > Btw, your concern should apply for single core scaling too, right? Context
> > switch can complete within max udelay (general - 5ms, ARM - 2ms) time and
> > CPU could have jumped
> > from lowest to highest speed in that time and mess up udelay. I didn't see
> > any code in cpufreq that deferred scaling during udelay. So, that's something
> > I plan to ask cpufreq folks too.
> 
> Well, the assumption is that the CPUs will be running at their fastest
> speed at boot time, and therefore loops_per_jiffy will be calibrated
> such that we guarantee _at least_ the asked-for delay - which is the
> only guarantee udelay has.

Well, some machines can't reach max cpu speed on battery power, so
there may be a problem there.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html