On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote:

On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:

quoted

However, the result of cpufreq_scale() differs from that of
(re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise if
this approximation is acceptable.

You don't say which figure is what.

Hi,
Those were BogoMIPS, which you were talking about in your comment 
(http://www.spinics.net/lists/linux-omap/msg60811.html).

Note that calibrate_delay() is itself inaccurate - the loops_per_jiffy
is the number of loops which can be executed between two timer ticks
_minus_ the time to process the timer interrupt itself.  So, it's
actually always a little less than the theoretical number of loops
within that time period.

I see. Then, in case of a machine always booting at, let's say, 12 and then reprogrammed to 150 MHz, we actually scale up that less then the theoretical number, with a side effect of scaling up its error as well. Perhaps in this case, when the machine is going to run at that target rate until rebooted, we should rather decide to recalibrate to keep that error proportionally small compared to the target loops per jiffy value, like it worked in my initial proposal? I think that your argument about unnecessarily wasting 10s of milliseconds has marginal importance here because we will be redoing that calibration only once, at boot time, and never later until next reboot.

Thanks,
Janusz