Otherwise timing is inaccurate, resulting in devices which depend on
delay(), like omap-keypad, broken.
Created and tested on top of linux-omap/fixes on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx>
Cc: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
---
Hi,
This version no longer depends on changes to init/calibrate.c, using the
method kindly advised by Russell instead. Then, patch 4/5 can be
dropped.
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.
Thanks,
Janusz
arch/arm/mach-omap1/clock_data.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 201b1f2..e616042 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -16,6 +16,8 @@
#include <linux/kernel.h>
#include <linux/clk.h>
+#include <linux/cpufreq.h>
+#include <linux/delay.h>
#include <linux/io.h>
#include <asm/mach-types.h> /* for machine_is_* */
@@ -928,7 +930,9 @@ int __init omap1_clk_init(void)
void __init omap1_clk_late_init(void)
{
- if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
+ unsigned long rate = ck_dpll1.rate;
+
+ if (rate >= OMAP1_DPLL1_SANE_VALUE)
return;
/* Find the highest supported frequency and enable it */
@@ -942,4 +946,5 @@ void __init omap1_clk_late_init(void)
}
propagate_rate(&ck_dpll1);
omap1_show_rates();
+ loops_per_jiffy = cpufreq_scale(loops_per_jiffy, rate, ck_dpll1.rate);
}
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
