The patch series removes the use of Exynos4210 specific cpufreq driver
and enables to use the cpufreq-cpu0 driver for Exynos4210 based platforms.
This is being done for few reasons.
(a) The Exynos4210 cpufreq driver reads/writes clock controller registers
bypassing the Exynos4 CCF driver which is sort of problematic.
(b) Removes the need for having clock controller register definitions
in the cpufreq driver and also removes the need for statically
io-remapping clock controller address space (helps in moving towards
multiplatform kernel).
In order to use cpufreq-cpu0 driver and provide fast cpu clock switching
during dvfs operations, the following apporach has been used.
(a) A new CPU clock provider type has been introduced in Samsung's CCF
support. This clock provider type can be a compostion of multiple
clock blocks such as mux, dividers and gates. Typically, in Exynos
platforms, there are multiple clock blocks in between the output
of the APLL and the CPU clock domain output. Representing these
mutiple clock blocks within a opaque CPU clock provider type helps
in reducing the time taken to perform a CPU clock frequency change
operation, which is generally required during DVFS operations.
This approach was suggested by Arnd Bergmann <arnd@xxxxxxxx> during
LCE-2013.
(b) A new optional safe operating point property has been introduced
in the cpufreq-cpu0 driver binding. On some platforms such as the
Samsung Exynos, a change in CPU frequency requires a change in the
PLL output that drives the CPU clock. A change in PLL output
requires the PLL output be turned off, which implies that the CPU
(and other components in the CPU clock domain) be supplied with
an alternate clock source during the time the PLL output is changed.
The clock speed of this alternate clock source could be higher
than the clock speed of the PLL at the time of switching over to
the alternate clock source. This temporary increase in clock speed
of the CPU clock domain implies that the blocks within the CPU
clock domain should also be supplied with an appropriate voltage
supply level as required to drive the CPU clock domain components
at the speed of the alternative clock source. This temporary
voltage level required during switching of CPU clock speed is
called safe voltage level. And the cpufreq-cpu0 driver has been
modified to setup the safe voltage levels during the changes
in CPU clock speed.
(c) The CPU clock supply as been restructured as
[ Output of APLL -> Opaque CPU clock provider -> CPU clock output ]
And with the changes in (a) and (b) above, the cpufreq-cpu0 driver
can now be used and can remove the use of Exynos4210 specific
cpufreq driver.
This approach is currently tried on Exynos4210 only. The same approach
can be adopted for other Exynos SoCs as well. This patch series is
based on linux-next master branch.
Thomas Abraham (6):
cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
clk: samsung: add infrastructure to register CPU clocks
clk: samsung: register cpu clock provider for exynos4210 SoC
cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform driver
arm: dts: add cpu nodes for Exynos4210 SoC
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 5 +
arch/arm/boot/dts/exynos4210-origen.dts | 6 +
arch/arm/boot/dts/exynos4210-trats.dts | 6 +
arch/arm/boot/dts/exynos4210-universal_c210.dts | 6 +
arch/arm/boot/dts/exynos4210.dtsi | 22 +++
arch/arm/mach-exynos/mach-exynos4-dt.c | 6 +
drivers/clk/samsung/clk-exynos4.c | 96 ++++++++++++-
drivers/clk/samsung/clk.c | 71 +++++++++
drivers/clk/samsung/clk.h | 37 +++++-
drivers/cpufreq/Kconfig.arm | 11 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/cpufreq-cpu0.c | 49 ++++++-
drivers/cpufreq/exynos-cpufreq.c | 4 +-
drivers/cpufreq/exynos-cpufreq.h | 8 -
drivers/cpufreq/exynos4210-cpufreq.c | 157 --------------------
15 files changed, 301 insertions(+), 184 deletions(-)
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
