[PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Jun 29, 2011 at 11:29:29AM -0700, Stephen Boyd wrote:
> On 06/28/2011 04:17 PM, Russell King - ARM Linux wrote:
> >
> > That's why people have proposed hardware-timer based delay loops -
> > these screw up the bogomips value (it no longer refers to the CPU
> > but to the timer used for the delays) and the code proposed thus far
> > probably has a severe negative impact on ARMs running at low clock
> > rates (the calculation cost of the number of loops to run becomes
> > significant for CPUs below 100MHz for short delays with the existing
> > optimized assembler, so moving it into C and introducing function
> > pointers will only make it worse.)
> 
> Am I people? ;-)

That depends if you're a multiple personality person!

> The code I've proposed doesn't seem to have a negative impact on our
> targets even when the processor is running at 19.2 Mhz. Before and after
> the patches I get the same lpj value (this is all described in the
> commit text). I've also shown that rewriting delay.S into C doesn't
> negatively affect the hand optimized assembly as the before and after
> object code is nearly identical modulo register allocation. The only
> issue would be the one function pointer which I haven't heard anyone
> complain about until now.
> 
> Even if the time to get into the __delay() routine increases by a few
> instructions I don't see how this harms anything as udelay() is a
> minimum time guarantee. We should strive to make it as close as possible
> to the time requested by the caller, but we shouldn't balk at the
> introduction of a few more cycles along the setup path. Finally, since
> the calibration takes into account most of the new instructions I doubt
> it will even be noticeable overhead to have the function pointers.
> 
> What more can I do to convince you to take this patch?

What I'm aware of is that I did create a kernel-side parport jtag driver,
and the limiting factor in that was udelay(), or rather udelay(1) not
giving a delay of 1us but several us longer - and that was tracked down
to the overhead of the CPU getting into __delay.

So, having experienced that problem I'm over-sensitive towards it...