[PATCH 1/3] [ARM] Translate delay.S into (mostly) C

[Stephen Boyd]

 On 10/06/2010 01:05 PM, Nicolas Pitre wrote:
> You could use the noinline qualifier from <linux/compiler.h> with those 
> functions you don't want inlined.
>

That won't help me for the interleaving behavior though.

>> Is it possible to do all this in assembly ? Can't you have the default
>> implementation using this assembly with different function names, then
>> just set the assembly function names in C code someplace?
> That weould be my preference too.  Being in assembly means that this 
> code is unlikely to change with different optimization levels and/or gcc 
> versions which would otherwise require different calibration values. 
> Relying on stable calibration is necessary for the lpj kernel cmdline 
> parameter to have some meaning.

Why doesn't any other architecture use assembly for their lpj code? They
may use headers with assembly in them or C code with assembly in them,
but they don't write all of the delay code in assembly and rely on
function interleaving. This leads me to believe other arches aren't
concerned about compiler optimizations breaking lpj cmdline parameters,
so why should ARM be concerned?

I tested the theory out and scaled down the CPU frequency to 19.2 MHz
and then called calibrate_delay(). Before and after applying this series
I got the same results.

Calibrating delay loop... 12.67 BogoMIPS (lpj=63360)

Jumping up to 1.2 GHz and calling calibrate_delay() gives me the same
before and after

Calibrating delay loop... 792.98 BogoMIPS (lpj=3964928)

I don't have access to a machine capable of running slower than 19.2
MHz. Maybe machines running in the KHz range would experience differences?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.