Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in freq-table. This also makes cpufreq stats
inconsistent as cpufreq-stats would fail to register because current frequency
of CPU isn't found in freq-table.
Because we don't want this change to effect boot process badly, we go for the
next freq which is >= policy->cur ('cur' must be set by now, otherwise we will
end up setting freq to lowest of the table as 'cur' is initialized to zero).
In case where CPU is already running on one of the frequencies present in
freq-table, this would turn into a dummy call as __cpufreq_driver_target() would
return early.
Reported-by: Carlos Hernandez <ceh(a)ti.com>
Reported-by: Nishanth Menon <nm(a)ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
After lots of discussion with Nishanth and others, I feel something like this..
@Nishanth: Please see if this works for you and I hope we don't need any of
these patches anymore:
- https://lkml.org/lkml/2013/11/15/569 : cpufreq: cpufreq-cpu0: Use a sane boot
frequency when booting with a mismatched bootloader configuration
- https://lkml.org/lkml/2013/11/15/503 : cpufreq: stats: Do not populate stats
when policy->cur has no exact match
- https://lkml.org/lkml/2013/11/19/16 : cpufreq/stats: Add "unknown" frequency
field in stats tables
drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..d55c843 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1038,6 +1038,32 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
}
}
+ /*
+ * Sometimes boot loaders set CPU frequency to a value outside of
+ * frequency table present with cpufreq core. In such cases CPU might be
+ * unstable if it has to run on that frequency for long duration of time
+ * and so its better to set it to a frequency which is specified in
+ * freq-table. This also makes cpufreq stats inconsistent as
+ * cpufreq-stats would fail to register because current frequency of CPU
+ * isn't found in freq-table.
+ *
+ * Because we don't want this change to effect boot process badly, we go
+ * for the next freq which is >= policy->cur ('cur' must be set by now,
+ * otherwise we will end up setting freq to lowest of the table as 'cur'
+ * is initialized to zero).
+ *
+ * In case where CPU is already running on one of the frequencies
+ * present in freq-table, this would turn into a dummy call as
+ * __cpufreq_driver_target() would return early.
+ */
+ if (has_target()) {
+ ret = __cpufreq_driver_target(policy, policy->cur,
+ CPUFREQ_RELATION_L);
+ if (ret)
+ pr_err("%s: Unable to set frequency from table: %d\n",
+ __func__, ret);
+ }
+
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
--
1.7.12.rc2.18.g61b472e
Hi,
As a part of daily validation of linux-next -> vexpress on vexpress-a9,
These kernel CI jobs builds daily linux-next with vexpress_defconfig and
submits job on vexpress-a9 target which validates build and boot.
LAVA reported boot test failed on vexpress-a9 [3].
Please find boot failed log [4].
Boot failed log:
--------------------
mmci-pl18x 10005000.mmci: dummy supplies not allowed
mmci-pl18x 10005000.mmci: Failed getting OCR mask: 0
mmci-pl18x 10005000.mmci: mmc0: PL180 manf 41 rev0 at 0x10005000 irq 41,42 (pio)
mmci-pl18x 10005000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
mmci-pl18x 10005000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
This issue was reported by QA team and fixed by Fathi [1] couple of months
back. Now this patch is applied on mainline [2]. But boot test still failed
[4].
linux-next.git tree already have this config enabled.
"CONFIG_REGULATOR_VEXPRESS=y"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next
.git/tree/arch/arm/configs/vexpress_defconfig#n91
Bugs:
--------
https://bugs.launchpad.net/linaro-ci/+bug/1212893https://bugs.launchpad.net/linaro-ci/+bug/1235156
Ref link:
----------
[1] http://archive.arm.linux
.org.uk/lurker/message/20130831.125731.66d5b796.en.html
[2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next
.git/commit/arch/arm/configs/vexpress_defconfig?id=0ffae27f0f29e877ce52e4794a99926167792378
[3] http://validation.linaro.org/dashboard/image-reports/linux-next
-vexpress_defconfig
[4] http://validation.linaro.org/scheduler/job/84789/log_file#L_33_398
Best regards
Naresh Kamboju
