Re: [PATCH 0/6] cpufreq: use cpufreq-cpu0 driver for exynos4210 based platforms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Thomas,

I've investigated the topic for a while, so if you don't mind I will
share my thoughts :-)

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

Also other, already supported devices suffer from it. Namely -
Exynos4x12 and Exynos5250.

That's why the solution shall be as generic as possible to also work
with those two SoCs.

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

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux