On 20/10/14 12:41, Thomas Abraham wrote:
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figa <tomasz.figa@xxxxxxxxx>
Cc: Kukjin Kim <kgene.kim@xxxxxxxxxxx>
Signed-off-by: Thomas Abraham <thomas.ab@xxxxxxxxxxx>
Reviewed-by: Tomasz Figa <tomasz.figa@xxxxxxxxx>
Tested-by: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx>
Tested-by: Chander Kashyap <k.chander@xxxxxxxxxxx>
---
arch/arm/mach-exynos/exynos.c | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6b283eb..a1be294 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -282,6 +282,28 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
}
+static const struct of_device_id exynos_cpufreq_matches[] = {
+ { .compatible = "samsung,exynos5420", .data = "arm-bL-cpufreq-dt" },
Sorry for raising this issue always with Exynos cpufreq drivers. IMO the
bindings for "arm-bL-cpufreq-dt" is broken. Currently no one is using it
and it's better to fix it before we have a real user of it.
If you look at the binding document for it[1], it has a fixme which
shouldn't have been there at first place. It assumes the ordering of
CPU's specified in the DT and the logical index allocation to them.
It even breaks for hotplug especially if you hotplug-in back in
different order. We can work around that probably, but it's better to
fix the binding. I failed to grab much attention in my previous attempts
to address this[2]. Viresh also started a discussion more recently[3].
Regards,
Sudeep
[1] Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
[2] http://www.spinics.net/lists/arm-kernel/msg303977.html
[3] https://lkml.org/lkml/2014/6/25/152
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
