ARM: OMAP1: Fix dpll1 reprogramming related issues

According to comments in omap1_select_table_rate(), reprogramming dpll1 is tricky, and should always be done from SRAM.

While being at it, move OMAP730 special case handling inside omap_sram_reprogram_clock().

Created on top of omap-fixes, not yet in mainline as of 3.2-rc3. Tested on Amstrad Delta.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
 arch/arm/mach-omap1/clock.c      |    6 +-----
 arch/arm/mach-omap1/clock_data.c |    7 +++++--
 arch/arm/plat-omap/sram.c        |    3 +++
 3 files changed, 9 insertions(+), 7 deletions(-)

arch/arm/mach-omap1/clock.c +1 -5

index 84ef704..3899176 100644
@@ -215,12 +215,8 @@ int omap1_select_table_rate(struct clk *clk, unsigned long rate)
 	/*
 	 * In most cases we should not need to reprogram DPLL.
 	 * Reprogramming the DPLL is tricky, it must be done from SRAM.
-	 * (on 730, bit 13 must always be 1)
 	 */
-	if (cpu_is_omap7xx())
-		omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val | 0x2000);
-	else
-		omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val);
+	omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val);
 
 	/* XXX Do we need to recalculate the tree below DPLL1 at this point? */
 	ck_dpll1_p->rate = ptr->pll_rate;

arch/arm/mach-omap1/clock_data.c +5 -2

index 1297bb5..4550415 100644
@@ -23,6 +23,7 @@
 #include <plat/clock.h>
 #include <plat/cpu.h>
 #include <plat/clkdev_omap.h>
+#include <plat/sram.h>	/* for omap_sram_reprogram_clock() */
 #include <plat/usb.h>   /* for OTG_BASE */
 
 #include "clock.h"

@@ -933,8 +934,10 @@ void __init omap1_clk_late_init(void)
 	/* Find the highest supported frequency and enable it */
 	if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
 		pr_err("System frequencies not set, using default. Check your config.\n");
-		omap_writew(0x2290, DPLL_CTL);
-		omap_writew(cpu_is_omap7xx() ? 0x3005 : 0x1005, ARM_CKCTL);
+		/*
+		 * Reprogramming the DPLL is tricky, it must be done from SRAM.
+		 */
+		omap_sram_reprogram_clock(0x2290, 0x1005);
 		ck_dpll1.rate = OMAP1_DPLL1_SANE_VALUE;
 	}
 	propagate_rate(&ck_dpll1);

arch/arm/plat-omap/sram.c +3 -0

index 8b28664..312bee8 100644
@@ -224,6 +224,9 @@ static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
 void omap_sram_reprogram_clock(u32 dpllctl, u32 ckctl)
 {
 	BUG_ON(!_omap_sram_reprogram_clock);
+	/* On 730, bit 13 must always be 1 */
+	if (cpu_is_omap7xx())
+		ckctl |= 0x2000;
 	_omap_sram_reprogram_clock(dpllctl, ckctl);
 }
 

Signature · 1 line

1.7.3.4

Quoted 8 lines · Janusz Krzysztofik

According to comments in omap1_select_table_rate(), reprogramming dpll1 is tricky, and should always be done from SRAM.

While being at it, move OMAP730 special case handling inside omap_sram_reprogram_clock().

Created on top of omap-fixes, not yet in mainline as of 3.2-rc3. Tested on Amstrad Delta.

Thanks for looking into these issues. For most of this we should plan on getting them done for the next merge window because we currently rely on Kconfig options for the supported MHz rates. This means that with this change omap1_defconfig will stop booting on most systems as it would try to change to 216MHz. To fix that issue we should allow the boards to set the supported rates before applying this patch.

I'm not sure which of the patches you meant not ready for 3.2-rc. From your comment I would conclude that only patch 3/5, which would really break omap1_defconfig booting on some boards, is questionable, while you posted this comment against patch 1/5, which I don't see how it could break booting, including omap1_defconfig.

Anyway, I hope that the additional patch below is addressing all your concerns.

DPLL1 reprogramming to a different rate is actually blocked inside omap1_select_table_rate(), resulting in the defalut rate of 60 MHz always used instead of the one selected in .config. OTOH, in omap1_defconfig we currently rely on Kconfig options for the supported MHz rates in case of boards which boot with dpll1 not set correctly by their boot loaders.

This means that before we allow for reprogramming of dpll1 rate, we should prevent from incompatible clock rates being selected, otherwise omap1_defconfig will stop booting on boards with imperfect boot loaders, as it would always try to change to 216MHz.

Expand omap1_rate_table with flags for different CPU types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
Hi,
Since there is no response to patch 2a/5 "Remove unsafe clock values from omap1_defconfig" yet, while rc4 is probably almost out:

If there are reasons for keeping high clock rates selected in omap1_defconfig, and those reasons are more important than fixing bugs which prevent some boards from working correctly under 3.2, here is an alternative, low intrusive solution which should allow booting from omap1_defconfig at correct speeds, selected by CPU type. If the idea is acceptable, please review the CPU per clock rate selections I made, since I'm not sure about their correctness, perhaps except CK_1510, which is based on my own experience with Amstrad Delta. I'll fix that if necessary.

arch/arm/mach-omap1/opp_data.c +0 -0

@@ -21,38 +22,52 @@ struct mpu_rate omap1_rate_table[] = {
 	 * armdiv, dspdiv, dspmmu, tcdiv, perdiv, lcddiv
 	 */
 #if defined(CONFIG_OMAP_ARM_216MHZ)

We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options too, right?

Quoted 3 lines · Tony Lindgren

We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options too, right?

Right, but then, perhaps the initial version of patch 2a/5, which already started removing them, from omap1_defconfig for now, then going into the right direction while unblocking another regression fix (3/5), _is_ a good candidate for an rc fix?

Quoted 5 lines · Janusz Krzysztofik

Quoted 3 lines · Tony Lindgren

We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options too, right?

Quoted 4 lines

Right, but then, perhaps the initial version of patch 2a/5, which already started removing them, from omap1_defconfig for now, then going into the right direction while unblocking another regression fix (3/5), _is_ a good candidate for an rc fix?

But we did not allow dpll1 reprogramming earlier either,

so we should
not need to make all these changes during the -rc cycle. I'm suspecting that we've had this same behaviour for a really long time, and we just have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER option set.

So I'm baffled how your board would be booting at a different rate compared to v3.1, it seems that the logic has not changed there. Or else we have some simple bug somewhere.

Care to try to verify at what point your system started booting at 60MHz rate?

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Janusz Krzysztofik

Quoted 3 lines · Tony Lindgren

We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options too, right?

Right, but then, perhaps the initial version of patch 2a/5, which already started removing them, from omap1_defconfig for now, then going into the right direction while unblocking another regression fix (3/5), _is_ a good candidate for an rc fix?

Quoted 1 line

But we did not allow dpll1 reprogramming earlier either,

Wrong. Without OMAP_CLOCKS_SET_BY_BOOTLOADER selected, we always did, but only once, early at boot, before ck_dpll1_p->rate was set first from omap1_clk_init(), and never retried later, that's why that check which I removed with 3/5 was never in the game until e9b7086b80c4d9e354f4edc9e280ae85a60df408.

Quoted 10 lines

so we should
not need to make all these changes during the -rc cycle. I'm suspecting that we've had this same behaviour for a really long time, and we just have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER option set.

So I'm baffled how your board would be booting at a different rate compared to v3.1, it seems that the logic has not changed there. Or else we have some simple bug somewhere.

Quoted 2 lines

Care to try to verify at what point your system started booting at 60MHz rate?

Since e9b7086b80c4d9e354f4edc9e280ae85a60df408, I guess, and it's hard to confirm wituout bisecting the issue with too early sram call, back until things still worked like before map_io related changes. I will do that if you decide we should try to revert.

For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm.

Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate.

Once done, remove no longer needed clock rate configure time options.

Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Tested on Amstrad Delta.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
Hi,
Here is a list of changes against the initial version, submitted as patch 2a/5 v2 "ARM: OMAP1: select clock rate by CPU type" of the series "ARM: OMAP1: Fix dpll1 reprogramming related issues":
* drop no longer needed .config options, as suggested by Tony (thanks!),
* follow selection conditions of those removed .config clock rate options more closely (I missed that before, ended up reinventing the wheel),
* add extra clkdev platform flag for OMAP1710 to be able to limit the 216 MHz rate selection to this SoC subtype only,
* update commit summary and message.

I still wonder if it is sufficient to select a highest rate for a board based on a SoC type only, not on the board type itself. For example, the Amstrad Delta has been used to be running at 150 MHz since it was introduced first, while from now on it will be running at 168 MHz. I haven't noticed any visible issues so far, but who knows... Any opinions?

For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm.

Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate.

Once done, remove no longer needed clock rate configure time options.

Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Tested on Amstrad Delta.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
v2: limit OMAP1510 rate to 150 MHz, or some boards may not work.

Quoted 14 lines · Janusz Krzysztofik

For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm.

Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate.

Once done, remove no longer needed clock rate configure time options.

Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Tested on Amstrad Delta.

Quoted 3 lines

Signed-off-by Janusz Krzysztofik <[email protected]>

---
v2: limit OMAP1510 rate to 150 MHz, or some boards may not work.

Thanks pushing them all into omap1 branch, can you please check that I got all the patches? I've boot tested it here on h2/osk/770.

Quoted 20 lines · Janusz Krzysztofik

Quoted 3 lines · Tony Lindgren

Can you please split your series into two: Fix(es) for the -rc cycle, then patches that can be left for the next merge window.

From my point of view, all 5 are important fixes. Please decide yourself, having the following information provided:

1/5: inspired by in-line comments about running from sram requirement
(works without this one for me),

2/5: without this one, system clock runs way too fast if dpll1 is
reprogrammed to default rate,

3/5: without this one, all boards with bootloaders not setting rate
correctly, like Amstrad Delta, will run at default rate, despite any .config selections, no matter if omap1_defconfig or custom,

2a/5: required by 3/5,

Quoted 4 lines

5/5: without this one, BogoMIPS is not updated after dpll1 reprogramme,
breaking omap_keypad at least.

and please let me know which I should resend as fixes and which not.

How about 2 and 5 as fixes during the -rc, then the rest for the merge window? That is assuming that those are enough for you to have things mostly working.

It seems that we've had the issue of not actually changing the rate for a while, right?

If that's the case, I'd rather not start messing
with that during the -rc cycle.

Regards,

Tony

Anyway, did you mean resending those 2/5 and 5/5 without any changes, only renumbered as 1/2 and 2/2?

If you still ask me for my opinion: with patch 3/5 omitted, then not being able to run at any other frequency than 60 MHz instead of usual 150 since the board support was introduced first, isn't this a regression?

Having a choice of upgrading to 3.2 and running my application on not very powerfull board at 60 MHz, or keep running 3.1 at 150, guess what I chose? If I were a distro kernel package maintainer, guess what I would chose?

Quoted 2 lines

It seems that we've had the issue of not actually changing the rate for a while, right?

This was not an issue before dpll1 reprogramming has been moved out from omap1_clk_init(), as an rc fix to another bug introduced in 3.2. Perhaps we should rather think of reverting a few commits which caused all these problems if fixing them all during rc cycle seems not possible? I haven't bisected them yet, rather concentrated on providing fixes, but I can still try to do it, starting back from the original issue
(http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.

Anyway, did you mean resending those 2/5 and 5/5 without any changes, only renumbered as 1/2 and 2/2?

* Janusz Krzysztofik <[email protected]> [111201 01:20]:

Quoted 6 lines

Perhaps
we should rather think of reverting a few commits which caused all these problems if fixing them all during rc cycle seems not possible? I haven't bisected them yet, rather concentrated on providing fixes, but I can still try to do it, starting back from the original issue
(http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.

We can't revert that because the SRAM init has been moved to later for map_io.

But if that patch changed the behaviour on your board, then that's the problem we should fix.

If you're now stuck at 60MHz rate, care to see if the following patch makes the kernel behave the same way as before for you?

Quoted 11 lines · Tony Lindgren

arch/arm/mach-omap1/clock_data.c +1 -1

@@ -927,7 +927,7 @@ int __init omap1_clk_init(void)
 
 void __init omap1_clk_late_init(void)
 {
-	if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
+	if (ck_dpll1.rate > OMAP1_DPLL1_SANE_VALUE)
 		return;
 

arch/arm/mach-omap1/clock_data.c int __init omap1_clk_init(void) · line 933

Quoted 1 line

arch/arm/mach-omap1/clock_data.c +0 -0

 	/* Find the highest supported frequency and enable it */

This change really makes sense to me, however, knowing the initial (bootloader selected) clock rate my board boots at, which is unfortunately raw 12 MHz, I would be surprised if that helped.

Before e9b7086b80c4d9e354f4edc9e280ae85a60df408, omap1_select_table_rate() was returning the rate selected with .config because it was called early, with ck_dpll1_p->rate uninitialized. Now it is not, and returns nothing, resulting in 60 MHz default. Then, the only way I can see to correct the problem is something like patch 3/5, which you are justifiably affraid of of always switching to 216 MHz with omap1_defconfig.

From: Tony Lindgren <[email protected]>
Date: Thu, 1 Dec 2011 11:00:11 -0800
Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot at rates below 60MHz

Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix reprogramming of dpll1 rate) fixed a regression for systems that did not rely on bootloader set rates.

However, it also introduced a new problem where the rates selected in .config would not take affect as omap1_select_table_rate currently refuses to reprogram DPLL1 if it's already initialized.

This was not a problem earlier, as the reprogramming was done earlier with ck_dpll1_p->rate uninitialized.

Fix this by forcing the reprogramming on systems booting at rates below 60MHz. Note that the long term fix is to make the rates SoC specific later on.

Thanks for Janusz Krzysztofik <[email protected]> for figuring this one out.

Reported-by Janusz Krzysztofik <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap1/clock_data.c +3 -1

index 1297bb5..3f30561 100644
@@ -930,6 +930,9 @@ void __init omap1_clk_late_init(void)
 	if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
 		return;
 
+	/* System booting at unusable rate, force reprogramming of DPLL1 */
+	ck_dpll1_p->rate = 0;
+
 	/* Find the highest supported frequency and enable it */
 	if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
 		pr_err("System frequencies not set, using default. Check your config.\n");
--

To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 23 lines · Tony Lindgren

From: Tony Lindgren <[email protected]>
Date: Thu, 1 Dec 2011 11:00:11 -0800
Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot at rates below 60MHz

Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix reprogramming of dpll1 rate) fixed a regression for systems that did not rely on bootloader set rates.

However, it also introduced a new problem where the rates selected in .config would not take affect as omap1_select_table_rate currently refuses to reprogram DPLL1 if it's already initialized.

This was not a problem earlier, as the reprogramming was done earlier with ck_dpll1_p->rate uninitialized.

Fix this by forcing the reprogramming on systems booting at rates below 60MHz. Note that the long term fix is to make the rates SoC specific later on.

Thanks for Janusz Krzysztofik <[email protected]> for figuring this one out.

Quoted 2 lines

Reported-by Janusz Krzysztofik <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Acked-by Janusz Krzysztofik <[email protected]>

However, this way or another, we are back to your mentioned problem of omap1_defconfig always switching to 216 MHz, I'm afraid. Then, 2a/5 v1 "Remove unsafe clock values from omap1_defconfig" can still be helpful.

Anyway, I'm resending (refreshed) 2/5 and 5/5 as rc fixes as you suggested before, 1/5 "ARM: OMAP1: Fix dpll1 default rate reprogramming method" intended for next, and 2a/5 v2 "ARM: OMAP1: select clock rate by CPU type" also for next but as an RFC.

After dpll1 reprogramming has been moved from setup_arch() to kernel_init(), I've been observing several issues, resulting in undesired system behaviour on my Amstrad Delta. This series fixes those most important (2/5 and 5/5 v2 previously), with a "stuck at 60MHz rate" issue going to be fixed with Tony's proposed solution instead of my previous 3/5.

Janusz Krzysztofik (2):
ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate
ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

 arch/arm/mach-omap1/clock_data.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

Quoted 11 lines · Janusz Krzysztofik

After dpll1 reprogramming has been moved from setup_arch() to kernel_init(), I've been observing several issues, resulting in undesired system behaviour on my Amstrad Delta. This series fixes those most important (2/5 and 5/5 v2 previously), with a "stuck at 60MHz rate" issue going to be fixed with Tony's proposed solution instead of my previous 3/5.

Janusz Krzysztofik (2):
ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate
ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

Quoted 2 lines

 arch/arm/mach-omap1/clock_data.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

Thanks, got these three patches now applied into fixes on top of -rc4.

Can you please try it out to make sure it's all working for you now?

DPLL1 reprogramming to a different rate is actually blocked inside omap1_select_table_rate(), resulting in the defalut rate of 60 MHz always used instead of the one selected in .config. Fix it.

Created against linux-3.2-rc2, tested on Amstrad Delta on top of linux-omap/fixes.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
 arch/arm/mach-omap1/clock.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

arch/arm/mach-omap1/clock.c +0 -4

index 3899176..962adbc 100644
@@ -200,10 +200,6 @@ int omap1_select_table_rate(struct clk *clk, unsigned long rate)
 		if (ptr->xtal != ref_rate)
 			continue;
 
-		/* DPLL1 cannot be reprogrammed without risking system crash */
-		if (likely(dpll1_rate != 0) && ptr->pll_rate != dpll1_rate)
-			continue;
-
 		/* Can check only after xtal frequency check */
 		if (ptr->rate <= rate)
 			break;

Signature · 1 line

1.7.3.4

This is required on ARM OMAP1 platform, after DPLL reprogramming has been fixed by moving it from setup_arch() to kernel_init().

Created against linux-3.2-rc2.

Quoted 4 lines · Janusz Krzysztofik

This is required on ARM OMAP1 platform, after DPLL reprogramming has been fixed by moving it from setup_arch() to kernel_init().

Created against linux-3.2-rc2.

Why do you need this? If you know what the original CPU clock rate and bogomips were, and the new CPU clock rate, then you simply scale the bogomips from the original accordingly. That's what cpufreq does.

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.

Quoted 3 lines · Janusz Krzysztofik

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.

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.

Quoted 6 lines · Russell King - ARM Linux

Quoted 3 lines · Janusz Krzysztofik

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).

Quoted 6 lines

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

Quoted 6 lines · Russell King - ARM Linux

Quoted 3 lines · Janusz Krzysztofik

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).

Quoted 5 lines

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.

Quoted 2 lines · Janusz Krzysztofik

Those were BogoMIPS, ...

I realise that. But which is which - is 70.40 from recalibrate_delay or is it 74.54? Your message is too vague to be able to interpret your results because it's impossible to work out what figure refers to which method.

Quoted 7 lines

... 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 ...

It really doesn't matter - udelay() etc is not designed to be mega accurate but good enough...