[PATCH v6 5/6] ARM: Exynos: switch to using generic cpufreq driver for exynos4210/5250
From: Thomas Abraham
Remove the platform device instantiation for Exynos4210/5250 cpufreq
driver and add the platform device for generic cpufreq drivers.
Cc: Kukjin Kim
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/exynos.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index f38cf7c..cfcfe02 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -181,7 +181,20 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
+ char *dev_name;
+
+ if (of_machine_is_compatible("samsung,exynos5440"))
+ return;
+ if (of_machine_is_compatible("samsung,exynos5420"))
+ dev_name = "arm-bL-cpufreq-dt";
+ else
+ if (of_machine_is_compatible("samsung,exynos4412") ||
+ of_machine_is_compatible("samsung,exynos4212"))
+ dev_name = "exynos-cpufreq";
+ else
+ dev_name = "cpufreq-cpu0";
+
+ platform_device_register_simple(dev_name, -1, NULL, 0);
}
void __iomem *sysram_base_addr;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/6] clk: exynos: use cpu-clock provider type to represent arm clock
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos4.c | 25 +
drivers/clk/samsung/clk-exynos5250.c | 16 +++-
drivers/clk/samsung/clk-exynos5420.c | 31 ++-
include/dt-bindings/clock/exynos5250.h |1 +
include/dt-bindings/clock/exynos5420.h |2 ++
5 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9..04cbcb6 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -471,7 +471,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
@@ -530,7 +531,8 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(0, "mout_jpeg", mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4x12, SRC_CAM, 4, 4),
MUX(CLK_MOUT_FIMC2, "mout_fimc2", group1_p4x12, SRC_CAM, 8, 4),
@@ -572,8 +574,10 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
- DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
+ DIV_F(0, "div_core", "mout_core", DIV_CPU0, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, "div_core2", "div_core", DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
@@ -619,8 +623,10 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
- DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
+ DIV_F(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
@@ -1005,7 +1011,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
static struct samsung_clock_alias exynos4_aliases[] __initdata = {
ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
- ALIAS(CLK_ARM_CLK, NULL, "armclk"),
ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
};
@@ -1244,6 +1249,8 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_gate_clks));
samsung_clk_register_alias(ctx, exynos4210_aliases,
ARRAY_SIZE(exynos4210_aliases));
+
[PATCH v6 2/6] clk: samsung: register exynos5420 apll/kpll configuration data
From: Thomas Abraham
Register the PLL configuration data for APLL and KPLL on Exynos5420. This
configuration data table specifies PLL coefficients for supported PLL
clock speeds when a 24MHz clock is supplied as the input clock source
for these PLLs.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos5420.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 9d7d7ee..51cff4a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1142,6 +1142,28 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
GATE(CLK_G3D, "g3d", "mout_user_aclk_g3d", GATE_IP_G3D, 9, 0, 0),
};
+static const struct samsung_pll_rate_table exynos5420_pll2550x_24mhz_tbl[] = {
+ PLL_35XX_RATE(20, 250, 3, 0),
+ PLL_35XX_RATE(19, 475, 6, 0),
+ PLL_35XX_RATE(18, 225, 3, 0),
+ PLL_35XX_RATE(17, 425, 6, 0),
+ PLL_35XX_RATE(16, 200, 3, 0),
+ PLL_35XX_RATE(15, 250, 4, 0),
+ PLL_35XX_RATE(14, 175, 3, 0),
+ PLL_35XX_RATE(13, 325, 6, 0),
+ PLL_35XX_RATE(12, 200, 2, 1),
+ PLL_35XX_RATE(11, 275, 3, 1),
+ PLL_35XX_RATE(10, 250, 3, 1),
+ PLL_35XX_RATE(9, 150, 2, 1),
+ PLL_35XX_RATE(8, 200, 3, 1),
+ PLL_35XX_RATE(7, 175, 3, 1),
+ PLL_35XX_RATE(6, 200, 2, 2),
+ PLL_35XX_RATE(5, 250, 3, 2),
+ PLL_35XX_RATE(4, 200, 3, 2),
+ PLL_35XX_RATE(3, 200, 2, 3),
+ PLL_35XX_RATE(2, 200, 3, 3),
+};
+
static struct samsung_pll_clock exynos5x_plls[nr_plls] __initdata = {
[apll] = PLL(pll_2550, CLK_FOUT_APLL, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, NULL),
@@ -1195,6 +1217,12 @@ static void __init exynos5x_clk_init(struct device_node
*np,
samsung_clk_of_register_fixed_ext(ctx, exynos5x_fixed_rate_ext_clks,
ARRAY_SIZE(exynos5x_fixed_rate_ext_clks),
ext_clk_match);
+
+ if (_get_rate("fin_pll") == 24 * MHZ) {
+ exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
+ exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
+ }
+
samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
reg_base);
samsung_clk_register_fixed_rate(ctx, exynos5x_fixed_rate_clks,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/6] clk: samsung: add infrastructure to register cpu clocks
From: Thomas Abraham
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 577 +
drivers/clk/samsung/clk.h |5 +
3 files changed, 583 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 69e8177..f4edd31 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..c40f7b5
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,577 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the CPU clocks
+ * for Samsung platforms.
+*/
+
+#include
+#include "clk.h"
+
+#define E4210_SRC_CPU 0x0
+#define E4210_STAT_CPU 0x200
+#define E4210_DIV_CPU0 0x300
+#define E4210_DIV_CPU1 0x304
+#define E4210_DIV_STAT_CPU00x400
+#define E4210_DIV_STAT_CPU10x404
+
+#define MAX_DIV8
+#define DIV_MASK 7
+#define DIV_MASK_ALL 0x
+#define MUX_MASK 7
+
+#define E4210_DIV0_RATIO0_MASK 0x7
+#define E4210_DIV1_HPM_MASK((0x7 << 4) | (0x7 << 0))
+#define E4210_MUX_HPM_MASK (1 << 20)
+#define E4210_DIV0_ATB_SHIFT 16
+#define E4210_DIV0_ATB_MASK(DIV_MASK << E4210_DIV0_ATB_SHIFT)
+
+#define E4210_CPU_DIV0(apll, pclk_dbg, atb, periph, corem1, corem0)\
+ (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
+ ((periph) << 12) | ((corem1) << 8) | ((corem0) << 4))
+#define E4210_CPU_DIV1(hpm, copy) \
+ (((hpm) << 4) | ((copy) << 0))
+
+#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
+ (((apll << 24) | (pclk_dbg << 20) | (atb << 16) | \
+(periph << 12) | (acp << 8) | (cpud << 4)))
+#define E5250_CPU_DIV1(hpm, copy) \
+ (((hpm) << 4) | (copy))
+
+#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud) \
+ (((apll << 24) | (pclk_dbg << 20) | (atb << 16) | \
+(cpud << 4)))
+#define E5420_KFC_DIV(kpll, pclk, aclk)
\
+ (((kpll << 24) | (pclk << 20) | (aclk << 4)))
+
+enum cpuclk_type {
+ EXYNOS4210,
+ EXYNOS5250,
+ EXYNOS5420,
+};
+
+/**
+ * struct exynos4210_cpuclk_data: config data to setup cpu clocks.
+ * @prate: frequency of the primary parent clock (in KHz).
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for dividers in the CPU
+ * clock domain. The parent frequency at which these divider values are valid
is
+ * specified in @prate. The @prate is the frequency of the primary parent
clock.
+ * For CPU clock domains that do not have a DIV1 register, the @div1 member
+ * is optional.
+ */
+struct exynos4210_cpuclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct exynos_cpuclk: information about clock supplied to a CPU core.
+ * @hw:handle between CCF and CPU clock.
+ * @alt_parent: alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset: offset from the ctrl_base address where the CPU clock div/mux
+ * registers can be accessed.
+ * @lock: cpu clock domain register access lock.
+ * @type: type of the CPU clock.
+ * @data: optional data which the actual instantiation of this clock
+ * can use.
+ * @clk_nb
[PATCH v6 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Changes since v5: - Configuration data for cpu clock block is embedded with the code. The cpu clock logic can later to extended to obtain this data from DT. - Excluded the support for Exynos4x12 SoC since the work on boost OPP bindings is still incomplete. - Included cpufreq support for Exynos5420 SoC. - Many other minor changes (and so dropped Ack's for some of the patches in v5) This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-cpu0 driver for these platforms. This series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq driver. Thomas Abraham (6): clk: samsung: add infrastructure to register cpu clocks clk: samsung: register exynos5420 apll/kpll configuration data clk: exynos: use cpu-clock provider type to represent arm clock ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data ARM: Exynos: switch to using generic cpufreq driver for exynos4210/5250 cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support 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 | 27 ++ arch/arm/boot/dts/exynos5250-arndale.dts|6 + arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 + arch/arm/boot/dts/exynos5250-smdk5250.dts |6 + arch/arm/boot/dts/exynos5250.dtsi | 23 + arch/arm/boot/dts/exynos5420-smdk5420.dts |6 + arch/arm/boot/dts/exynos5420.dtsi | 32 ++ arch/arm/mach-exynos/exynos.c | 15 +- drivers/clk/samsung/Makefile|2 +- drivers/clk/samsung/clk-cpu.c | 577 +++ drivers/clk/samsung/clk-exynos4.c | 25 +- drivers/clk/samsung/clk-exynos5250.c| 16 +- drivers/clk/samsung/clk-exynos5420.c| 59 ++- drivers/clk/samsung/clk.h |5 + drivers/cpufreq/Kconfig.arm | 22 - drivers/cpufreq/Makefile|2 - drivers/cpufreq/exynos4210-cpufreq.c| 184 drivers/cpufreq/exynos5250-cpufreq.c| 210 - include/dt-bindings/clock/exynos5250.h |1 + include/dt-bindings/clock/exynos5420.h |2 + 23 files changed, 802 insertions(+), 442 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] cpufreq: Use cpufreq-cpu0 driver for Exynos3250
On Fri, Jun 13, 2014 at 12:06 PM, Viresh Kumar wrote: > cpuf...@vger.kernel.org is dead now. Anyway you should be using linux-pm > instead. > > On 13 June 2014 11:38, Chanwoo Choi wrote: >> This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this >> patchset is based on following patchset[1] by Thomas Abraham. >> [1] http://www.spinics.net/lists/linux-samsung-soc/msg31593.html >> >> Chanwoo Choi (4): >> clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq >> clk: samsung: Add support for cpu clocks of Exynos3250 >> Documentation: devicetree: Add cpu clock configuration data binding for >> Exynos3250 >> ARM: dts: Exynos: Add cpu clock table and armclk divider table for >> Exynos3250 >> >> .../devicetree/bindings/clock/exynos3250-clock.txt | 32 >> ++ >> arch/arm/boot/dts/exynos3250.dtsi | 28 +++ >> drivers/clk/samsung/clk-cpu.c | 31 >> + >> drivers/clk/samsung/clk-exynos3250.c | 14 +++--- >> 4 files changed, 96 insertions(+), 9 deletions(-) > > Nothing really cpufreq specific. Would *eagerly* wait for the patch that > removes existing driver files :) The next version of the exynos cpufreq cleanup patches are being prepared. But exynos4x12 cpufreq driver will not be included for cleanup since the boost frequency bindings need more work. Thanks, Thomas. > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Fri, May 30, 2014 at 11:45 PM, Tomasz Figa wrote: > > > On 30.05.2014 20:05, Thomas Abraham wrote: >> Hi Mark, >> >> On Fri, May 30, 2014 at 6:38 PM, Mark Rutland wrote: >>> Hi, >>> >>> Apologies for being somewhat late w.r.t. review on this. >>> >>> On Fri, May 30, 2014 at 10:01:17AM +0100, Thomas Abraham wrote: >>>> From: Thomas Abraham >>>> >>>> Add a new optional boost-frequency binding for specifying the frequencies >>>> usable in boost mode. >>>> >>>> Cc: Rob Herring >>>> Cc: Pawel Moll >>>> Cc: Mark Rutland >>>> Cc: Ian Campbell >>>> Cc: Kumar Gala >>>> Signed-off-by: Thomas Abraham >>>> Acked-by: Viresh Kumar >>>> Acked-by: Nishanth Menon >>>> Acked-by: Lukasz Majewski >>>> --- >>>> .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38 >>>> >>>> 1 file changed, 38 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> new file mode 100644 >>>> index 000..63ed0fc >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> @@ -0,0 +1,38 @@ >>>> +* Device tree binding for CPU boost frequency (aka over-clocking) >>>> + >>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes >>>> referred as >>> >>> Nit: CPUs (we're not greengrocers [1]) >>> >>>> +overclocking) in which the CPU can operate at frequencies which are not >>>> +specified by the manufacturer as CPU's operating frequency. >>>> + >>>> +Optional Properties: >>>> +- boost-frequencies: list of frequencies in KHz to be used only in boost >>>> mode. >>>> + This list should be a subset of frequencies listed in "operating-points" >>>> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for >>>> + details about "operating-points" property. >>> >>> What is 'boost-mode'? >> >> boost-mode activates additional one or more cpu clock speeds (which >> are not specified as operating frequency of the cpu by the >> manufacturer). The cpu is allowed to operate in these boost mode >> speeds when the boost mode is active. The boost mode speeds are >> usually undocumented. Some of the chip samples could be clocked in >> boost mode speeds and only such samples can be safely operated in >> boost mode. >> > > IMHO the most important part that I believe should be stated in the > documentation is that CPU usually can operate in boost mode for limited > amount of time, which depends on thermal conditions, which makes the > boost operating points separate from normal ones, which can be used at > any time. The factors that allow a CPU to operate in boost mode and the duration the CPU can operate in boost mode clock speed is a CPU specific description. This binding does not describe such CPU specific behavior. This binding only states the additional clock speeds CPU is allowed to operate in boost mode. The boost mode entry and exit conditions are implementation specific and not part of the scope of this binding and documentation. > >> The mechanism of entry into and exit out of boost mode is outside the >> scope of this documentation. >> >>> >>> What are the limitations on boost frequencies? When is a CPU expected to >>> go to these frequencies and for now long? When should I as a dt author >>> place elements in boost-frequencies? >> >> I will add these details in the next revision of this patch. >> >>> >>> Why are these in both operating-points and boost-frequencies? It'll be >>> really easy to accidentally forget to mark something as a >>> boost-frequency this way. Why not have a boost-points instead? >> >> Does boost-points mean a set of clock speeds which are not listed as >> part of operating-points property? If yes, that also is a possible >> implementation (it was implemented in one of the earlier version of >> this series). Could you confirm that you want the boost mode speeds to >> be exclusive of the speeds listed in operating-points? > > It seems reaso
Re: [PATCH v6 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
On Fri, May 30, 2014 at 8:17 PM, Rafael J. Wysocki wrote:
> On Friday, May 30, 2014 02:19:06 PM Rafael J. Wysocki wrote:
>> On Friday, May 30, 2014 02:31:15 PM Thomas Abraham wrote:
>> > Changes since v5:
>> > - Fixes for checkpatch warnings with --strict option as suggested by
>> > Nishanth Menon.
>> >
>> > Changes since v4:
>> > - Code improvements suggested by Viresh Kumar.
>> >
>> > Changes since v3:
>> > - Minor changes as suggested in the last version.
>> >
>> > Changes since v2:
>> > - Reworked based on the "PM / OPP: move cpufreq specific helpers out of OPP
>> > layer" patch series posted by Nishanth Menon.
>> >
>> > Changes since v1:
>> > - Boost mode frequencies are specfied as a set of frequencies instead of
>> > specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
>> > feedback.
>> >
>> > This series has been acked by authors and maintainers of the code
>> > portions changed in this series. The new DT binding introduced in this
>> > patch needs an ack from device tree binding maintainers as well.
>> >
>> > Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> > support for CPU boost mode for CPUfreq drivers. To use the new boost
>> > mode, CPUfreq drivers have to specify the boost mode frequency and
>> > voltage within the CPUfreq driver, which is the case for Exynos4x12
>> > CPUfreq driver.
>> >
>> > But for CPUfreq drivers which obtain the OPPs from cpus node, this
>> > patch series adds support to specify boost mode frequencies in the
>> > cpu device tree node. This requirement came up when Lukasz pointed
>> > out the regression caused by the Exynos CPUfreq driver consolidation
>> > patches.
>>
>> Both patches queued up for 3.16 in the linux-pm tree.
>
> But please address the Mark's comments or I'll drop them.
Hi Rafael,
Please drop this series for now. Both the patches have to reworked
based on Mark's comments.
Thanks,
Thomas.
>
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
Hi Mark,
On Fri, May 30, 2014 at 6:38 PM, Mark Rutland wrote:
> Hi,
>
> Apologies for being somewhat late w.r.t. review on this.
>
> On Fri, May 30, 2014 at 10:01:17AM +0100, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Add a new optional boost-frequency binding for specifying the frequencies
>> usable in boost mode.
>>
>> Cc: Rob Herring
>> Cc: Pawel Moll
>> Cc: Mark Rutland
>> Cc: Ian Campbell
>> Cc: Kumar Gala
>> Signed-off-by: Thomas Abraham
>> Acked-by: Viresh Kumar
>> Acked-by: Nishanth Menon
>> Acked-by: Lukasz Majewski
>> ---
>> .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38
>>
>> 1 file changed, 38 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> new file mode 100644
>> index 000..63ed0fc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> @@ -0,0 +1,38 @@
>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>> +
>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes
>> referred as
>
> Nit: CPUs (we're not greengrocers [1])
>
>> +overclocking) in which the CPU can operate at frequencies which are not
>> +specified by the manufacturer as CPU's operating frequency.
>> +
>> +Optional Properties:
>> +- boost-frequencies: list of frequencies in KHz to be used only in boost
>> mode.
>> + This list should be a subset of frequencies listed in "operating-points"
>> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>> + details about "operating-points" property.
>
> What is 'boost-mode'?
boost-mode activates additional one or more cpu clock speeds (which
are not specified as operating frequency of the cpu by the
manufacturer). The cpu is allowed to operate in these boost mode
speeds when the boost mode is active. The boost mode speeds are
usually undocumented. Some of the chip samples could be clocked in
boost mode speeds and only such samples can be safely operated in
boost mode.
The mechanism of entry into and exit out of boost mode is outside the
scope of this documentation.
>
> What are the limitations on boost frequencies? When is a CPU expected to
> go to these frequencies and for now long? When should I as a dt author
> place elements in boost-frequencies?
I will add these details in the next revision of this patch.
>
> Why are these in both operating-points and boost-frequencies? It'll be
> really easy to accidentally forget to mark something as a
> boost-frequency this way. Why not have a boost-points instead?
Does boost-points mean a set of clock speeds which are not listed as
part of operating-points property? If yes, that also is a possible
implementation (it was implemented in one of the earlier version of
this series). Could you confirm that you want the boost mode speeds to
be exclusive of the speeds listed in operating-points?
Thanks,
Thomas.
>
>> +
>> +Example:
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <0>;
>> +
>> + operating-points = <
>> + 150 135
>> + 140 1287500
>> + 130 125
>> + 120 1187500
>> + 110 1137500
>> + 100 1087500
>> + >;
>> + boost-frequencies = <150 140>;
>
> This is more of a general issue, but I hate the whole cpufreq-cpu0 way
> of assuming that all CPUs mirror CPU0.
>
> It would be nicer if either this were dropped in /cpus or repeated
> per-cpu.
>
> Cheers,
> Mark.
>
>> + };
>> + cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <1>;
>> + };
>> + };
>> --
>> 1.7.9.5
>>
>>
>
> [1]
> http://en.wikipedia.org/wiki/Apostrophe#Superfluous_apostrophes_.28.22greengrocers.27_apostrophes.22.29
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
Changes since v5:
- Fixes for checkpatch warnings with --strict option as suggested by
Nishanth Menon.
Changes since v4:
- Code improvements suggested by Viresh Kumar.
Changes since v3:
- Minor changes as suggested in the last version.
Changes since v2:
- Reworked based on the "PM / OPP: move cpufreq specific helpers out of OPP
layer" patch series posted by Nishanth Menon.
Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
feedback.
This series has been acked by authors and maintainers of the code
portions changed in this series. The new DT binding introduced in this
patch needs an ack from device tree binding maintainers as well.
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Signed-off-by: Thomas Abraham
Acked-by: Nishanth Menon
Acked-by: Lukasz Majewski
---
drivers/cpufreq/cpufreq_opp.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..a13019a 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,11 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ struct cpufreq_frequency_table *ft;
+ int len, count;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +88,45 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = &freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (!of_find_property(dev->of_node, "boost-frequencies", &len))
+ goto out;
+
+ if (!len || !IS_ALIGNED(len, sizeof(u32))) {
+ dev_err(dev, "%s: invalid boost frequency\n", __func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kmalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_err(dev, "%s: no memory for boost freq table\n", __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ count = len / sizeof(u32);
+ of_property_read_u32_array(dev->of_node, "boost-frequencies",
+ boost_freqs, count);
+
+ for (i = 0; i < count; i++) {
+ cpufreq_for_each_valid_entry(ft, *table) {
+ if (boost_freqs[i] == ft->frequency) {
+ ft->flags |= CPUFREQ_BOOST_FREQ;
+ pr_debug("%s: marked %d as boost frequency\n",
+__func__, boost_freqs[i]);
+ break;
+ }
+ }
+
+ if (ft->frequency == CPUFREQ_TABLE_END)
+ dev_err(dev, "%s: invalid boost frequency %d\n",
+ __func__, boost_freqs[i]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham
Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Thomas Abraham
Acked-by: Viresh Kumar
Acked-by: Nishanth Menon
Acked-by: Lukasz Majewski
---
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 000..63ed0fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,38 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred
as
+overclocking) in which the CPU can operate at frequencies which are not
+specified by the manufacturer as CPU's operating frequency.
+
+Optional Properties:
+- boost-frequencies: list of frequencies in KHz to be used only in boost mode.
+ This list should be a subset of frequencies listed in "operating-points"
+ property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+ details about "operating-points" property.
+
+Example:
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+
+ operating-points = <
+ 150 135
+ 140 1287500
+ 130 125
+ 120 1187500
+ 110 1137500
+ 100 1087500
+ >;
+ boost-frequencies = <150 140>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
drivers/cpufreq/cpufreq_opp.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..05fb115 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,11 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ struct cpufreq_frequency_table *ft;
+ int len, count;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +88,45 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = &freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (!of_find_property(dev->of_node, "boost-frequencies", &len))
+ goto out;
+
+ if (!len || !IS_ALIGNED(len, sizeof(u32))) {
+ dev_err(dev, "%s: invalid boost frequency\n", __func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kmalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_err(dev, "%s: no memory for boost freq table\n", __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ count = len / sizeof(u32);
+ of_property_read_u32_array(dev->of_node, "boost-frequencies",
+ boost_freqs, count);
+
+ for (i = 0; i < count; i++) {
+ cpufreq_for_each_valid_entry(ft, *table) {
+ if (boost_freqs[i] == ft->frequency) {
+ ft->flags |= CPUFREQ_BOOST_FREQ;
+ pr_debug("%s: marked %d as boost frequency\n",
+ __func__, boost_freqs[i]);
+ break;
+ }
+ }
+
+ if (ft->frequency == CPUFREQ_TABLE_END)
+ dev_err(dev, "%s: invalid boost frequency %d\n",
+ __func__, boost_freqs[i]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham
Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Thomas Abraham
Acked-by: Viresh Kumar
---
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 000..63ed0fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,38 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred
as
+overclocking) in which the CPU can operate at frequencies which are not
+specified by the manufacturer as CPU's operating frequency.
+
+Optional Properties:
+- boost-frequencies: list of frequencies in KHz to be used only in boost mode.
+ This list should be a subset of frequencies listed in "operating-points"
+ property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+ details about "operating-points" property.
+
+Example:
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+
+ operating-points = <
+ 150 135
+ 140 1287500
+ 130 125
+ 120 1187500
+ 110 1137500
+ 100 1087500
+ >;
+ boost-frequencies = <150 140>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
Changes since v5:
- Code improvements suggested by Viresh Kumar.
Changes since v4:
- Includes cleanup changes suggested by Viresh Kumar.
Changes since v3:
- Minor changes as suggested in the last version.
Changes since v2:
- Reworked based on the "PM / OPP: move cpufreq specific helpers out of OPP
layer" patch series posted by Nishanth Menon .
Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
feedback.
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Mon, May 26, 2014 at 11:28 AM, Viresh Kumar wrote:
> On 23 May 2014 19:07, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/cpufreq/cpufreq_opp.c | 44
>> +
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
>> index c0c6f4a..2b3905b 100644
>> --- a/drivers/cpufreq/cpufreq_opp.c
>> +++ b/drivers/cpufreq/cpufreq_opp.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
>> @@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> struct cpufreq_frequency_table *freq_table = NULL;
>> int i, max_opps, ret = 0;
>> unsigned long rate;
>> +#ifdef CONFIG_CPU_FREQ_BOOST_SW
>> + int j, len;
>> + u32 *boost_freqs = NULL;
>> +#endif
>>
>> rcu_read_lock();
>>
>> @@ -82,6 +87,45 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>
>> *table = &freq_table[0];
>>
>> +#ifdef CONFIG_CPU_FREQ_BOOST_SW
>> + if (of_find_property(dev->of_node, "boost-frequencies", &len)) {
>
> Maybe:
> if(!of_find_property(...))
> goto out;
>
> To get rid of extra indentation levels below..
>
>> + struct cpufreq_frequency_table *ft;
>
> Declare at the top with boost_freqs, etc..
>
>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>
> s/len == 0/!len
>
> And use IS_ALIGNED() instead of the right hand side of ||
>
>> + dev_err(dev, "%s: invalid boost frequency\n",
>> __func__);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>
> Can we do a devm_kzalloc instead? And why not kmalloc BTW ?
This is a temporary storage that is freed at the end of this function.
So devm_kzalloc is not used. Yes, kmalloc can be used.
>
>> + if (!boost_freqs) {
>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>
> dev_err ?
>
>> + __func__);
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> + of_property_read_u32_array(dev->of_node, "boost-frequencies",
>> + boost_freqs, len / sizeof(u32));
>
>
> Create int count = len / sizeof(u32) instead.. You have used this
> multiple times.
>
>> + for (j = 0; j < len / sizeof(u32); j++) {
>> + ft = *table;
>> + for (i = 0; ft->frequency != CPUFREQ_TABLE_END; i++)
>> {
>
> See if new macros can be used here instead. cpufreq_for_each_valid_entry().
>
>> + if (boost_freqs[j] == ft->frequency) {
>> + ft->flags |= CPUFREQ_BOOST_FREQ;
>> + break;
>> + }
>> + ft++;
>> + }
>> +
>> + if (ft->frequency == CPUFREQ_TABLE_END)
>> + pr_err("%s: invalid boost frequency %d\n",
>> + __func__, boost_freqs[j]);
>
> Maybe a pr_debug on the else part as well ? With boost freqs ..
>
>> + }
>> + }
>> +
>> + kfree(boost_freqs);
>> +#endif
>> +
>> out:
>> rcu_read_unlock();
>> if (ret)
>> --
>> 1.7.9.5
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/8] Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5
Hi Tomasz, Thanks for your comments. Please see inline reply. On Sat, May 17, 2014 at 4:54 AM, Tomasz Figa wrote: > Hi Thomas, > > Please see my comments inline. > > On 14.05.2014 03:11, Thomas Abraham wrote: >> From; Thomas Abraham >> >> The clock blocks within the CMU_CPU clock domain are put together into a >> new composite clock type called the cpu clock. This clock type requires >> configuration data that will be atomically programmed in the multiple >> clock blocks encapsulated within the cpu clock type when the parent clock >> frequency is changed. This configuration data is held in the clock controller >> node. Update clock binding documentation about this configuration data format >> for Samsung Exynos4 and Exynos5 platforms. >> >> Cc: Tomasz Figa >> Cc: Rob Herring >> Cc: Pawel Moll >> Cc: Mark Rutland >> Cc: Ian Campbell >> Cc: Kumar Gala >> Cc: >> Signed-off-by: Thomas Abraham >> --- >> .../devicetree/bindings/clock/exynos4-clock.txt| 37 >> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 36 >> +++ >> 2 files changed, 73 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> index f5a5b19..0934e02 100644 >> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> @@ -15,6 +15,35 @@ Required Properties: >> >> - #clock-cells: should be 1. >> >> +- samsung,armclk-divider-table: when the frequency of the APLL is changed >> + the divider clocks in CMU_CPU clock domain also need to be updated. These >> + divider clocks have SoC specific divider clock output requirements for a >> + specific APLL clock speeds. When APLL clock rate is changed, these divider >> + clocks are reprogrammed with pre-determined values in order to maintain >> the >> + SoC specific divider clock outputs. This property lists the divider values >> + for divider clocks in the CMU_CPU block for supported APLL clock speeds. >> + The format of each entry included in the arm-frequency-table should be >> + as defined below > > As far as I understand, the relation is not between the APLL frequency > and particular clocks in CPU domain, but rather between the latter and > input clock to CPU domain, which is _after_ the two dividers (called > DIV_CORE and DIV_CORE2 or ARM_DIV1 and ARM_DIV2), which is also exactly > the output frequency of ARMCLK. > >> + >> + - for Exynos4210 and Exynos4212 based platforms: >> + cell #1: arm clock parent frequency > > Considering my comment above, this should be rather ARMCLK frequency. The clocks SCLK_APLL, SCLK_HPM, ATCLK and PCLK_DBG have no relation to the ARMCLK frequency. These clocks are directly derived from the PLL clock and so it would not be correct to have them related to ARMCLK. So, I see two solutions to this, first being preferred solution. [A] Cell #1 should define PLL (parent of armclk) clock speed. Cell #2 and Cell #3 should define divider values for ARMCLK clock speed. The hardware does support PLL frequency != ARMCLK frequency and so DT binding should allow that (even though implementation in the linux kernel does not use this feature). BTW, this was what was done in v2 of this series. [B] Embedded this data with the code and don't get this from DT. The reason for doing this is, these are SoC specific values and not board specific. And when we are clear about what we want to put in DT, have a provision to lookup DT first and if DT values are not found, fallback on data embedded with the code. Thanks, Thomas. > >> + cell #2 ~ cell 9#: value of clock divider in the following order >> + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, >> + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio. >> + >> + - for Exynos4412 based platforms: >> + cell #1: expected arm clock parent frequency > > Ditto. > >> + cell #2 ~ cell #10: value of clock divider in the following order >> +corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, >> + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio, >> cores_ratio >> + >> +- samsung,armclk-cells: defines the number of cells in >> + samsung,armclk-divider-table property. The value of this property depends >> on >> + the SoC type. > > To follow conventions used by all other bindings with variable number of > cells, the property should be called "#samsung,armclk-cells&qu
Re: [PATCH v4 3/8] clk: samsung: add infrastructure to register cpu clocks
Hi Tomasz,
On Fri, May 16, 2014 at 10:47 PM, Tomasz Figa wrote:
> Hi Thomas,
>
> On 14.05.2014 03:11, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> The CPU clock provider supplies the clock to the CPU clock domain. The
>> composition and organization of the CPU clock provider could vary among
>> Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
>> and gates. This patch defines a new clock type for CPU clock provider and
>> adds infrastructure to register the CPU clock providers for Samsung
>> platforms.
>>
>> Cc: Tomasz Figa
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/clk/samsung/Makefile |2 +-
>> drivers/clk/samsung/clk-cpu.c | 458
>> +
>> drivers/clk/samsung/clk.h |5 +
>> 3 files changed, 464 insertions(+), 1 deletions(-)
>> create mode 100644 drivers/clk/samsung/clk-cpu.c
>>
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index 8eb4799..e2b453f 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -2,7 +2,7 @@
>> # Samsung Clock specific Makefile
>> #
>>
>> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
>> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
>> new file mode 100644
>> index 000..6a40862
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-cpu.c
>> @@ -0,0 +1,458 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * Author: Thomas Abraham
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This file contains the utility functions to register the cpu clocks
>> + * for samsung platforms.
>
> s/cpu/CPU/
> s/samsung/Samsung/
>
>> +*/
>> +
>> +#include
>> +#include "clk.h"
>> +
>> +#define SRC_CPU 0x0
>> +#define STAT_CPU 0x200
>> +#define DIV_CPU0 0x300
>> +#define DIV_CPU1 0x304
>> +#define DIV_STAT_CPU00x400
>> +#define DIV_STAT_CPU10x404
>> +
>> +#define MAX_DIV 8
>> +
>> +#define EXYNOS4210_ARM_DIV1(div) ((div & 0x7) + 1)
>> +#define EXYNOS4210_ARM_DIV2(div) (((div >> 28) & 0x7) + 1)
>> +
>> +#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0) \
>> + ((d5 << 24) | (d4 << 20) | (d3 << 16) | (d2 << 12) |\
>> + (d1 << 8) | (d0 << 4))
>> +#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
>> \
>> + ((d2 << 8) | (d1 << 4) | (d0 << 0))
>
> Macro arguments should be put into parentheses to make sure that whole
> argument is subject to further arithmetic operations.
>
>> +
>> +#define EXYNOS4210_DIV1_HPM_MASK ((0x7 << 0) | (0x7 << 4))
>> +#define EXYNOS4210_MUX_HPM_MASK (1 << 20)
>> +
>> +/**
>> + * struct exynos4210_armclk_data: config data to setup exynos4210 cpu
>> clocks.
>> + * @prate: frequency of the parent clock.
>> + * @div0:value to be programmed in the div_cpu0 register.
>> + * @div1:value to be programmed in the div_cpu1 register.
>> + *
>> + * This structure holds the divider configuration data for divider clocks
>> + * belonging to the CMU_CPU clock domain. The parent frequency at which
>> these
>> + * divider values are vaild is specified in @prate.
>
> s/vaild/valid/
>
>> + */
>> +struct exynos4210_armclk_data {
>> + unsigned long prate;
>> + unsigned intdiv0;
>> + unsigned intdiv1;
>> +};
>> +
>> +/**
>> + * struct exynos_cpuclk: information about clock supplied to a CPU core.
>> + * @hw: handle between ccf and cpu clock.
>
> s/ccf/CCF/
> s/cpu/CPU/
>
>> + * @alt_parent: alternate parent clock to use when switching the speed
>> + * of the primary parent clock.
>> + * @ctrl_base: base address of the clock controller.
>> + * @offset: offset from the ctrl_base address where t
[PATCH v5 6/7] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
From: Thomas Abraham
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 93507ee..2193061 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -184,7 +184,9 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
+ if (!(of_machine_is_compatible("samsung,exynos5420")) &&
+ !(of_machine_is_compatible("samsung,exynos5440")))
+ platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
}
void __init exynos_init_late(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/7] clk: samsung: add infrastructure to register cpu clocks
From: Thomas Abraham
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 448 +
drivers/clk/samsung/clk.h |4 +
3 files changed, 453 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 25646c6..83620a1 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..13fa4c5
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,448 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the CPU clocks
+ * for Samsung platforms.
+*/
+
+#include
+#include "clk.h"
+
+#define SRC_CPU0x0
+#define STAT_CPU 0x200
+#define DIV_CPU0 0x300
+#define DIV_CPU1 0x304
+#define DIV_STAT_CPU0 0x400
+#define DIV_STAT_CPU1 0x404
+
+#define DIV_CPU0_RATIO0_MASK 0x7
+
+#define MAX_DIV8
+
+#define EXYNOS4210_ARM_DIV1(div) ((div & 0x7) + 1)
+#define EXYNOS4210_ARM_DIV2(div) (((div >> 28) & 0x7) + 1)
+
+#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0)\
+ (((d5) << 24) | ((d4) << 20) | ((d3) << 16) | ((d2) << 12) | \
+((d1) << 8) | ((d0) << 4))
+#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
\
+ (((d2) << 8) | ((d1) << 4) | ((d0) << 0))
+
+#define EXYNOS4210_DIV1_HPM_MASK ((0x7 << 0) | (0x7 << 4))
+#define EXYNOS4210_MUX_HPM_MASK(1 << 20)
+
+/**
+ * struct exynos4210_armclk_data: config data to setup exynos4210 cpu clocks.
+ * @prate: frequency of the parent clock.
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for divider clocks
+ * belonging to the CMU_CPU clock domain. The parent frequency at which these
+ * divider values are valid is specified in @prate.
+ */
+struct exynos4210_armclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct exynos_cpuclk: information about clock supplied to a CPU core.
+ * @hw:handle between CCF and CPU clock.
+ * @alt_parent:alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset:offset from the ctrl_base address where the CPU clock div/mux
+ * registers can be accessed.
+ * @clk_nb:clock notifier registered for changes in clock speed of the
+ * primary parent clock.
+ * @lock: register access lock.
+ * @data: optional data which the actual instantiation of this clock
+ * can use.
+ */
+struct exynos_cpuclk {
+ struct clk_hw hw;
+ struct clk *alt_parent;
+ void __iomem*ctrl_base;
+ unsigned long offset;
+ struct notifier_block clk_nb;
+ spinlock_t *lock;
+ void*data;
+};
+
+#define to_exynos_cpuclk_hw(hw) container_of(hw, struct exynos_cpuclk, hw)
+#define to_exynos_cpuclk_nb(nb) container_of(nb, struct exynos_cpuclk, clk_nb)
+
+/**
+ * struct exynos_cpuclk_soc_data: soc specific data for cpu clocks.
+ * @parser:pointer to a function that can parse SoC specific data.
+ * @ops: clock operations to be used for this clock.
+ * @offset:optional offset from base of clock controller register base, to
+ * be used when accessing clock controller registers related to the
+ * CPU clock.
+ * @clk_cb:the clock no
[PATCH v5 5/7] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
From: Thomas Abraham
For all Exynos based platforms, add CPU nodes, operating points and cpu
clock data for migrating from Exynos specific cpufreq driver to using
generic cpufreq-cpu0 driver.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
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 | 35 +++
arch/arm/boot/dts/exynos4212.dtsi | 18 ++
arch/arm/boot/dts/exynos4412-odroidx.dts|6
arch/arm/boot/dts/exynos4412-origen.dts |6
arch/arm/boot/dts/exynos4412-trats2.dts |6
arch/arm/boot/dts/exynos4412.dtsi | 31 +
arch/arm/boot/dts/exynos4x12.dtsi | 36
arch/arm/boot/dts/exynos5250-arndale.dts|6
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6
arch/arm/boot/dts/exynos5250-smdk5250.dts |6
arch/arm/boot/dts/exynos5250.dtsi | 41 +++
14 files changed, 215 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f..4324b25 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&buck1_reg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..fe32b6a 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&varm_breg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..8ab12d6 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&vdd_arm_reg>;
+ };
+ };
+
sysram@0202 {
smp-sysram@0 {
status = "disabled";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..e42b87c 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,33 @@
pinctrl2 = &pinctrl_2;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+
+ operating-points = <
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
+ >;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
+
sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
@@ -91,6 +118,14 @@
compatible = "samsung,exynos4210-clock";
reg = <0x1003 0x2>;
#clock-cells = <1>;
+
+ samsung,armclk-cells = <9>;
+ samsung,armclk-divider-table = <120 3 7 3 4 1 7 5 0>,
+ <100 3 7 3 4 1 7 4 0>,
+ < 80 3 7 3 3 1 7 3 0>,
+
[PATCH v5 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed. Signed-off-by: Thomas Abraham --- drivers/cpufreq/Kconfig.arm | 52 drivers/cpufreq/Makefile |4 - drivers/cpufreq/exynos-cpufreq.c | 218 -- drivers/cpufreq/exynos-cpufreq.h | 99 --- drivers/cpufreq/exynos4210-cpufreq.c | 157 drivers/cpufreq/exynos4x12-cpufreq.c | 208 drivers/cpufreq/exynos5250-cpufreq.c | 183 7 files changed, 921 deletions(-) delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 5805035..9721674 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -24,43 +24,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ This add the CPUfreq driver support for Versatile Express big.LITTLE platforms using SPC for power management. - -config ARM_EXYNOS_CPUFREQ - bool - -config ARM_EXYNOS4210_CPUFREQ - bool "SAMSUNG EXYNOS4210" - depends on CPU_EXYNOS4210 && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4210 - SoC (S5PV310 or S5PC210). - - If in doubt, say N. - -config ARM_EXYNOS4X12_CPUFREQ - bool "SAMSUNG EXYNOS4x12" - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4X12 - SoC (EXYNOS4212 or EXYNOS4412). - - If in doubt, say N. - -config ARM_EXYNOS5250_CPUFREQ - bool "SAMSUNG EXYNOS5250" - depends on SOC_EXYNOS5250 && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS5250 - SoC. - - If in doubt, say N. - config ARM_EXYNOS5440_CPUFREQ bool "SAMSUNG EXYNOS5440" depends on SOC_EXYNOS5440 @@ -75,21 +38,6 @@ config ARM_EXYNOS5440_CPUFREQ If in doubt, say N. -config ARM_EXYNOS_CPU_FREQ_BOOST_SW - bool "EXYNOS Frequency Overclocking - Software" - depends on ARM_EXYNOS_CPUFREQ - select CPU_FREQ_BOOST_SW - select EXYNOS_THERMAL - help - This driver supports software managed overclocking (BOOST). - It allows usage of special frequencies for Samsung Exynos - processors if thermal conditions are appropriate. - - It reguires, for safe operation, thermal framework with properly - defined trip points. - - If in doubt, say N. - config ARM_HIGHBANK_CPUFREQ tristate "Calxeda Highbank-based" depends on ARCH_HIGHBANK && GENERIC_CPUFREQ_CPU0 && REGULATOR diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 738c8b7..8a75419 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -51,10 +51,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c deleted file mode 100644 index e8a4a7e..000 --- a/drivers/cpufreq/exynos-cpufreq.c +++ /dev/null @@ -1,218 +0,0 @@ -/* - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. - * http://www.samsung.com - * - * EXYNOS - CPU frequency scaling support for EXYNOS series - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. -*/ - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include "exynos-cpufreq.h" - -static struct exynos_dvfs_info *exynos_info; -static struct regulator *arm_regulator; -stat
[PATCH v5 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Thomas Abraham
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while preparing the cpufreq table
from the list of operating points available.
Cc: Shawn Guo
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig|1 +
drivers/cpufreq/cpufreq-cpu0.c |3 +++
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..60f321a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..52741b9 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
tristate "Generic CPU0 cpufreq driver"
depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
select PM_OPP
+ select CPU_FREQ_BOOST_SW
help
This adds a generic cpufreq driver for CPU0 frequency management.
It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..93d3d6d 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -194,6 +194,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
transition_latency += ret * 1000;
}
+ if (of_find_property(cpu_dev->of_node, "boost-frequencies", NULL))
+ cpu0_cpufreq_driver.boost_supported = true;
+
ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
if (ret) {
pr_err("failed register driver: %d\n", ret);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/7] Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5
From: Thomas Abraham The clock blocks within the CMU_CPU clock domain are put together into a new composite clock type called the cpu clock. This clock type requires configuration data that will be atomically programmed in the multiple clock blocks encapsulated within the cpu clock type when the parent clock frequency is changed. This configuration data is held in the clock controller node. Update clock binding documentation about this configuration data format for Samsung Exynos4 and Exynos5 platforms. Cc: Tomasz Figa Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Signed-off-by: Thomas Abraham --- .../devicetree/bindings/clock/exynos4-clock.txt| 37 .../devicetree/bindings/clock/exynos5250-clock.txt | 36 +++ 2 files changed, 73 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index f5a5b19..0934e02 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,6 +15,35 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + - for Exynos4210 and Exynos4212 based platforms: + cell #1: arm clock parent frequency + cell #2 ~ cell 9#: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio. + + - for Exynos4412 based platforms: + cell #1: expected arm clock parent frequency + cell #2 ~ cell #10: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio, cores_ratio + +- samsung,armclk-cells: defines the number of cells in + samsung,armclk-divider-table property. The value of this property depends on + the SoC type. + + - for Exynos4210 and Exynos4212: the value should be 9. + - for Exynos4412: the value should be 10. + Each clock is assigned an identifier and client nodes can use this identifier to specify the clock which they consume. @@ -28,6 +57,14 @@ Example 1: An example of a clock controller node is listed below. compatible = "samsung,exynos4210-clock"; reg = <0x1003 0x2>; #clock-cells = <1>; + + samsung,armclk-cells = <9>; + samsung,armclk-divider-table = <120 3 7 3 4 1 7 5 0>, + <100 3 7 3 4 1 7 4 0>, + < 80 3 7 3 3 1 7 3 0>, + < 50 3 7 3 3 1 7 3 0>, + < 40 3 7 3 3 1 7 3 0>, + < 20 1 3 1 1 1 0 3 0>; }; Example 2: UART controller node that consumes the clock generated by the clock diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 536eacd..3d63d09 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,6 +13,24 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + cell #1: expected arm clock parent frequency + cell #2 ~ cell #9: value of clock divider in the following order + cpud_ratio, acp_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio + +- samsun
[PATCH v5 4/7] clk: exynos: use cpu-clock provider type to represent arm clock
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos4.c | 25 +
drivers/clk/samsung/clk-exynos5250.c | 16 +++-
include/dt-bindings/clock/exynos5250.h |1 +
3 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index c4df294..fd235e4 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -471,7 +471,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
@@ -530,7 +531,8 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(0, "mout_jpeg", mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4x12, SRC_CAM, 4, 4),
MUX(CLK_MOUT_FIMC2, "mout_fimc2", group1_p4x12, SRC_CAM, 8, 4),
@@ -572,8 +574,10 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
- DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
+ DIV_F(0, "div_core", "mout_core", DIV_CPU0, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, "div_core2", "div_core", DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
@@ -619,8 +623,10 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
- DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
+ DIV_F(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
@@ -1005,7 +1011,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
static struct samsung_clock_alias exynos4_aliases[] __initdata = {
ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
- ALIAS(CLK_ARM_CLK, NULL, "armclk"),
ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
};
@@ -1244,6 +1249,8 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_gate_clks));
samsung_clk_register_alias(ctx, exynos4210_aliases,
ARRAY_SIZE(exynos4210_aliases));
+ exynos_register_arm_clock(ctx, CLK_ARM_CLK, mout_core_p4210[0],
+ mout_core_p4210[1], np);
} else {
[PATCH v5 0/7] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
Changes since v4:
- Various changes in clock code suggested by Tomasz Figa
- This series depends on mutiple other patches
[a] patch that introduces read-only attribute for clock dividers.
-
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/259264.html
[b] the series "PM / OPP: move cpufreq specific helpers out of OPP layer"
- https://www.mail-archive.com/linux-omap@vger.kernel.org/msg104610.html
[c] the series "cpufreq: opp: Add device tree based lookup of boost mode
frequency"
- http://www.spinics.net/lists/arm-kernel/msg334336.html
Changes since v3:
- Addressed comments from Tomasz Figa
[http://www.spinics.net/lists/cpufreq/msg09290.html]
- Rebased to v3.15-rc4
Changes since v2:
- Safe operating voltage is not required while switching APLL frequency
since the temporary parent's clock is divided down to keep armclk within
permissible limits. Thanks to Heiko Stuebner for
suggesting this.
- Rob had suggested to use max frequency for each of the divider clock
outputs instead of divider values. But due to certain SoC specific
characteristics, the divider values corresponding to the input clock
frequency for the CMU_CPU clock blocks have to be used.
Changes since v1:
- Removes Exynos4x12 and Exynos5250 cpufreq driver also.
- Device tree based clock configuration lookup as suggested by Lukasz
Majewski and Tomasz Figa.
- safe operating point binding reworked as suggested by Shawn Guo.
The patch series removes the use of Exynos specific cpufreq driver and enables
the use of cpufreq-cpu0 driver for Exynos4210, Exynos4x12 and Exynos5250 based
platforms. This is being done for few reasons.
(a) The Exynos cpufreq driver reads/writes clock controller registers
bypassing the Exynos 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).
Thomas Abraham (7):
cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
clk: samsung: add infrastructure to register cpu clocks
Documentation: devicetree: add cpu clock configuration data binding for
Exynos4/5
clk: exynos: use cpu-clock provider type to represent arm clock
ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
ARM: Exynos: switch to using generic cpufreq-cpu0 driver
cpufreq: exynos: remove all exynos specific cpufreq driver support
.../devicetree/bindings/clock/exynos4-clock.txt| 37 ++
.../devicetree/bindings/clock/exynos5250-clock.txt | 36 ++
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 +
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 | 35 ++
arch/arm/boot/dts/exynos4212.dtsi | 18 +
arch/arm/boot/dts/exynos4412-odroidx.dts |6 +
arch/arm/boot/dts/exynos4412-origen.dts|6 +
arch/arm/boot/dts/exynos4412-trats2.dts|6 +
arch/arm/boot/dts/exynos4412.dtsi | 31 ++
arch/arm/boot/dts/exynos4x12.dtsi | 36 ++
arch/arm/boot/dts/exynos5250-arndale.dts |6 +
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +
arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +
arch/arm/boot/dts/exynos5250.dtsi | 41 ++
arch/arm/mach-exynos/exynos.c |4 +-
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 448
drivers/clk/samsung/clk-exynos4.c | 25 +-
drivers/clk/samsung/clk-exynos5250.c | 16 +-
drivers/clk/samsung/clk.h |4 +
drivers/cpufreq/Kconfig|1 +
drivers/cpufreq/Kconfig.arm| 52 ---
drivers/cpufreq/Makefile |4 -
drivers/cpufreq/cpufreq-cpu0.c |3 +
drivers/cpufreq/exynos-cpufreq.c | 218 --
drivers/cpufreq/exynos-cpufreq.h | 99 -
drivers/cpufreq/exynos4210-cpufreq.c | 157 ---
drivers/cpufreq/exynos4x12-cpufreq.c | 208 -
drivers/cpufreq/exynos5250-cpufreq.c | 183
include/dt-bindings/clock/exynos5250.h |1 +
33 files changed, 779 insertions(+), 936 deletions(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
delete mode 100644 drivers/cpufreq/exynos-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos-cpufreq.h
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c
delete mode 100644 d
[PATCH v4 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
drivers/cpufreq/cpufreq_opp.c | 44 +
1 file changed, 44 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..2b3905b 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ int j, len;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +87,45 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = &freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev->of_node, "boost-frequencies", &len)) {
+ struct cpufreq_frequency_table *ft;
+
+ if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, "%s: invalid boost frequency\n", __func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, "%s: no memory for boost freq table\n",
+ __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+ of_property_read_u32_array(dev->of_node, "boost-frequencies",
+ boost_freqs, len / sizeof(u32));
+
+ for (j = 0; j < len / sizeof(u32); j++) {
+ ft = *table;
+ for (i = 0; ft->frequency != CPUFREQ_TABLE_END; i++) {
+ if (boost_freqs[j] == ft->frequency) {
+ ft->flags |= CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ ft++;
+ }
+
+ if (ft->frequency == CPUFREQ_TABLE_END)
+ pr_err("%s: invalid boost frequency %d\n",
+ __func__, boost_freqs[j]);
+ }
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
Changes since v3:
- Minor changes as suggested in the last version.
Changes since v2:
- Reworked based on the "PM / OPP: move cpufreq specific helpers out of OPP
layer" patch series posted by Nishanth Menon .
Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
feedback.
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.
Thomas Abraham (2):
cpufreq / OPP: Allow boost frequency to be looked up from device tree
Documentation: devicetree: Add boost-frequency binding to list boost
mode frequency
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38 +
drivers/cpufreq/cpufreq_opp.c | 44
2 files changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham
Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 000..63ed0fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,38 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred
as
+overclocking) in which the CPU can operate at frequencies which are not
+specified by the manufacturer as CPU's operating frequency.
+
+Optional Properties:
+- boost-frequencies: list of frequencies in KHz to be used only in boost mode.
+ This list should be a subset of frequencies listed in "operating-points"
+ property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+ details about "operating-points" property.
+
+Example:
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+
+ operating-points = <
+ 150 135
+ 140 1287500
+ 130 125
+ 120 1187500
+ 110 1137500
+ 100 1087500
+ >;
+ boost-frequencies = <150 140>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/8] clk: exynos: use cpu-clock provider type to represent arm clock.
On Thu, May 15, 2014 at 3:07 AM, Mike Turquette wrote:
> Quoting Thomas Abraham (2014-05-13 18:11:13)
>> From: Thomas Abraham
>>
>> With the addition of the new Samsung specific cpu-clock type, the
>> arm clock can be represented as a cpu-clock type and the independent
>> clock blocks that made up the arm clock can be removed.
>
>
>
> I am not a fan of this type of "clock hiding". Certainly the design of
> the CCF allows for a clock provider to obfuscate it's internals; there
> was never a requirement that every clock node be exposed to Linux as a
> struct clk. A truly obfuscated system could only expose leaf clocks that
> are consumed by Linux device drivers, and never expose any of the
> intermediary clocks in between the input clock signal (if it exists) and
> the leaf nodes.
>
> However I feel that this patch is more of a workaround to the fact that
> the clock framework today does not make DVFS transitions (or
> coordinated, multi-clock rate change transitions) easy to control. The
> generic "walk up the tree" algorithm might give you the right rate, but
> perhaps using a non-validated combination of PLL frequency and
> adjustable-rate dividers, or a combination that his higher jitter or is
> more likely to unlock at higher temperatures, etc.
>
> Back in the pre-CCF days lots of folks implemented this with "virtual"
> clock nodes that simply called "clk_set_rate" or whatever on the
> affected clocks, or even worse just banged a bunch of registers.
>
> The cbus clock series for Tegra is also looks a little like this.
>
>
>
> Thomas,
>
> Would a coordinated clock rate change method solve this problem for you
> in place of the cpu-clock provider type? A poorly conceived call graph
> for this might look something like:
>
> clk_set_rate(div_arm2, 100);
> -> if (div_arm2->coordinated == true)
> clk_coordinate_rates(div_arm2, 100);
> -> clk->ops->coordinate(div_arm2->hw, 100);
>-> vendor_supplied_magic()
>
> The vendor_supplied_magic() would be a callback that essentially calls
> clk_set_rate() on all of the affected (coordinated) clocks. In your case
> that looks like mout_core, div_core, div_core2, arm_clk and sclk_apll
> for Exynos4.
>
> The trick is that calling clk_set_rate() from any driver would initiate
> this coordinated rate change, and then the exynos clock driver would set
> up the coordinated clocks itself. No new API is introduced to drivers
> (since it still uses clk_set_rate) and now a new clock provider doesn't
> have to be invented every time we have a couple of clocks involved in a
> DVFS transition.
>
> Does this sound right to you or have I horribly misinterpreted the point
> of these clock patches?
>
> Thanks,
> Mike
Hi Mike,
I have been testing this patch series on three exynos platforms for
about five days now and do not see any issues. There are some review
comments which I need to incorporate. So before that, I wanted to
check with you about the grouping of clocks approach in this patch
series. Is this approach something that we could use until the changes
for coordinated clocks are in place? This patch series also helps with
multi-platform support for exynos as well.
Tomasz, I have addressed most of your comments from v3. If you could
have a look at the v4 series as well, it would be helpful in making
this better.
Thanks,
Thomas.
>
>>
>> Cc: Tomasz Figa
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 25 +
>> drivers/clk/samsung/clk-exynos5250.c | 12 ++--
>> include/dt-bindings/clock/exynos5250.h |1 +
>> 3 files changed, 16 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> b/drivers/clk/samsung/clk-exynos4.c
>> index b4f9672..7e3bb16c 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>> @@ -471,7 +471,6 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
>> __initdata = {
>> MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
>> MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
>> MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
>> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
>> MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
>> MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
>> MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
>>
Re: [PATCH v4 3/8] clk: samsung: add infrastructure to register cpu clocks
On Fri, May 16, 2014 at 1:56 AM, Doug Anderson wrote:
> Heiko,
>
> On Thu, May 15, 2014 at 1:12 PM, Heiko Stübner wrote:
>> Hi Doug,
>>
>> Am Donnerstag, 15. Mai 2014, 12:36:45 schrieb Doug Anderson:
>>> On Thu, May 15, 2014 at 12:17 PM, Heiko Stübner wrote:
>>> > Am Donnerstag, 15. Mai 2014, 11:18:44 schrieb Doug Anderson:
>>> >> Thomas,
>>> >>
>>> >> On Tue, May 13, 2014 at 6:11 PM, Thomas Abraham
>> wrote:
>>> >> > From: Thomas Abraham
>>> >> > +static int exynos4210_armclk_pre_rate_change(struct clk_notifier_data
>>> >> > *ndata, + struct exynos_cpuclk *armclk, void
>>> >> > __iomem *base) +{
>>> >> > + struct exynos4210_armclk_data *armclk_data = armclk->data;
>>> >> > + unsigned long alt_prate = clk_get_rate(armclk->alt_parent);
>>> >> > + unsigned long alt_div, div0, div1, tdiv0, mux_reg;
>>> >> > + unsigned long cur_armclk_rate, timeout;
>>> >> > + unsigned long flags;
>>> >> > +
>>> >> > + /* find out the divider values to use for clock data */
>>> >> > + while (armclk_data->prate != ndata->new_rate) {
>>> >> > + if (armclk_data->prate == 0)
>>> >> > + return -EINVAL;
>>> >> > + armclk_data++;
>>> >> > + }
>>> >> > +
>>> >> > + div0 = armclk_data->div0;
>>> >> > + div1 = armclk_data->div1;
>>> >> > + if (readl(base + SRC_CPU) & EXYNOS4210_MUX_HPM_MASK) {
>>> >> > + div1 = readl(base + DIV_CPU1) &
>>> >> > EXYNOS4210_DIV1_HPM_MASK;
>>> >> > + div1 |= ((armclk_data->div1) &
>>> >> > ~EXYNOS4210_DIV1_HPM_MASK);
>>> >> > + }
>>> >> > +
>>> >> > + /*
>>> >> > +* if the new and old parent clock speed is less than the clock
>>> >> > speed +* of the alternate parent, then it should be ensured
>>> >> > that
>>> >> > at no point +* the armclk speed is more than the old_prate
>>> >> > until
>>> >> > the dividers are +* set.
>>> >> > +*/
>>> >> > + tdiv0 = readl(base + DIV_CPU0);
>>> >> > + cur_armclk_rate = ndata->old_rate / EXYNOS4210_ARM_DIV1(tdiv0)
>>> >> > /
>>> >> > + EXYNOS4210_ARM_DIV2(tdiv0);
>>> >> > + if (alt_prate > cur_armclk_rate) {
>>> >> > + alt_div = _calc_div(alt_prate, cur_armclk_rate);
>>> >> > + _exynos4210_set_armclk_div(base, alt_div);
>>> >> > + div0 |= alt_div;
>>> >>
>>> >> Don't you need to up the voltage here, too? ...I haven't reviewed
>>> >> this whole patch (so perhaps it's elsewhere in the patch or in the
>>> >> series), but I stumbled upon this while trying to solve a different
>>> >> problem and figured I'd check...
>>> >
>>> > setting the voltage should be done by the cpufreq driver like cpufreq-cpu0
>>> > - whose usage this series intents to allow.
>>> >
>>> > As I've hijacked Thomas' concept for my current rockchip clock work, I've
>>> > already seen this working nicely :-) .
>>>
>>> I guess I should have been more clear. I was talking more
>>> specifically about upping the voltage as part of the mux switch in the
>>> case that alt_prate > cur_armclk_rate.
>>
>> from earlier discussions I remember Thomas and me talked about setting a
>> divider to make sure that alt_prate <= cur_armclk_rate, so the voltage can
>> stay at its current level. I haven't looked deeply into this revision, but
>> the
>> last one did exactly this.
>
> Ah-ha, that's a reasonable solution to this problem. I was familiar
> with the old code and know that it used to set the CPUD ratio here, so
> I assumed that was what Thomas's code did. ...but you're right, his
> code is setting the divider here. I didn't double-check all of his
> code / calculations, but he's certainly tweaking the right bits.
>
>
Re: [PATCH v4 5/8] clk: exynos: use cpu-clock provider type to represent arm clock.
On Thu, May 15, 2014 at 1:40 PM, Lukasz Majewski wrote: > Hi Thomas, > >> On Thu, May 15, 2014 at 3:07 AM, Mike Turquette >> wrote: >> > Quoting Thomas Abraham (2014-05-13 18:11:13) >> >> From: Thomas Abraham >> >> >> >> With the addition of the new Samsung specific cpu-clock type, the >> >> arm clock can be represented as a cpu-clock type and the >> >> independent clock blocks that made up the arm clock can be removed. >> > >> > >> > >> > I am not a fan of this type of "clock hiding". Certainly the design >> > of the CCF allows for a clock provider to obfuscate it's internals; >> > there was never a requirement that every clock node be exposed to >> > Linux as a struct clk. A truly obfuscated system could only expose >> > leaf clocks that are consumed by Linux device drivers, and never >> > expose any of the intermediary clocks in between the input clock >> > signal (if it exists) and the leaf nodes. >> > >> > However I feel that this patch is more of a workaround to the fact >> > that the clock framework today does not make DVFS transitions (or >> > coordinated, multi-clock rate change transitions) easy to control. >> > The generic "walk up the tree" algorithm might give you the right >> > rate, but perhaps using a non-validated combination of PLL >> > frequency and adjustable-rate dividers, or a combination that his >> > higher jitter or is more likely to unlock at higher temperatures, >> > etc. >> > >> > Back in the pre-CCF days lots of folks implemented this with >> > "virtual" clock nodes that simply called "clk_set_rate" or whatever >> > on the affected clocks, or even worse just banged a bunch of >> > registers. >> > >> > The cbus clock series for Tegra is also looks a little like this. >> > >> > >> > >> > Thomas, >> > >> > Would a coordinated clock rate change method solve this problem for >> > you in place of the cpu-clock provider type? A poorly conceived >> > call graph for this might look something like: >> > >> > clk_set_rate(div_arm2, 100); >> > -> if (div_arm2->coordinated == true) >> > clk_coordinate_rates(div_arm2, 100); >> > -> clk->ops->coordinate(div_arm2->hw, 100); >> >-> vendor_supplied_magic() >> > >> > The vendor_supplied_magic() would be a callback that essentially >> > calls clk_set_rate() on all of the affected (coordinated) clocks. >> > In your case that looks like mout_core, div_core, div_core2, >> > arm_clk and sclk_apll for Exynos4. > > I might misinterpret the idea here, but is clk_set_rate() function > ready to handle atomic change for several clocks? Especially setting > rate of dividers located in the same register, represented as different > clocks to CCF. > > As fair as I remember it was not possible to serialize operations on > clocks with calling clk_set_rate() several times. Those had to be done > instantly, otherwise platform hanged. > > Am I missing something, or a major improvement had I overlooked? Hi Lukasz, Not sure what Mike would suggest here, but probably the clk_set_rate() itself might not be called for coordinated clocks. It could be some internal clock framework function that takes care of setting rate of coordinated clocks. I don't have a good understanding of how the implementation for this will look like. Thanks, Thomas. > >> > >> > The trick is that calling clk_set_rate() from any driver would >> > initiate this coordinated rate change, and then the exynos clock >> > driver would set up the coordinated clocks itself. No new API is >> > introduced to drivers (since it still uses clk_set_rate) and now a >> > new clock provider doesn't have to be invented every time we have a >> > couple of clocks involved in a DVFS transition. >> > >> > Does this sound right to you or have I horribly misinterpreted the >> > point of these clock patches? >> >> Mike, >> >> Thanks for your comments. If I have understood the coordinated clock >> as described above, I believe this patch series also attempts to do >> almost the same thing. The advantage of using coordinated clock over >> the approach in this series is that each platform need not define a >> new clock type. >> >> In this patch series, for all exynos SoC's, a new cpu clock type was >> introduced which is reusab
Re: [PATCH v4 5/8] clk: exynos: use cpu-clock provider type to represent arm clock.
On Thu, May 15, 2014 at 3:07 AM, Mike Turquette wrote:
> Quoting Thomas Abraham (2014-05-13 18:11:13)
>> From: Thomas Abraham
>>
>> With the addition of the new Samsung specific cpu-clock type, the
>> arm clock can be represented as a cpu-clock type and the independent
>> clock blocks that made up the arm clock can be removed.
>
>
>
> I am not a fan of this type of "clock hiding". Certainly the design of
> the CCF allows for a clock provider to obfuscate it's internals; there
> was never a requirement that every clock node be exposed to Linux as a
> struct clk. A truly obfuscated system could only expose leaf clocks that
> are consumed by Linux device drivers, and never expose any of the
> intermediary clocks in between the input clock signal (if it exists) and
> the leaf nodes.
>
> However I feel that this patch is more of a workaround to the fact that
> the clock framework today does not make DVFS transitions (or
> coordinated, multi-clock rate change transitions) easy to control. The
> generic "walk up the tree" algorithm might give you the right rate, but
> perhaps using a non-validated combination of PLL frequency and
> adjustable-rate dividers, or a combination that his higher jitter or is
> more likely to unlock at higher temperatures, etc.
>
> Back in the pre-CCF days lots of folks implemented this with "virtual"
> clock nodes that simply called "clk_set_rate" or whatever on the
> affected clocks, or even worse just banged a bunch of registers.
>
> The cbus clock series for Tegra is also looks a little like this.
>
>
>
> Thomas,
>
> Would a coordinated clock rate change method solve this problem for you
> in place of the cpu-clock provider type? A poorly conceived call graph
> for this might look something like:
>
> clk_set_rate(div_arm2, 100);
> -> if (div_arm2->coordinated == true)
> clk_coordinate_rates(div_arm2, 100);
> -> clk->ops->coordinate(div_arm2->hw, 100);
>-> vendor_supplied_magic()
>
> The vendor_supplied_magic() would be a callback that essentially calls
> clk_set_rate() on all of the affected (coordinated) clocks. In your case
> that looks like mout_core, div_core, div_core2, arm_clk and sclk_apll
> for Exynos4.
>
> The trick is that calling clk_set_rate() from any driver would initiate
> this coordinated rate change, and then the exynos clock driver would set
> up the coordinated clocks itself. No new API is introduced to drivers
> (since it still uses clk_set_rate) and now a new clock provider doesn't
> have to be invented every time we have a couple of clocks involved in a
> DVFS transition.
>
> Does this sound right to you or have I horribly misinterpreted the point
> of these clock patches?
Mike,
Thanks for your comments. If I have understood the coordinated clock
as described above, I believe this patch series also attempts to do
almost the same thing. The advantage of using coordinated clock over
the approach in this series is that each platform need not define a
new clock type.
In this patch series, for all exynos SoC's, a new cpu clock type was
introduced which is reusable for multi-cluster exynos SoCs as well.
The new clock type is part of the clock driver and all drivers can use
standard clock API to access this clock type instance.
So probably, all the logic for the new cpu_clk clock type introduced
in this patch would go into the vendor_supplied_magic() callback. So
it sounds like the coordinated clock approach would be helpful. Is
this something that you are already working on?
Thanks,
Thomas.
>
> Thanks,
> Mike
>
>>
>> Cc: Tomasz Figa
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 25 +
>> drivers/clk/samsung/clk-exynos5250.c | 12 ++--
>> include/dt-bindings/clock/exynos5250.h |1 +
>> 3 files changed, 16 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> b/drivers/clk/samsung/clk-exynos4.c
>> index b4f9672..7e3bb16c 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>> @@ -471,7 +471,6 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
>> __initdata = {
>> MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
>> MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
>> MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
>> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
>> MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, S
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On Wed, May 14, 2014 at 7:20 PM, Viresh Kumar wrote:
> On 14 May 2014 19:13, Thomas Abraham wrote:
>> Okay, so you are suggesting that Kconfig entry used to select
>> cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well.
>
> I never said that... That should be enabled by your defconfig instead.
> What I said was, don't put code within any #ifdefs in cpufreq-cpu0.
Okay, I get the point about #ifdef in cpufreq-cpu0. What about your
earlier comment about the new Kconfig entry ("Get rid of this.. just
not required.")? The new Kconfig entry would be needed in that case.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wed, May 14, 2014 at 6:20 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 06:41:15 Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Remove the platform device instantiation for Exynos specific cpufreq
>> driver and add the platform device for cpufreq-cpu0 driver.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/mach-exynos/exynos.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index b32a907..489a495 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -232,7 +232,9 @@ void __init exynos_cpuidle_init(void)
>>
>> void __init exynos_cpufreq_init(void)
>> {
>> - platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
>> + if (!(of_machine_is_compatible("samsung,exynos5420")) &&
>> + !(of_machine_is_compatible("samsung,exynos5440")))
>> + platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
>> }
>>
>
> Could we please come up with a way to probe this from DT in the cpufreq-cpu0
> driver itself, so we don't have to add a device in every platform using it?
Okay, I don't have a solution for this as of now. Would this be
considered as a blocker for this series? I hope we could just live
with this for now.
Thanks,
Thomas.
>
> I realize you copied it from the other platforms using this driver, but
> it still seems really wrong.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wed, May 14, 2014 at 6:41 PM, Heiko Stübner wrote: > Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: >> On 14 May 2014 18:20, Arnd Bergmann wrote: >> > Could we please come up with a way to probe this from DT in the >> > cpufreq-cpu0 driver itself, so we don't have to add a device in every >> > platform using it? >> Its followed that way because DT Maintainers had strong objections >> to creating virtual device nodes and haven't allowed creation of nodes >> for cpufreq drivers.. For which there is no physical device, as CPU already >> has a separate node.. > > as we already have the "enable-method" property for enabling/disabling cpus, > would something like a "scaling-method" be feasible? > "scaling-method" also sounds like a software specific property. Would that be something that will be acceptable in dt? -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Lukasz, On Wed, May 14, 2014 at 12:50 PM, Lukasz Majewski wrote: > Hi Thomas, > >> -config ARM_EXYNOS_CPU_FREQ_BOOST_SW >> - bool "EXYNOS Frequency Overclocking - Software" >> - depends on ARM_EXYNOS_CPUFREQ >> - select CPU_FREQ_BOOST_SW >> - select EXYNOS_THERMAL >> - help >> - This driver supports software managed overclocking (BOOST). >> - It allows usage of special frequencies for Samsung Exynos >> - processors if thermal conditions are appropriate. >> - >> - It reguires, for safe operation, thermal framework with >> properly >> - defined trip points. >> - >> - If in doubt, say N. >> - > > If I might ask, where this switch,to enable BOOST, will be moved? All > in all, I would like to be able to enable boost :-). The intent was to have a separate boost config option for cpufreq-cpu0 driver, only available if cpufreq-cpu0 driver is selected, as done in the other patch. > > In my opinion we should have the Kconfig option to enable/disable the > CPU_FREQ_BOOST_SW and this may be used with cpufreq-cpu0 driver as I've > pointed out in the other patch. Okay, this is how this patch series handles CPU_FREQ_BOOST_SW config option. Thanks, Thomas. > > -- > Best regards, > > Lukasz Majewski > > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Wed, May 14, 2014 at 11:54 AM, Viresh Kumar wrote: > On 14 May 2014 11:39, Lukasz Majewski wrote: >> I agree with Nishanth here, that point 1 (as described by Viresh at >> [*]) is a more scalable approach. > > The only reason why I wanted all that to be done at OPP level was to > ensure if somebody else also needs it apart from cpufreq, they don't have > to duplicate code and find it.. As it is present at a central place.. > > But if no other code is going to look for that, it may just be fine as is.. Yes, I agree with Nishanth and Lukasz for a separate binding. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Wed, May 14, 2014 at 9:10 AM, Viresh Kumar wrote:
> On 14 May 2014 06:32, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/cpufreq/cpufreq_opp.c | 39 +++
>> 1 files changed, 39 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
>> index c0c6f4a..e3c97f3 100644
>> --- a/drivers/cpufreq/cpufreq_opp.c
>> +++ b/drivers/cpufreq/cpufreq_opp.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
>> @@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> struct cpufreq_frequency_table *freq_table = NULL;
>> int i, max_opps, ret = 0;
>> unsigned long rate;
>> +#ifdef CONFIG_CPU_FREQ_BOOST_SW
>> + int j, len;
>> + u32 *boost_freqs = NULL;
>> +#endif
>>
>> rcu_read_lock();
>>
>> @@ -82,6 +87,40 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>
>> *table = &freq_table[0];
>>
>> +#ifdef CONFIG_CPU_FREQ_BOOST_SW
>> + if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>
> Does this mean another block inside the cpu node ? Like this: ?
>
> cpu@0 {
> compatible = "arm,cortex-a9";
> reg = <0>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHzuV */
> 792000 110
> 396000 95
> 198000 85
> >;
> boost-frequency = <
> 792000
> 198000
> >;
> };
>
> I think it we might better add another field in the opp block as these
> OPPs are rather boost one..
>
> @Rob/Rafael: Opinion please ..
>
>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> + dev_err(dev, "%s: invalid boost frequency\n",
>> __func__);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>> + if (!boost_freqs) {
>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>> + __func__);
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> + of_property_read_u32_array(dev->of_node, "boost-frequency",
>> + boost_freqs, len / sizeof(u32));
>> + }
>> +
>> + for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>
> Why is this present outside of above if {} ? as boost_freqs is guaranteed to
> be NULL without that.
Just to reduce indentation by one tab. No technical reasons. The code
had to wrap at 80 column was becoming unreadable.
>
>> + for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END;
>> i++) {
>> + if (boost_freqs[j] == freq_table[i].frequency) {
>
> Use cpufreq_frequency_table_get_index() instead.
Okay. Thanks for pointing out.
>
>> + freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
>> + break;
>> + }
>> + }
>> + if (freq_table[i].frequency == CPUFREQ_TABLE_END)
>> + pr_err("%s: invalid boost frequency %d\n",
>> + __func__, boost_freqs[j]);
>> + }
>> +
>> + kfree(boost_freqs);
>> +#endif
>> +
>> out:
>> rcu_read_unlock();
>> if (ret)
>> --
>> 1.7.4.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
Hi Lukasz, Viresh, On Wed, May 14, 2014 at 11:50 AM, Viresh Kumar wrote: > On 14 May 2014 11:47, Lukasz Majewski wrote: >> I think that you can rely solely on the CPU_FREQ_BOOST_SW flag if the >> original author of cpufreq-cpu0.c don't mind. > > We don't have to. struct cpufreq_driver: boost_supported is always available. > Just update it without any ugly #ifdefs .. Okay, so you are suggesting that Kconfig entry used to select cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well. Considering that exynos4412 is the only user of this feature in mainline, should we do this? -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/8] clk: samsung: change scope of samsung clock lock to global
On Wed, May 14, 2014 at 9:20 AM, Viresh Kumar wrote: > On 14 May 2014 06:41, Thomas Abraham wrote: >> From: Thomas Abraham >> >> Access to samsung clock lock is required to support newer samsung specific >> clock types. So change the scope of the samsung clock lock to global. And > > Maybe bit more detail on why exactly it should be available outside this file. Okay, will do in the next version. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Wed, May 14, 2014 at 7:32 AM, Nishanth Menon wrote: > On Tue, May 13, 2014 at 8:03 PM, Thomas Abraham wrote: >> From: Thomas Abraham >> >> Add a new optional boost-frequency binding for specifying the frequencies >> usable in boost mode. >> >> Cc: Nishanth Menon >> Cc: Lukasz Majewski >> Cc: Rob Herring >> Cc: Pawel Moll >> Cc: Mark Rutland >> Cc: Ian Campbell >> Cc: Kumar Gala >> Signed-off-by: Thomas Abraham >> --- >> .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ >> 1 files changed, 11 insertions(+), 0 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> new file mode 100644 >> index 000..d925e38 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> @@ -0,0 +1,11 @@ >> +* Device tree binding for CPU boost frequency (aka over-clocking) >> + >> +Certain CPU's can be operated in optional 'boost' mode (or sometimes >> referred as >> +overclocking) in which the CPU can operate in frequencies beyond the normal > > "operate at"? > >> +operating conditions. > > "normal operating conditions" probably need a little bit of an > expansion here perhaps? > >> + >> +Optional Properties: >> +- boost-frequency: list of frequencies in KHz to be used only in boost mode. > > probably boost-frequencies? > >> + This list should be a subset of frequencies listed in "operating-points" >> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for >> + details about "operating-points" property. > > > an example is expected here. > > personally, I think I understand the intent here, but as a hardware > description, will let folks comment if it is acceptable. Thanks for your review Nishanth. I will do the changes you have suggested. Regards, Thomas. > > -- > Regards, > Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed. Signed-off-by: Thomas Abraham --- drivers/cpufreq/Kconfig.arm | 52 - drivers/cpufreq/Makefile |4 - drivers/cpufreq/exynos-cpufreq.c | 209 - drivers/cpufreq/exynos-cpufreq.h | 91 --- drivers/cpufreq/exynos4210-cpufreq.c | 157 - drivers/cpufreq/exynos4x12-cpufreq.c | 211 -- drivers/cpufreq/exynos5250-cpufreq.c | 183 - 7 files changed, 0 insertions(+), 907 deletions(-) delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 5805035..9721674 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -24,43 +24,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ This add the CPUfreq driver support for Versatile Express big.LITTLE platforms using SPC for power management. - -config ARM_EXYNOS_CPUFREQ - bool - -config ARM_EXYNOS4210_CPUFREQ - bool "SAMSUNG EXYNOS4210" - depends on CPU_EXYNOS4210 && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4210 - SoC (S5PV310 or S5PC210). - - If in doubt, say N. - -config ARM_EXYNOS4X12_CPUFREQ - bool "SAMSUNG EXYNOS4x12" - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4X12 - SoC (EXYNOS4212 or EXYNOS4412). - - If in doubt, say N. - -config ARM_EXYNOS5250_CPUFREQ - bool "SAMSUNG EXYNOS5250" - depends on SOC_EXYNOS5250 && !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS5250 - SoC. - - If in doubt, say N. - config ARM_EXYNOS5440_CPUFREQ bool "SAMSUNG EXYNOS5440" depends on SOC_EXYNOS5440 @@ -75,21 +38,6 @@ config ARM_EXYNOS5440_CPUFREQ If in doubt, say N. -config ARM_EXYNOS_CPU_FREQ_BOOST_SW - bool "EXYNOS Frequency Overclocking - Software" - depends on ARM_EXYNOS_CPUFREQ - select CPU_FREQ_BOOST_SW - select EXYNOS_THERMAL - help - This driver supports software managed overclocking (BOOST). - It allows usage of special frequencies for Samsung Exynos - processors if thermal conditions are appropriate. - - It reguires, for safe operation, thermal framework with properly - defined trip points. - - If in doubt, say N. - config ARM_HIGHBANK_CPUFREQ tristate "Calxeda Highbank-based" depends on ARCH_HIGHBANK && GENERIC_CPUFREQ_CPU0 && REGULATOR diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 738c8b7..8a75419 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -51,10 +51,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c deleted file mode 100644 index f99cfe2..000 --- a/drivers/cpufreq/exynos-cpufreq.c +++ /dev/null @@ -1,209 +0,0 @@ -/* - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. - * http://www.samsung.com - * - * EXYNOS - CPU frequency scaling support for EXYNOS series - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. -*/ - -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include "exynos-cpufreq.h" - -static struct exynos_dvfs_info *exynos_info; -static struct regulator *a
[PATCH v4 6/8] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
From: Thomas Abraham
For all Exynos based platforms, add CPU nodes, operating points and cpu
clock data for migrating from Exynos specific cpufreq driver to using
generic cpufreq-cpu0 driver.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
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 | 35 +++
arch/arm/boot/dts/exynos4212.dtsi | 18 ++
arch/arm/boot/dts/exynos4412-odroidx.dts|6 +++
arch/arm/boot/dts/exynos4412-origen.dts |6 +++
arch/arm/boot/dts/exynos4412-trats2.dts |6 +++
arch/arm/boot/dts/exynos4412.dtsi | 31 +
arch/arm/boot/dts/exynos4x12.dtsi | 36
arch/arm/boot/dts/exynos5250-arndale.dts|6 +++
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +++
arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +++
arch/arm/boot/dts/exynos5250.dtsi | 41 +++
14 files changed, 215 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f..4324b25 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&buck1_reg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63aa2bb..7cc0a57 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&varm_breg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b2..844f3fb 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&vdd_arm_reg>;
+ };
+ };
+
mct@1005 {
compatible = "none";
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..22b967d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -36,6 +36,33 @@
reg = <0x10023CA0 0x20>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+
+ operating-points = <
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
+ >;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x8000>;
};
@@ -73,6 +100,14 @@
compatible = "samsung,exynos4210-clock";
reg = <0x1003 0x2>;
#clock-cells = <1>;
+
+ samsung,armclk-cells = <9>;
+ samsung,armclk-divider-table = <120 3 7 3 4 1 7 5 0>,
+ <100 3 7 3 4 1 7 4 0>,
+ < 80 3 7 3 3 1 7 3 0>,
+ < 50 3 7 3 3 1 7 3 0>,
+
[PATCH v4 5/8] clk: exynos: use cpu-clock provider type to represent arm clock.
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos4.c | 25 +
drivers/clk/samsung/clk-exynos5250.c | 12 ++--
include/dt-bindings/clock/exynos5250.h |1 +
3 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..7e3bb16c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -471,7 +471,6 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
@@ -530,7 +529,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(0, "mout_jpeg", mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4x12, SRC_CAM, 4, 4),
MUX(CLK_MOUT_FIMC2, "mout_fimc2", group1_p4x12, SRC_CAM, 8, 4),
@@ -572,8 +570,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
- DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
@@ -619,8 +615,8 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
- DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
+ DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, 0),
DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
@@ -1003,12 +999,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
0),
};
-static struct samsung_clock_alias exynos4_aliases[] __initdata = {
- ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
- ALIAS(CLK_ARM_CLK, NULL, "armclk"),
- ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
-};
-
static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
ALIAS(CLK_SCLK_MPLL, NULL, "mout_mpll"),
};
@@ -1241,6 +1231,9 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_gate_clks));
samsung_clk_register_alias(exynos4210_aliases,
ARRAY_SIZE(exynos4210_aliases));
+ exynos_register_arm_clock(CLK_ARM_CLK, mout_core_p4210,
+ ARRAY_SIZE(mout_core_p4210), reg_base, np, NULL,
+ &samsung_clk_lock);
} else {
samsung_clk_register_mux(exynos4x12_mux_clks,
ARRAY_SIZE(exynos4x12_mux_clks));
@@ -1250,11 +1243,11 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4x12_gate_clks));
samsung_clk_register_alias(exynos4x12_aliases,
ARRAY_SIZE(exynos4x12_aliases));
+ exynos_register_arm_clock(CLK_ARM_CLK, mout_core_p4x12,
+ ARRAY_SIZE(mout_core_p4x12), reg_base, np, NULL,
+
[PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
From: Thomas Abraham
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..489a495 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -232,7 +232,9 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
+ if (!(of_machine_is_compatible("samsung,exynos5420")) &&
+ !(of_machine_is_compatible("samsung,exynos5440")))
+ platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
}
void __init exynos_init_late(void)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/8] Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5
From; Thomas Abraham The clock blocks within the CMU_CPU clock domain are put together into a new composite clock type called the cpu clock. This clock type requires configuration data that will be atomically programmed in the multiple clock blocks encapsulated within the cpu clock type when the parent clock frequency is changed. This configuration data is held in the clock controller node. Update clock binding documentation about this configuration data format for Samsung Exynos4 and Exynos5 platforms. Cc: Tomasz Figa Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Signed-off-by: Thomas Abraham --- .../devicetree/bindings/clock/exynos4-clock.txt| 37 .../devicetree/bindings/clock/exynos5250-clock.txt | 36 +++ 2 files changed, 73 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index f5a5b19..0934e02 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,6 +15,35 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + - for Exynos4210 and Exynos4212 based platforms: + cell #1: arm clock parent frequency + cell #2 ~ cell 9#: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio. + + - for Exynos4412 based platforms: + cell #1: expected arm clock parent frequency + cell #2 ~ cell #10: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio, cores_ratio + +- samsung,armclk-cells: defines the number of cells in + samsung,armclk-divider-table property. The value of this property depends on + the SoC type. + + - for Exynos4210 and Exynos4212: the value should be 9. + - for Exynos4412: the value should be 10. + Each clock is assigned an identifier and client nodes can use this identifier to specify the clock which they consume. @@ -28,6 +57,14 @@ Example 1: An example of a clock controller node is listed below. compatible = "samsung,exynos4210-clock"; reg = <0x1003 0x2>; #clock-cells = <1>; + + samsung,armclk-cells = <9>; + samsung,armclk-divider-table = <120 3 7 3 4 1 7 5 0>, + <100 3 7 3 4 1 7 4 0>, + < 80 3 7 3 3 1 7 3 0>, + < 50 3 7 3 3 1 7 3 0>, + < 40 3 7 3 3 1 7 3 0>, + < 20 1 3 1 1 1 0 3 0>; }; Example 2: UART controller node that consumes the clock generated by the clock diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 536eacd..3d63d09 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,6 +13,24 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + cell #1: expected arm clock parent frequency + cell #2 ~ cell #9: value of clock divider in the following order + cpud_ratio, acp_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm
[PATCH v4 3/8] clk: samsung: add infrastructure to register cpu clocks
From: Thomas Abraham
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 458 +
drivers/clk/samsung/clk.h |5 +
3 files changed, 464 insertions(+), 1 deletions(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..e2b453f 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..6a40862
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the cpu clocks
+ * for samsung platforms.
+*/
+
+#include
+#include "clk.h"
+
+#define SRC_CPU0x0
+#define STAT_CPU 0x200
+#define DIV_CPU0 0x300
+#define DIV_CPU1 0x304
+#define DIV_STAT_CPU0 0x400
+#define DIV_STAT_CPU1 0x404
+
+#define MAX_DIV8
+
+#define EXYNOS4210_ARM_DIV1(div) ((div & 0x7) + 1)
+#define EXYNOS4210_ARM_DIV2(div) (((div >> 28) & 0x7) + 1)
+
+#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0)\
+ ((d5 << 24) | (d4 << 20) | (d3 << 16) | (d2 << 12) |\
+(d1 << 8) | (d0 << 4))
+#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
\
+ ((d2 << 8) | (d1 << 4) | (d0 << 0))
+
+#define EXYNOS4210_DIV1_HPM_MASK ((0x7 << 0) | (0x7 << 4))
+#define EXYNOS4210_MUX_HPM_MASK(1 << 20)
+
+/**
+ * struct exynos4210_armclk_data: config data to setup exynos4210 cpu clocks.
+ * @prate: frequency of the parent clock.
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for divider clocks
+ * belonging to the CMU_CPU clock domain. The parent frequency at which these
+ * divider values are vaild is specified in @prate.
+ */
+struct exynos4210_armclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct exynos_cpuclk: information about clock supplied to a CPU core.
+ * @hw:handle between ccf and cpu clock.
+ * @alt_parent:alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset:offset from the ctrl_base address where the cpu clock div/mux
+ * registers can be accessed.
+ * @clk_nb:clock notifier registered for changes in clock speed of the
+ * primary parent clock.
+ * @lock: register access lock.
+ * @data: optional data which the acutal instantiation of this clock
+ * can use.
+ */
+struct exynos_cpuclk {
+ struct clk_hw hw;
+ struct clk *alt_parent;
+ void __iomem*ctrl_base;
+ unsigned long offset;
+ struct notifier_block clk_nb;
+ spinlock_t *lock;
+ void*data;
+};
+
+#define to_exynos_cpuclk_hw(hw) container_of(hw, struct exynos_cpuclk, hw)
+#define to_exynos_cpuclk_nb(nb) container_of(nb, struct exynos_cpuclk, clk_nb)
+
+/**
+ * struct exynos_cpuclk_soc_data: soc specific data for cpu clocks.
+ * @parser:pointer to a function that can parse SoC specific data.
+ * @ops: clock operations to be used for this clock.
+ * @offset:optional offset from base of clock controller register base, to
+ * be used when accessing clock controller registers related to the
+ * cpu clock.
+ * @clk_cb:the clock notifier callback to be called for changes in the
+ *
[PATCH v4 2/8] clk: samsung: change scope of samsung clock lock to global
From: Thomas Abraham
Access to samsung clock lock is required to support newer samsung specific
clock types. So change the scope of the samsung clock lock to global. And
prefix 'samsung_clk_' to the existing name of the lock to prevent name space
pollution.
Cc: Tomasz Figa
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk.c | 13 -
drivers/clk/samsung/clk.h |2 ++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 91bec3e..c86c28c 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -14,7 +14,7 @@
#include
#include "clk.h"
-static DEFINE_SPINLOCK(lock);
+DEFINE_SPINLOCK(samsung_clk_lock);
static struct clk **clk_table;
static void __iomem *reg_base;
#ifdef CONFIG_OF
@@ -173,7 +173,8 @@ void __init samsung_clk_register_mux(struct
samsung_mux_clock *list,
for (idx = 0; idx < nr_clk; idx++, list++) {
clk = clk_register_mux(NULL, list->name, list->parent_names,
list->num_parents, list->flags, reg_base + list->offset,
- list->shift, list->width, list->mux_flags, &lock);
+ list->shift, list->width, list->mux_flags,
+ &samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err("%s: failed to register clock %s\n", __func__,
list->name);
@@ -206,12 +207,13 @@ void __init samsung_clk_register_div(struct
samsung_div_clock *list,
list->parent_name, list->flags,
reg_base + list->offset, list->shift,
list->width, list->div_flags,
- list->table, &lock);
+ list->table, &samsung_clk_lock);
else
clk = clk_register_divider(NULL, list->name,
list->parent_name, list->flags,
reg_base + list->offset, list->shift,
- list->width, list->div_flags, &lock);
+ list->width, list->div_flags,
+ &samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err("%s: failed to register clock %s\n", __func__,
list->name);
@@ -241,7 +243,8 @@ void __init samsung_clk_register_gate(struct
samsung_gate_clock *list,
for (idx = 0; idx < nr_clk; idx++, list++) {
clk = clk_register_gate(NULL, list->name, list->parent_name,
list->flags, reg_base + list->offset,
- list->bit_idx, list->gate_flags, &lock);
+ list->bit_idx, list->gate_flags,
+ &samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err("%s: failed to register clock %s\n", __func__,
list->name);
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index c7141ba..951bc85 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -21,6 +21,8 @@
#include
#include "clk-pll.h"
+extern spinlock_t samsung_clk_lock;
+
/**
* struct samsung_clock_alias: information about mux clock
* @id: platform specific id of the clock.
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Thomas Abraham
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while preparing the cpufreq table
from the list of operating points available.
Cc: Shawn Guo
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig| 11 +++
drivers/cpufreq/cpufreq-cpu0.c |5 +
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..60f321a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..0ca4485 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -194,6 +194,17 @@ config GENERIC_CPUFREQ_CPU0
If in doubt, say N.
+config GENERIC_CPUFREQ_CPU0_BOOST
+ bool "Boost frequency support for generic CPU0 cpufreq driver"
+ depends on GENERIC_CPUFREQ_CPU0
+ select CPU_FREQ_BOOST_SW
+ help
+ This enables support for software managed overclocking (BOOST). It
+ allows usage of special frequencies (those beyond the normal operating
+ frequencies).
+
+ If in doubt, say N.
+
menu "x86 CPU frequency scaling drivers"
depends on X86
source "drivers/cpufreq/Kconfig.x86"
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..e6c21a8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -194,6 +194,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
transition_latency += ret * 1000;
}
+#ifdef CONFIG_GENERIC_CPUFREQ_CPU0_BOOST
+ if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
+ cpu0_cpufreq_driver.boost_supported = true;
+#endif
+
ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
if (ret) {
pr_err("failed register driver: %d\n", ret);
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/8] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
Changes since v3: - Addressed comments from Tomasz Figa [http://www.spinics.net/lists/cpufreq/msg09290.html] - Rebased to v3.15-rc4 Changes since v2: - Safe operating voltage is not required while switching APLL frequency since the temporary parent's clock is divided down to keep armclk within permissible limits. Thanks to Heiko Stübner for this suggesting this. - Rob had suggested to use max frequency for each of the divider clock outputs instead of divider values. But due to certain SoC specific characteristics, the divider values corresponding to the input clock frequency for the CMU_CPU clock blocks have to be used. Changes since v1: - Removes Exynos4x12 and Exynos5250 cpufreq driver also. - Device tree based clock configuration lookup as suggested by Lukasz Majewski and Tomasz Figa. - safe operating point binding reworked as suggested by Shawn Guo. The patch series removes the use of Exynos specific cpufreq driver and enables the use of cpufreq-cpu0 driver for Exynos4210, Exynos4x12 and Exynos5250 based platforms. This is being done for few reasons. (a) The Exynos cpufreq driver reads/writes clock controller registers bypassing the Exynos 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). Thomas Abraham (8): cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies clk: samsung: change scope of samsung clock lock to global clk: samsung: add infrastructure to register cpu clocks Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5 clk: exynos: use cpu-clock provider type to represent arm clock ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data ARM: Exynos: switch to using generic cpufreq-cpu0 driver cpufreq: exynos: remove all exynos specific cpufreq driver support .../devicetree/bindings/clock/exynos4-clock.txt| 37 ++ .../devicetree/bindings/clock/exynos5250-clock.txt | 36 ++ .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 + 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 | 35 ++ arch/arm/boot/dts/exynos4212.dtsi | 18 + arch/arm/boot/dts/exynos4412-odroidx.dts |6 + arch/arm/boot/dts/exynos4412-origen.dts|6 + arch/arm/boot/dts/exynos4412-trats2.dts|6 + arch/arm/boot/dts/exynos4412.dtsi | 31 ++ arch/arm/boot/dts/exynos4x12.dtsi | 36 ++ arch/arm/boot/dts/exynos5250-arndale.dts |6 + arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 + arch/arm/boot/dts/exynos5250-smdk5250.dts |6 + arch/arm/boot/dts/exynos5250.dtsi | 41 ++ arch/arm/mach-exynos/exynos.c |4 +- drivers/clk/samsung/Makefile |2 +- drivers/clk/samsung/clk-cpu.c | 458 drivers/clk/samsung/clk-exynos4.c | 25 +- drivers/clk/samsung/clk-exynos5250.c | 12 +- drivers/clk/samsung/clk.c | 13 +- drivers/clk/samsung/clk.h |7 + drivers/cpufreq/Kconfig| 11 + drivers/cpufreq/Kconfig.arm| 52 --- drivers/cpufreq/Makefile |4 - drivers/cpufreq/cpufreq-cpu0.c |5 + drivers/cpufreq/exynos-cpufreq.c | 209 - drivers/cpufreq/exynos-cpufreq.h | 91 drivers/cpufreq/exynos4210-cpufreq.c | 157 --- drivers/cpufreq/exynos4x12-cpufreq.c | 211 - drivers/cpufreq/exynos5250-cpufreq.c | 183 include/dt-bindings/clock/exynos5250.h |1 + 34 files changed, 799 insertions(+), 936 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
drivers/cpufreq/cpufreq_opp.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..e3c97f3 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ int j, len;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +87,40 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = &freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev->of_node, "boost-frequency", &len)) {
+ if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, "%s: invalid boost frequency\n", __func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, "%s: no memory for boost freq table\n",
+ __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+ of_property_read_u32_array(dev->of_node, "boost-frequency",
+ boost_freqs, len / sizeof(u32));
+ }
+
+ for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+ if (boost_freqs[j] == freq_table[i].frequency) {
+ freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ }
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END)
+ pr_err("%s: invalid boost frequency %d\n",
+ __func__, boost_freqs[j]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
Changes since v2:
- Reworked based on the "PM / OPP: move cpufreq specific helpers out of OPP
layer"
patch series posted by Nishanth Menon .
Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
feedback.
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.
Thomas Abraham (2):
cpufreq / OPP: Allow boost frequency to be looked up from device tree
Documentation: devicetree: Add boost-frequency binding to list boost mode
frequency
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 ++
drivers/cpufreq/cpufreq_opp.c | 39
2 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon Cc: Lukasz Majewski Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Thomas Abraham --- .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal +operating conditions. + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. + This list should be a subset of frequencies listed in "operating-points" + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about "operating-points" property. -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] PM / OPP: move cpufreq specific helpers out of OPP layer
On Mon, May 5, 2014 at 7:03 PM, Nishanth Menon wrote: > CPUFreq usage of OPP should be independent of the ordering of type of > data storage inside OPP layer. The current operations can equally be > performed by generic operations. > > [RFC]: https://patchwork.kernel.org/patch/4100811/ > > Series based on: v3.15-rc1 > > Nishanth Menon (2): > PM / OPP: Remove cpufreq wrapper dependency on internal data > organization > PM / OPP: Move cpufreq specific OPP functions out of generic OPP > library > > Documentation/cpu-freq/core.txt | 29 +++ > Documentation/power/opp.txt | 40 ++ > drivers/base/power/opp.c| 91 > drivers/cpufreq/Makefile|2 + > drivers/cpufreq/cpufreq_opp.c | 110 > +++ > include/linux/cpufreq.h | 21 > include/linux/pm_opp.h | 20 --- > 7 files changed, 167 insertions(+), 146 deletions(-) > create mode 100644 drivers/cpufreq/cpufreq_opp.c Works fine on Exynos. Tested-by: Thomas Abraham > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa wrote: > On 16.04.2014 16:31, Arnd Bergmann wrote: >> >> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: >>> >>> On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. >>> >>> >>> Is this still true as of today? >>> >>> Otherwise looks fine. >> >> >> sparsemem is still not supported in multiplatform, but after I looked >> at it in more detail, I came to the conclusion that there is no >> reason why it couldn't be. It just needs testing so we are confident >> that it doesn't break other platforms, and we need to find good >> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS >> to put into asm/memory.h, since we can't have them set in mach/memory.h >> for multiplatform. >> >> Looking at my patch again now, I would actually prefer to kill off >> the single-platform support for exynos right away. I don't see >> any reason to keep it now, and it complicates the test matrix. > > > That would be the best option, assuming that it wouldn't introduce feature > regressions. Unfortunately there is still ongoing work on cpufreq driver to > make it multiplatform-aware, so dropping single platform support right now > would introduce at least this one regression. > > Thomas, is there any progress on new version of Exynos cpufreq rework > series? Hi Tomasz, Yes, I am preparing the fourth version of the cpufreq patches and will post it next week. Mostly, the changes will be addressing your review comments. Thanks, Thomas. > > Best regards, > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On Wed, Feb 12, 2014 at 8:28 PM, Tomasz Figa wrote:
> Hi Thomas,
>
>
> On 07.02.2014 16:55, Thomas Abraham wrote:
>>
>> From: Thomas Abraham
>>
>> Lookup for the optional boost-frequency property in cpu0 node and if
>> available, enable support for boost mode frequencies. The frequencies
>> usable in boost mode are determined while preparing the cpufreq table
>> from the list of operating points available.
>>
>> In addition to this, enable the CPU_FREQ_BOOST_SW config option for
>> this driver by default. On platforms that do not support boost mode,
>> the boost mode frequencies will not be specified in cpu0 node and
>> hence the boost mode support will not be enabled. Since this driver
>> anyways depends on THERMAL config option, it is safe to enable
>> CPU_FREQ_BOOST_SW config option as default.
>>
>> Cc: Shawn Guo
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
>> drivers/cpufreq/Kconfig|1 +
>> drivers/cpufreq/cpufreq-cpu0.c |3 +++
>> 3 files changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> index f055515..60f321a 100644
>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> @@ -19,6 +19,8 @@ Optional properties:
>> - cooling-min-level:
>> - cooling-max-level:
>>Please refer to
>> Documentation/devicetree/bindings/thermal/thermal.txt.
>> +- boost-frequency:
>> + Please refer to
>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> Examples:
>>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index 4b029c0..52cc704 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b/drivers/cpufreq/Kconfig
>> @@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
>> tristate "Generic CPU0 cpufreq driver"
>> depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
>> select PM_OPP
>> + select CPU_FREQ_BOOST_SW
>> help
>> This adds a generic cpufreq driver for CPU0 frequency
>> management.
>> It supports both uniprocessor (UP) and symmetric multiprocessor
>> (SMP)
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c
>> b/drivers/cpufreq/cpufreq-cpu0.c
>> index 0c12ffc..06539eb 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -195,6 +195,9 @@ static int cpu0_cpufreq_probe(struct platform_device
>> *pdev)
>> transition_latency += ret * 1000;
>> }
>>
>> + if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
>> + cpu0_cpufreq_driver.boost_supported = true;
>> +
>> ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
>> if (ret) {
>> pr_err("failed register driver: %d\n", ret);
>>
>
> I'd say that boost should be enabled depending on user's preference, as done
> before in Exynos cpufreq driver. So both presence of boost-frequency
> property and state of CPU_FREQ_BOOST_SW should be considered.
>
> As for CPU_FREQ_BOOST_SW, I don't think it should be always selected, but
> ather, either converted to a user-selectable bool entry or made selectable
> by other entry, like current ARM_EXYNOS_CPU_FREQ_BOOST_SW.
We still will have the same problem on Exynos multi-platform kernel
where one Exynos platform needs it and others don't. Same with just
using the CPU_FREQ_BOOST_SW config option. So that was the reason to
just fallback on presence of boost property.
Thanks,
Thomas.
>
> Best regards,
> Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] clk: samsung: add infrastructure to register cpu clocks
Hi Tomasz,
Thanks for your detailed review.
On Wed, Feb 12, 2014 at 11:55 PM, Tomasz Figa wrote:
> Hi Thomas,
>
>
> On 07.02.2014 16:55, Thomas Abraham wrote:
>>
>> From: Thomas Abraham
>>
>> The CPU clock provider supplies the clock to the CPU clock domain. The
>> composition and organization of the CPU clock provider could vary among
>> Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
>> and gates. This patch defines a new clock type for CPU clock provider and
>> adds infrastructure to register the CPU clock providers for Samsung
>> platforms.
>>
>> In addition to this, the arm cpu clock provider for Exynos4210 and
>> compatible SoCs is instantiated using the new cpu clock type. The clock
>> configuration data for this clock is obtained from device tree. This
>> implementation is reusable for Exynos4x12 and Exynos5250 SoCs as well.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/clk/samsung/Makefile |2 +-
>> drivers/clk/samsung/clk-cpu.c | 409
>> +
>> drivers/clk/samsung/clk.h |5 +
>> 3 files changed, 415 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/clk/samsung/clk-cpu.c
>
>
> [snip]
>
>
>> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
>> new file mode 100644
>> index 000..673f620
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-cpu.c
>> @@ -0,0 +1,409 @@
>
>
> [snip]
>
>
>> +#define SRC_CPU0x0
>> +#define STAT_CPU 0x200
>> +#define DIV_CPU0 0x300
>> +#define DIV_CPU1 0x304
>> +#define DIV_STAT_CPU0 0x400
>> +#define DIV_STAT_CPU1 0x404
>> +
>> +#define MAX_DIV8
>> +
>> +#define EXYNOS4210_ARM_DIV1(base) ((readl(base + DIV_CPU0) & 0xf) + 1)
>> +#define EXYNOS4210_ARM_DIV2(base) (((readl(base + DIV_CPU0) >> 28) & 0xf)
>> + 1)
>
>
> Those are 3-bit dividers, so the mask should be rather 0x7, shouldn't it?
Yes, that is correct. I will fix this.
>
> Btw. Somehow I feel like this kind of macros is simply obfuscating code
> without any real benefits. Could you rewrite them to simply take the value
> of DIV_CPU0 register, without hiding readl behind the scenes?
Okay. I will change this.
>
>
>> +
>> +#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0)\
>> + ((d5 << 24) | (d4 << 20) | (d3 << 16) | (d2 << 12) |\
>> +(d1 << 8) | (d0 << 4))
>> +#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
>> \
>> + ((d2 << 8) | (d1 << 4) | (d0 << 0))
>> +
>> +#define EXYNOS4210_DIV1_HPM_MASK ((0x7 << 0) | (0x7 << 4))
>> +#define EXYNOS4210_MUX_HPM_MASK(1 << 20)
>
>
> [snip]
>
>
>> +/* common round rate callback useable for all types of cpu clocks */
>> +static long samsung_cpuclk_round_rate(struct clk_hw *hw,
>> + unsigned long drate, unsigned long *prate)
>> +{
>> + struct clk *parent = __clk_get_parent(hw->clk);
>> + unsigned long max_prate = __clk_round_rate(parent, UINT_MAX);
>> + unsigned long t_prate, best_div = 1;
>> + unsigned long delta, min_delta = UINT_MAX;
>> +
>> + do {
>> + t_prate = __clk_round_rate(parent, drate * best_div);
>> + delta = drate - (t_prate / best_div);
>> + if (delta < min_delta) {
>> + *prate = t_prate;
>> + min_delta = delta;
>> + }
>> + if (!delta)
>> + break;
>> + best_div++;
>> + } while ((drate * best_div) < max_prate && best_div <= MAX_DIV);
>> +
>> + return t_prate / best_div;
>> +}
>
>
> I think there is something wrong with the code above. You increment best_div
> in every iteration of the loop and use it to calculate the final best
> frequency. Shouldn't best_div be the divisor which was found to give the
> least delta and so the loop should rather iterate on a different variable
> and store best_div only if (delta < min_delta) condition is true?
This function finds out the best parent frequency (APLL in this case)
which when divided with some divider value provides the the closest
possible drate. Probably, the name best_div is misleading since there
is no need to know the value of be
Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon wrote: > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla wrote: >> On 07/02/14 17:37, Nishanth Menon wrote: >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla wrote: >> >> [...] >> Yes I think its counter-intuitive as it's visible to the userspace(list of frequencies and the boost parameters are exposed through sysfs) >>> >>> That will be a different problem -> as currently every single >>> frequency in the cpufreq list has ability to be marked as boost >>> frequency - if userspace does not maintain that, then, IMHO, fix the >>> userspace :D >>> >> >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives >> the list of frequencies based on the state of the boost feature at anytime. >> >> Intuitively the list without boost shouldn't have any frequency above the >> range >> when it's enabled :), that's what I was referring to. So I am not talking >> about >> any issue with user-space maintenance. > Fair enough - but i still think it has nothing to do with dt binding > itself -> and i think the discussion we've had should be good for the > binding provided in this patch.. I hope.. if documentation needs a bit > of better explanation to prevent a repeat of the same discussion at a > later point of time, now might be a good time to add it in. The term boost and over-clocking have been described in the bindings document as being the same. Since the term over-clocking refers to running a CPU beyond normal operating frequencies, I tend to agree with Sudeep that it is not intuitive if a normal operating frequency is greater than a boost mode frequency. Otherwise, when userspace does "echo 1 > /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I think the original intent of boost mode patches was to allow CPU to operate at frequencies greater than the normal operating frequencies. Lukasz, how would you want this to be handled? Thanks, Thomas. > > Regards, > Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla wrote: > On 07/02/14 17:37, Nishanth Menon wrote: >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla wrote: > > [...] > >>> Yes I think its counter-intuitive as it's visible to the userspace(list of >>> frequencies and the boost parameters are exposed through sysfs) >> >> That will be a different problem -> as currently every single >> frequency in the cpufreq list has ability to be marked as boost >> frequency - if userspace does not maintain that, then, IMHO, fix the >> userspace :D >> > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives > the list of frequencies based on the state of the boost feature at anytime. The list of frequencies in /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies does not change based in the state of the boost feature (enabled or disabled). But the scaling_max_frequency and scaling_min_frequency are updated based on the set of available + boost frequencies available. > > Intuitively the list without boost shouldn't have any frequency above the > range > when it's enabled :), that's what I was referring to. So I am not talking > about > any issue with user-space maintenance. > > Regards, > Sudeep > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
On Fri, Feb 7, 2014 at 9:50 PM, Sudeep Holla wrote:
> On 07/02/14 15:55, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> For all Exynos based platforms, add CPU nodes, operating points and cpu
>> clock data for migrating from Exynos specific cpufreq driver to using
>> generic cpufreq-cpu0 driver.
>>
>> Signed-off-by: Thomas Abraham
>
> [...]
>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 5c412aa..c613fc2 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -31,6 +31,42 @@
>> mshc0 = &mshc_0;
>> };
>>
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <0>;
>> + clocks = <&clock 12>;
>> + clock-names = "cpu";
>> +
>> + operating-points = <
>> + 150 135
>> + 140 1287500
>> + 130 125
>> + 120 1187500
>> + 110 1137500
>> + 100 1087500
>> +90 1037500
>> +80 100
>> +70 987500
>> +60 975000
>> +50 95
>> +40 925000
>> +30 90
>> +20 90
>> + >;
>> + clock-latency = <20>;
>> + boost-frequency = <150 135>;
>
> This is confusing, 135 is not in the OPP frequency list or this is still
> following old binding with voltage. Either case this needs to be fixed.
Yes, I missed that. Will fix it. Thanks for your review.
Regards,
Thomas.
>
> Regards,
> Sudeep
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On Fri, Feb 7, 2014 at 9:46 PM, Nishanth Menon wrote:
> On 02/07/2014 09:55 AM, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Lookup for the optional boost-frequency property in cpu0 node and if
>> available, enable support for boost mode frequencies. The frequencies
>> usable in boost mode are determined while preparing the cpufreq table
>> from the list of operating points available.
>>
>> In addition to this, enable the CPU_FREQ_BOOST_SW config option for
>> this driver by default. On platforms that do not support boost mode,
>> the boost mode frequencies will not be specified in cpu0 node and
>> hence the boost mode support will not be enabled. Since this driver
>> anyways depends on THERMAL config option, it is safe to enable
>> CPU_FREQ_BOOST_SW config option as default.
>>
>> Cc: Shawn Guo
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
>> drivers/cpufreq/Kconfig|1 +
>> drivers/cpufreq/cpufreq-cpu0.c |3 +++
>> 3 files changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> index f055515..60f321a 100644
>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> @@ -19,6 +19,8 @@ Optional properties:
>> - cooling-min-level:
>> - cooling-max-level:
>> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
>> +- boost-frequency:
>> + Please refer to
>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> Examples:
>>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index 4b029c0..52cc704 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b/drivers/cpufreq/Kconfig
>> @@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
>> tristate "Generic CPU0 cpufreq driver"
>> depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
>> select PM_OPP
>> + select CPU_FREQ_BOOST_SW
>> help
>> This adds a generic cpufreq driver for CPU0 frequency management.
>> It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index 0c12ffc..06539eb 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -195,6 +195,9 @@ static int cpu0_cpufreq_probe(struct platform_device
>> *pdev)
>> transition_latency += ret * 1000;
>> }
>>
>> + if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
>> + cpu0_cpufreq_driver.boost_supported = true;
>> +
>> ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
>> if (ret) {
>> pr_err("failed register driver: %d\n", ret);
>>
>
> might as well hide that under the opp api which returns a bool that
> says if boost is supported or not. that allows the parse to be
> isolated to a single location.
This is specific to the cpufreq-cpu0 driver. Other cpufreq drivers
might want to use other methods and additional constraints to
determine if boost has to be enabled.
Thanks,
Thomas.
>
> --
> Regards,
> Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/base/power/opp.c | 34 +-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> struct device_opp *dev_opp;
>> struct dev_pm_opp *opp;
>> struct cpufreq_frequency_table *freq_table;
>> - int i = 0;
>> + int i = 0, j, len, ret;
>> + u32 *boost_freqs = NULL;
>>
>> /* Pretend as if I am an updater */
>> mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> return -ENOMEM;
>> }
>>
>> + if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> + dev_err(dev, "%s: invalid boost frequency\n",
>> __func__);
>> + ret = -EINVAL;
>> + goto err_boost;
>> + }
>> +
>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>> + if (!boost_freqs) {
>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>> + __func__);
>> + ret = -ENOMEM;
>> + goto err_boost;
>> + }
>> + of_property_read_u32_array(dev->of_node, "boost-frequency",
>> + boost_freqs, len / sizeof(u32));
>> + }
>> +
>> list_for_each_entry(opp, &dev_opp->opp_list, node) {
>> if (opp->available) {
>> freq_table[i].driver_data = i;
>> freq_table[i].frequency = opp->rate / 1000;
>> + for (j = 0; j < len / sizeof(u32) && boost_freqs; j++)
>> {
>> + if (boost_freqs[j] == freq_table[i].frequency)
>> {
>> + freq_table[i].driver_data =
>> + CPUFREQ_BOOST_FREQ;
>> + break;
>> + }
>> + }
>> i++;
>> }
>> }
> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
> this change seems to be cpufreq only.
Yes, but as you have initiated the discussion on extending the OPP
binding, this has been limited to cpufreq only. If the new OPP library
has support for listing boost frequency, this can be migrated to the
new OPP libaray.
Thanks,
Thomas.
>
> Regards,
> Sudeep
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
Changes since v2: - Safe operating voltage is not required while switching APLL frequency since the temporary parent's clock is divided down to keep armclk within permissible limits. Thanks to Heiko Stübner for this suggesting this. - Rob had suggested to use max frequency for each of the divider clock outputs instead of divider values. But due to certain SoC specific characteristics, the divider values corresponding to the input clock frequency for the CMU_CPU clock blocks have to be used. Changes since v1: - Removes Exynos4x12 and Exynos5250 cpufreq driver also. - Device tree based clock configuration lookup as suggested by Lukasz Majewski and Tomasz Figa. - safe operating point binding reworked as suggested by Shawn Guo. The patch series removes the use of Exynos specific cpufreq driver and enables the use of cpufreq-cpu0 driver for Exynos4210, Exynos4x12 and Exynos5250 based platforms. This is being done for few reasons. (a) The Exynos cpufreq driver reads/writes clock controller registers bypassing the Exynos 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). Thomas Abraham (7): cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies clk: samsung: add infrastructure to register cpu clocks Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5 clk: exynos: use cpu-clock provider type to represent arm clock ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data ARM: Exynos: switch to using generic cpufreq-cpu0 driver cpufreq: exynos: remove all exynos specific cpufreq driver support .../devicetree/bindings/clock/exynos4-clock.txt| 37 ++ .../devicetree/bindings/clock/exynos5250-clock.txt | 39 ++ .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 + 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 | 35 ++ arch/arm/boot/dts/exynos4212.dtsi | 18 + arch/arm/boot/dts/exynos4412-odroidx.dts |6 + arch/arm/boot/dts/exynos4412-origen.dts|6 + arch/arm/boot/dts/exynos4412-trats2.dts|6 + arch/arm/boot/dts/exynos4412.dtsi | 31 ++ arch/arm/boot/dts/exynos4x12.dtsi | 36 ++ arch/arm/boot/dts/exynos5250-arndale.dts |6 + arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 + arch/arm/boot/dts/exynos5250-smdk5250.dts |6 + arch/arm/boot/dts/exynos5250.dtsi | 41 ++ arch/arm/mach-exynos/common.c |5 - arch/arm/mach-exynos/common.h |1 - arch/arm/mach-exynos/mach-exynos4-dt.c |2 +- arch/arm/mach-exynos/mach-exynos5-dt.c |2 +- drivers/clk/samsung/Makefile |2 +- drivers/clk/samsung/clk-cpu.c | 409 drivers/clk/samsung/clk-exynos4.c | 23 +- drivers/clk/samsung/clk-exynos5250.c | 10 +- drivers/clk/samsung/clk.h |5 + drivers/cpufreq/Kconfig|1 + drivers/cpufreq/Kconfig.arm| 51 --- drivers/cpufreq/Makefile |4 - drivers/cpufreq/cpufreq-cpu0.c |3 + drivers/cpufreq/exynos-cpufreq.c | 292 -- drivers/cpufreq/exynos-cpufreq.h | 91 - drivers/cpufreq/exynos4210-cpufreq.c | 157 drivers/cpufreq/exynos4x12-cpufreq.c | 211 -- drivers/cpufreq/exynos5250-cpufreq.c | 183 - include/dt-bindings/clock/exynos5250.h |1 + 36 files changed, 727 insertions(+), 1019 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Thomas Abraham
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while preparing the cpufreq table
from the list of operating points available.
In addition to this, enable the CPU_FREQ_BOOST_SW config option for
this driver by default. On platforms that do not support boost mode,
the boost mode frequencies will not be specified in cpu0 node and
hence the boost mode support will not be enabled. Since this driver
anyways depends on THERMAL config option, it is safe to enable
CPU_FREQ_BOOST_SW config option as default.
Cc: Shawn Guo
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig|1 +
drivers/cpufreq/cpufreq-cpu0.c |3 +++
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..60f321a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..52cc704 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
tristate "Generic CPU0 cpufreq driver"
depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
select PM_OPP
+ select CPU_FREQ_BOOST_SW
help
This adds a generic cpufreq driver for CPU0 frequency management.
It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 0c12ffc..06539eb 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -195,6 +195,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
transition_latency += ret * 1000;
}
+ if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
+ cpu0_cpufreq_driver.boost_supported = true;
+
ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
if (ret) {
pr_err("failed register driver: %d\n", ret);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5
From: Thomas Abraham The clock blocks within the CMU_CPU clock domain are put together into a new composite clock type called the cpu clock. This clock type requires configuration data that will be atomically programmed in the multiple clock blocks encapsulated within the cpu clock type when the parent clock frequency is changed. This configuration data is held in the clock controller node. Update clock binding documentation about this configuration data format for Samsung Exynos4 and Exynos5 platforms. Cc: Tomasz Figa Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Signed-off-by: Thomas Abraham --- .../devicetree/bindings/clock/exynos4-clock.txt| 37 +++ .../devicetree/bindings/clock/exynos5250-clock.txt | 38 2 files changed, 75 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index a2ac2d9..b505e17 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,6 +15,35 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + - for Exynos4210 and Exynos4212 based platforms: + cell #1: arm clock parent frequency + cell #2 ~ cell 9#: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio. + + - for Exynos4412 based platforms: + cell #1: expected arm clock parent frequency + cell #2 ~ cell #10: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio, cores_ratio + +- samsung,armclk-cells: defines the number of cells in + samsung,armclk-divider-table property. The value of this property depends on + the SoC type. + + - for Exynos4210 and Exynos4212: the value should be 9. + - for Exynos4412: the value should be 10. + The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. Some of the clocks are available only on a particular @@ -275,6 +304,14 @@ Example 1: An example of a clock controller node is listed below. compatible = "samsung,exynos4210-clock"; reg = <0x1003 0x2>; #clock-cells = <1>; + + samsung,armclk-cells = <9>; + samsung,armclk-divider-table = <120 3 7 3 4 1 7 5 0>, + <100 3 7 3 4 1 7 4 0>, + < 80 3 7 3 3 1 7 3 0>, + < 50 3 7 3 3 1 7 3 0>, + < 40 3 7 3 3 1 7 3 0>, + < 20 1 3 1 1 1 0 3 0>; }; Example 2: UART controller node that consumes the clock generated by the clock diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 72ce617..9ca818e 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,6 +13,25 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + cell #1: expected arm clock parent frequency + cell #2 ~ cell #9: value of clock divider in the following order + cpud_ratio, ac
[PATCH v3 4/7] clk: exynos: use cpu-clock provider type to represent arm clock
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos4.c | 23 +++
drivers/clk/samsung/clk-exynos5250.c | 10 +-
include/dt-bindings/clock/exynos5250.h |1 +
3 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 010f071..a52c622 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -336,7 +336,6 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
@@ -395,7 +394,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(0, "mout_jpeg", mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4x12, SRC_CAM, 4, 4),
MUX(CLK_MOUT_FIMC2, "mout_fimc2", group1_p4x12, SRC_CAM, 8, 4),
@@ -437,8 +435,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
- DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
@@ -484,8 +480,8 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
- DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
+ DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, 0),
DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
@@ -868,12 +864,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
0),
};
-static struct samsung_clock_alias exynos4_aliases[] __initdata = {
- ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
- ALIAS(CLK_ARM_CLK, NULL, "armclk"),
- ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
-};
-
static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
ALIAS(CLK_SCLK_MPLL, NULL, "mout_mpll"),
};
@@ -,6 +1101,8 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_gate_clks));
samsung_clk_register_alias(exynos4210_aliases,
ARRAY_SIZE(exynos4210_aliases));
+ samsung_register_arm_clock(CLK_ARM_CLK, mout_core_p4210,
+ ARRAY_SIZE(mout_core_p4210), reg_base, np, NULL);
} else {
samsung_clk_register_mux(exynos4x12_mux_clks,
ARRAY_SIZE(exynos4x12_mux_clks));
@@ -1120,17 +1112,16 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4x12_gate_clks));
samsung_clk_register_alias(exynos4x12_aliases,
ARRAY_SIZE(exynos4x12_aliases));
+ samsung_register_arm_clock(CLK_ARM_CLK, mout_core_p4x12,
+ ARRAY_SIZE(mout_core_p4x12), reg_base, np, NULL);
}
- samsung_clk_register_alias(exynos4_aliases,
-
[PATCH v3 2/7] clk: samsung: add infrastructure to register cpu clocks
From: Thomas Abraham
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
In addition to this, the arm cpu clock provider for Exynos4210 and
compatible SoCs is instantiated using the new cpu clock type. The clock
configuration data for this clock is obtained from device tree. This
implementation is reusable for Exynos4x12 and Exynos5250 SoCs as well.
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 409 +
drivers/clk/samsung/clk.h |5 +
3 files changed, 415 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..e2b453f 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..673f620
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,409 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the cpu clocks
+ * for samsung platforms.
+*/
+
+#include
+#include "clk.h"
+
+#define SRC_CPU0x0
+#define STAT_CPU 0x200
+#define DIV_CPU0 0x300
+#define DIV_CPU1 0x304
+#define DIV_STAT_CPU0 0x400
+#define DIV_STAT_CPU1 0x404
+
+#define MAX_DIV8
+
+#define EXYNOS4210_ARM_DIV1(base) ((readl(base + DIV_CPU0) & 0xf) + 1)
+#define EXYNOS4210_ARM_DIV2(base) (((readl(base + DIV_CPU0) >> 28) & 0xf) + 1)
+
+#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0)\
+ ((d5 << 24) | (d4 << 20) | (d3 << 16) | (d2 << 12) |\
+(d1 << 8) | (d0 << 4))
+#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
\
+ ((d2 << 8) | (d1 << 4) | (d0 << 0))
+
+#define EXYNOS4210_DIV1_HPM_MASK ((0x7 << 0) | (0x7 << 4))
+#define EXYNOS4210_MUX_HPM_MASK(1 << 20)
+
+/**
+ * struct exynos4210_armclk_data: config data to setup exynos4210 cpu clocks.
+ * @prate: frequency of the parent clock.
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for divider clocks
+ * belonging to the CMU_CPU clock domain. The parent frequency at which these
+ * divider values are vaild is specified in @prate.
+ */
+struct exynos4210_armclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct samsung_cpuclk: information about clock supplied to a CPU core.
+ * @hw:handle between ccf and cpu clock.
+ * @alt_parent:alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset:offset from the ctrl_base address where the cpu clock div/mux
+ * registers can be accessed.
+ * @clk_nb:clock notifier registered for changes in clock speed of the
+ * primary parent clock.
+ * @data: optional data which the acutal instantiation of this clock
+ * can use.
+ */
+struct samsung_cpuclk {
+ struct clk_hw hw;
+ struct clk *alt_parent;
+ void __iomem*ctrl_base;
+ unsigned long offset;
+ struct notifier_block clk_nb;
+ void*data;
+};
+
+#define to_samsung_cpuclk_hw(hw) container_of(hw, struct samsung_cpuclk, hw)
+#define to_samsung_cpuclk_nb(nb) container_of(nb, struct samsung_cpuclk,
clk_nb)
+
+/**
+ * struct samsung_cpuclk_soc_data: soc specific data for cpu clocks.
+ * @parser:pointer to a function that can parse SoC specific data.
+ * @ops: clock operations to be used for this clock.
+ * @offset:optional off
[PATCH v3 5/7] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
From: Thomas Abraham
For all Exynos based platforms, add CPU nodes, operating points and cpu
clock data for migrating from Exynos specific cpufreq driver to using
generic cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/clock/exynos5250-clock.txt |1 +
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 | 35 +
arch/arm/boot/dts/exynos4212.dtsi | 18 +
arch/arm/boot/dts/exynos4412-odroidx.dts |6 +++
arch/arm/boot/dts/exynos4412-origen.dts|6 +++
arch/arm/boot/dts/exynos4412-trats2.dts|6 +++
arch/arm/boot/dts/exynos4412.dtsi | 31 +++
arch/arm/boot/dts/exynos4x12.dtsi | 36 +
arch/arm/boot/dts/exynos5250-arndale.dts |6 +++
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +++
arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +++
arch/arm/boot/dts/exynos5250.dtsi | 41
15 files changed, 216 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 9ca818e..4513cbb 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -43,6 +43,7 @@ clock which they consume.
fin_pll 1
+ armclk 12
[Clock Gate for Special Clocks]
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 2aa13cb..dd17e93 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&buck1_reg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63cc571..25487d76 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&varm_breg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d2e3f5f..74d5a70 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&vdd_arm_reg>;
+ };
+ };
+
mct@1005 {
compatible = "none";
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 48ecd7a..a774247 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -36,6 +36,33 @@
reg = <0x10023CA0 0x20>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clocks = <&clock 12>;
+ clock-names = "cpu";
+
+ operating-points = <
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
+ >;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x8000>;
};
@@ -73,6 +100,14 @@
compati
[PATCH v3 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham
Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over
to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos
specific cpufreq drivers for these platforms can be removed.
Signed-off-by: Thomas Abraham
---
drivers/cpufreq/Kconfig.arm | 51 --
drivers/cpufreq/Makefile |4 -
drivers/cpufreq/exynos-cpufreq.c | 292 --
drivers/cpufreq/exynos-cpufreq.h | 91 ---
drivers/cpufreq/exynos4210-cpufreq.c | 157 --
drivers/cpufreq/exynos4x12-cpufreq.c | 211
drivers/cpufreq/exynos5250-cpufreq.c | 183 -
7 files changed, 989 deletions(-)
delete mode 100644 drivers/cpufreq/exynos-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos-cpufreq.h
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 3129749..38f691a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -16,42 +16,6 @@ config ARM_DT_BL_CPUFREQ
This enables probing via DT for Generic CPUfreq driver for ARM
big.LITTLE platform. This gets frequency tables from DT.
-config ARM_EXYNOS_CPUFREQ
- bool
-
-config ARM_EXYNOS4210_CPUFREQ
- bool "SAMSUNG EXYNOS4210"
- depends on CPU_EXYNOS4210
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS4210
- SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
-
-config ARM_EXYNOS4X12_CPUFREQ
- bool "SAMSUNG EXYNOS4x12"
- depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS4X12
- SoC (EXYNOS4212 or EXYNOS4412).
-
- If in doubt, say N.
-
-config ARM_EXYNOS5250_CPUFREQ
- bool "SAMSUNG EXYNOS5250"
- depends on SOC_EXYNOS5250
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS5250
- SoC.
-
- If in doubt, say N.
-
config ARM_EXYNOS5440_CPUFREQ
bool "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
@@ -66,21 +30,6 @@ config ARM_EXYNOS5440_CPUFREQ
If in doubt, say N.
-config ARM_EXYNOS_CPU_FREQ_BOOST_SW
- bool "EXYNOS Frequency Overclocking - Software"
- depends on ARM_EXYNOS_CPUFREQ
- select CPU_FREQ_BOOST_SW
- select EXYNOS_THERMAL
- help
- This driver supports software managed overclocking (BOOST).
- It allows usage of special frequencies for Samsung Exynos
- processors if thermal conditions are appropriate.
-
- It reguires, for safe operation, thermal framework with properly
- defined trip points.
-
- If in doubt, say N.
-
config ARM_HIGHBANK_CPUFREQ
tristate "Calxeda Highbank-based"
depends on ARCH_HIGHBANK
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..3abfe05 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -49,10 +49,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) +=
arm_big_little_dt.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
deleted file mode 100644
index fcd2914..000
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ /dev/null
@@ -1,292 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS - CPU frequency scaling support for EXYNOS series
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "exynos-cpufreq.h"
-
-static struct exynos_dvfs_info *exynos_info;
-
-static struct regulator *arm_regulator;
-
-static unsigned int locking_frequency;
-static bool frequency_locked;
-static DEFINE_MUTEX(cpufreq_lock);
-
-static int exynos_cpufreq_get_index(unsigned int freq)
-{
-
[PATCH v3 6/7] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
From: Thomas Abraham
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham
Reviewed-by: Lukasz Majewski
---
arch/arm/mach-exynos/common.c |5 -
arch/arm/mach-exynos/common.h |1 -
arch/arm/mach-exynos/mach-exynos4-dt.c |2 +-
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +-
4 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index f18be40..72ae5d3 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -303,11 +303,6 @@ void __init exynos_cpuidle_init(void)
platform_device_register(&exynos_cpuidle);
}
-void __init exynos_cpufreq_init(void)
-{
- platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
-}
-
void __init exynos_init_late(void)
{
if (of_machine_is_compatible("samsung,exynos5440"))
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f76967b..0c31b34 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -22,7 +22,6 @@ void exynos_init_io(void);
void exynos4_restart(enum reboot_mode mode, const char *cmd);
void exynos5_restart(enum reboot_mode mode, const char *cmd);
void exynos_cpuidle_init(void);
-void exynos_cpufreq_init(void);
void exynos_init_late(void);
void exynos_firmware_init(void);
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index d3e54b7..9a25320 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -22,8 +22,8 @@
static void __init exynos4_dt_machine_init(void)
{
exynos_cpuidle_init();
- exynos_cpufreq_init();
+ platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 37ea261..9dc3710 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -44,8 +44,8 @@ static void __init exynos5_dt_machine_init(void)
}
exynos_cpuidle_init();
- exynos_cpufreq_init();
+ platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
On Fri, Feb 7, 2014 at 8:59 PM, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/base/power/opp.c | 34 +-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> struct device_opp *dev_opp;
>> struct dev_pm_opp *opp;
>> struct cpufreq_frequency_table *freq_table;
>> - int i = 0;
>> + int i = 0, j, len, ret;
>> + u32 *boost_freqs = NULL;
>>
>> /* Pretend as if I am an updater */
>> mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> return -ENOMEM;
>> }
>>
>> + if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> + dev_err(dev, "%s: invalid boost frequency\n",
>> __func__);
>> + ret = -EINVAL;
>> + goto err_boost;
>> + }
>> +
>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>> + if (!boost_freqs) {
>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>> + __func__);
>> + ret = -ENOMEM;
>> + goto err_boost;
>> + }
>> + of_property_read_u32_array(dev->of_node, "boost-frequency",
>> + boost_freqs, len / sizeof(u32));
>> + }
>> +
>> list_for_each_entry(opp, &dev_opp->opp_list, node) {
>> if (opp->available) {
>> freq_table[i].driver_data = i;
>> freq_table[i].frequency = opp->rate / 1000;
>> + for (j = 0; j < len / sizeof(u32) && boost_freqs;
>> j++) {
>> + if (boost_freqs[j] ==
>> freq_table[i].frequency) {
>> + freq_table[i].driver_data =
>> + CPUFREQ_BOOST_FREQ;
>> + break;
>> + }
>> + }
>
> What if any one of the boost_freqs are not contained in the enabled
> frequencies?
It is not used as a boost frequency because its corresponding voltage
is not known. If required a warning can be printed out for the same.
Thanks,
Thomas.
>
>> i++;
>> }
>> }
>> @@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> freq_table[i].frequency = CPUFREQ_TABLE_END;
>>
>> *table = &freq_table[0];
>> + kfree(boost_freqs);
>>
>> return 0;
>> +
>> +err_boost:
>> + kfree(freq_table);
>> + mutex_unlock(&dev_opp_list_lock);
>> + return ret;
>> }
>> EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Fri, Feb 7, 2014 at 8:57 PM, Nishanth Menon wrote: > On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham wrote: >> From: Thomas Abraham >> >> Add a new optional boost-frequency binding for specifying the frequencies >> usable in boost mode. >> >> Cc: Nishanth Menon >> Cc: Lukasz Majewski >> Cc: Rob Herring >> Cc: Pawel Moll >> Cc: Mark Rutland >> Cc: Ian Campbell >> Cc: Kumar Gala >> Signed-off-by: Thomas Abraham >> --- >> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 >> +++ >> 1 file changed, 11 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> new file mode 100644 >> index 000..d925e38 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >> @@ -0,0 +1,11 @@ >> +* Device tree binding for CPU boost frequency (aka over-clocking) >> + >> +Certain CPU's can be operated in optional 'boost' mode (or sometimes >> referred as >> +overclocking) in which the CPU can operate in frequencies beyond the normal >> +operating conditions. >> + >> +Optional Properties: >> +- boost-frequency: list of frequencies in KHz to be used only in boost mode. > > boost-frequencies? Okay, I will change it. Thanks, Thomas. > >> + This list should be a subset of frequencies listed in "operating-points" >> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for >> + details about "operating-points" property. >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add device tree based lookup of boost mode frequency
Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
feedback.
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.
Thomas Abraham (2):
PM / OPP: Allow boost frequency to be looked up from device tree
Documentation: devicetree: Add boost-frequency binding to list boost mode
frequency
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++
drivers/base/power/opp.c | 34 +++-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon Cc: Lukasz Majewski Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Thomas Abraham --- Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal +operating conditions. + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. + This list should be a subset of frequencies listed in "operating-points" + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about "operating-points" property. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
drivers/base/power/opp.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index fa41874..b636826 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct device_opp *dev_opp;
struct dev_pm_opp *opp;
struct cpufreq_frequency_table *freq_table;
- int i = 0;
+ int i = 0, j, len, ret;
+ u32 *boost_freqs = NULL;
/* Pretend as if I am an updater */
mutex_lock(&dev_opp_list_lock);
@@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
return -ENOMEM;
}
+ if (of_find_property(dev->of_node, "boost-frequency", &len)) {
+ if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, "%s: invalid boost frequency\n", __func__);
+ ret = -EINVAL;
+ goto err_boost;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, "%s: no memory for boost freq table\n",
+ __func__);
+ ret = -ENOMEM;
+ goto err_boost;
+ }
+ of_property_read_u32_array(dev->of_node, "boost-frequency",
+ boost_freqs, len / sizeof(u32));
+ }
+
list_for_each_entry(opp, &dev_opp->opp_list, node) {
if (opp->available) {
freq_table[i].driver_data = i;
freq_table[i].frequency = opp->rate / 1000;
+ for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
+ if (boost_freqs[j] == freq_table[i].frequency) {
+ freq_table[i].driver_data =
+ CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ }
i++;
}
}
@@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
freq_table[i].frequency = CPUFREQ_TABLE_END;
*table = &freq_table[0];
+ kfree(boost_freqs);
return 0;
+
+err_boost:
+ kfree(freq_table);
+ mutex_unlock(&dev_opp_list_lock);
+ return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Samsung PM consolidation part 1 (clocks)
On Thu, Feb 6, 2014 at 11:46 PM, Tomasz Figa wrote: > This series reworks suspend/resume handling of Samsung clock drivers > to cover more SoC specific aspects that are beyond simple register > save and restore. The goal is to have all the suspend/resume code > that touches the clock controller in single place, which is the > clock driver. > > On Exynos4210-based Trats, Exynos4412-based Trats2 and Exynos5250-based > Arndale boards (except suspend/resume, which is broken because of > unrelated reasons): > > Tested-by: Tomasz Figa > > Tomasz Figa (9): > clk: exynos4: Remove remnants of non-DT support > clk: samsung: Provide common helpers for register save/restore > clk: samsung: exynos4: Move suspend/resume handling to SoC driver > clk: samsung: exynos5250: Move suspend/resume handling to SoC driver > clk: samsung: exynos5420: Move suspend/resume handling to SoC driver > clk: samsung: s3c64xx: Move suspend/resume handling to SoC driver > clk: samsung: Drop old suspend/resume code > clk: samsung: exynos4: Add remaining suspend/resume handling > ARM: EXYNOS: pm: Drop legacy Exynos4 clock suspend/resume code > > arch/arm/mach-exynos/pm.c| 148 +- > drivers/clk/samsung/clk-exynos4.c| 172 > +++ > drivers/clk/samsung/clk-exynos5250.c | 49 +- > drivers/clk/samsung/clk-exynos5420.c | 49 +- > drivers/clk/samsung/clk-exynos5440.c | 2 +- > drivers/clk/samsung/clk-s3c64xx.c| 79 +--- > drivers/clk/samsung/clk.c| 71 ++- > drivers/clk/samsung/clk.h | 14 ++- > 8 files changed, 348 insertions(+), 236 deletions(-) Nice series! Reviewed-by: Thomas Abraham > > -- > 1.8.5.2 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Lukasz,
On Wed, Feb 5, 2014 at 5:14 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
> Fist of all, thanks for your patches.
>
>> Hi Lukasz,
>>
>> On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski
>> wrote:
>> > Hi Thomas,
>> >
>> >> From: Thomas Abraham
>> >>
>> >> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
>> >> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
>> >> Exynos specific cpufreq drivers for these platforms can be removed.
>> >>
>>
>>
>>
>> >> -static unsigned int exynos4x12_volt_table[] = {
>> >> - 135, 1287500, 125, 1187500, 1137500, 1087500,
>> >> 1037500,
>> >> - 100, 987500, 975000, 95, 925000, 90, 90
>> >> -};
>> >> -
>> >> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
>> >> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
>> >
>> > Here, you are removing BOOST support for Exynos4412, without any
>> > code, which brings back this functionality in the new code.
>> >
>> > I'd propose adding new property to cpus node and during
>> > operating-points parsing mark the entry at the
>> > cpufreq_frequency_table accordingly.
>>
>> I tried doing this as you suggested with [1] but looks like that will
>> not go through at this point.
>
> I've read your patches regarding OPP. In my opinion, despite the problem
> with further OPP format discussion (which is ongoing and probably will
> take some time), there is a palatable solution (presented below).
>
>> The other alternative would be to use
>> exynos specific cpufreq drivers only if multiplatform config is not
>> selected or use cpufreq-cpu0 if multiplatform config is selected (but
>> this is not something I would want to do). With this, there are issues
>> like clock blocks encapsulated within the opaque clock type cannot be
>> removed since exynos specific cpufreq drivers need it and hence it is
>> not really a clean solution.
>
> It would be a maintenance nightmare. We cannot afford to do such huge
> cleanup only partially. The rationale for the whole clean up is to
> remove exynos-cpufreq.c files.
>
> I also share your doubts here. We shall NOT do it this way.
>
>>The other option is to drop the support
>> for boost on exynos4x12 for now and reintroduce that when the OPP
>> bindings have been finalized.
>
> So you want to drop the BOOST kernel functionality just because you are
> doing clean up and this feature is problematic to provide at new
> approach?
>
>> Would that be okay?
>
> It is NOT acceptable. Sorry, but NAK.
>
>> Any other
>> suggestions will also be helpful.
>
> For me it would be perfectly fine to see at device tree CPU0 node code
> proposed by Nishanth:
>
> operating-points = < Fa Va
> Fb Vb
> Fc Vc
> Fd Vd
> >;
> boost-frequencies = ;
>
> And then the cpufreq table could be properly modified by marking
> relevant frequencies as CPUFREQ_BOOST_FREQ.
Okay, thanks. Initially it looked like adding boost frequencies into
operating-modes would convolute it but I guess I was wrong. So I will
add support for looking up "boost-frequencies" property in
dev_pm_opp_init_cpufreq_table function and mark the frequencies listed
in this binding as CPUFREQ_BOOST_FREQ.
Thanks,
Thomas.
>
>>
>> Thanks,
>> Thomas.
>>
>> >
>> >> - {L1, 1400 * 1000},
>> >> - {L2, 1300 * 1000},
>> >> - {L3, 1200 * 1000},
>> >> - {L4, 1100 * 1000},
>> >> - {L5, 1000 * 1000},
>> >> - {L6, 900 * 1000},
>> >> - {L7, 800 * 1000},
>> >> - {L8, 700 * 1000},
>> >> - {L9, 600 * 1000},
>> >> - {L10, 500 * 1000},
>> >> - {L11, 400 * 1000},
>> >> - {L12, 300 * 1000},
>> >> - {L13, 200 * 1000},
>> >> - {0, CPUFREQ_TABLE_END},
>> >> -};
>> >> -
>> >> -static struct apll_freq *apll_freq_4x12;
>> >> -
>> >> -static struct apll_freq apll_freq_4212[] = {
>> >> - /*
>> >> - * values:
>> >> - * freq
>> >> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> >> PCLK_DBG, APLL, CORE2
>> >> - * clock divider for COPY, HPM, RESERVED
>> >> - * PLL M, P, S
>> >> - */
>> >> - APLL_FREQ
Re: [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Lukasz,
On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> From: Thomas Abraham
>>
>> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
>> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
>> Exynos specific cpufreq drivers for these platforms can be removed.
>>
>> -static unsigned int exynos4x12_volt_table[] = {
>> - 135, 1287500, 125, 1187500, 1137500, 1087500,
>> 1037500,
>> - 100, 987500, 975000, 95, 925000, 90, 90
>> -};
>> -
>> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
>> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
>
> Here, you are removing BOOST support for Exynos4412, without any code,
> which brings back this functionality in the new code.
>
> I'd propose adding new property to cpus node and during
> operating-points parsing mark the entry at the cpufreq_frequency_table
> accordingly.
I tried doing this as you suggested with [1] but looks like that will
not go through at this point. The other alternative would be to use
exynos specific cpufreq drivers only if multiplatform config is not
selected or use cpufreq-cpu0 if multiplatform config is selected (but
this is not something I would want to do). With this, there are issues
like clock blocks encapsulated within the opaque clock type cannot be
removed since exynos specific cpufreq drivers need it and hence it is
not really a clean solution. The other option is to drop the support
for boost on exynos4x12 for now and reintroduce that when the OPP
bindings have been finalized. Would that be okay? Any other
suggestions will also be helpful.
Thanks,
Thomas.
>
>> - {L1, 1400 * 1000},
>> - {L2, 1300 * 1000},
>> - {L3, 1200 * 1000},
>> - {L4, 1100 * 1000},
>> - {L5, 1000 * 1000},
>> - {L6, 900 * 1000},
>> - {L7, 800 * 1000},
>> - {L8, 700 * 1000},
>> - {L9, 600 * 1000},
>> - {L10, 500 * 1000},
>> - {L11, 400 * 1000},
>> - {L12, 300 * 1000},
>> - {L13, 200 * 1000},
>> - {0, CPUFREQ_TABLE_END},
>> -};
>> -
>> -static struct apll_freq *apll_freq_4x12;
>> -
>> -static struct apll_freq apll_freq_4212[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, RESERVED
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 2, 0, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 2, 0, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 1),
>> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 2, 0, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 2, 0, 100, 3, 2),
>> -};
>> -
>> -static struct apll_freq apll_freq_4412[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, CORES
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 7, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 6, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 6, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 5, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 0, 5, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 0, 4, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 4, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 3, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 3, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 1,
Re: [PATCH 1/2] PM / OPP: Add support for 'boost' mode OPP
On Tue, Feb 4, 2014 at 8:45 PM, Nishanth Menon wrote:
> On 02/04/2014 03:41 AM, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost OPPs from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>
> Why is a cpufreq feature being pushed on to OPP library? you can very
> well have a property boot-frequencies = < a b c > and be done with the
> job.
The boost-opp was not limited to be a cpu/cpufreq only feature. Any
device (such as a bus) which has OPPs and if it can support optional
boost OPPs, can utilize this feature. The boost OPPs also require a
voltage to be associated with the frequency and hence the binding
boost-frequencies would not be suffice. The code changes in this patch
also do not have anything that is cpufreq specific.
>
> I agree with Rob's comment that this is something we have to discuss
> in wider "add features to an OPP" discussion[1].
Okay. I have read through the discussion in [1]. Thanks for the link.
Assuming that the current OPP tuple format will not change, I do not
feel the code changes in this patch will be hinder the outcome of the
discussion in [1].
Regards,
Thomas.
>
>
> [1] http://marc.info/?t=13910894641&r=1&w=2
>
>> drivers/base/power/opp.c | 69
>> +-
>> 1 file changed, 56 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index 2553867..de4d52d 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -62,6 +62,7 @@ struct dev_pm_opp {
>> struct list_head node;
>>
>> bool available;
>> + bool boost;
>> unsigned long rate;
>> unsigned long u_volt;
>>
>> @@ -380,10 +381,12 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct
>> device *dev,
>> EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
>>
>> /**
>> - * dev_pm_opp_add() - Add an OPP table from a table definitions
>> + * dev_pm_opp_add_flags() - Add an OPP to device OPP list with flags
>> * @dev: device for which we do this operation
>> * @freq:Frequency in Hz for this OPP
>> * @u_volt: Voltage in uVolts for this OPP
>> + * @available: initial availability of the OPP with adding it to the
>> list.
>> + * @boost: availability of this opp in controller's boost operating mode.
>> *
>> * This function adds an opp definition to the opp list and returns status.
>> * The opp is made available by default and it can be controlled using
>> @@ -395,7 +398,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
>> * that this function is *NOT* called under RCU protection or in contexts
>> where
>> * mutex cannot be locked.
>> */
>> -int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long
>> u_volt)
>> +static int dev_pm_opp_add_flags(struct device *dev, unsigned long freq,
>> + unsigned long u_volt, bool available, bool boost)
>> {
>> struct device_opp *dev_opp = NULL;
>> struct dev_pm_opp *opp, *new_opp;
>> @@ -441,7 +445,8 @@ int dev_pm_opp_add(struct device *dev, unsigned long
>> freq, unsigned long u_volt)
>> new_opp->dev_opp = dev_opp;
>> new_opp->rate = freq;
>> new_opp->u_volt = u_volt;
>> - new_opp->available = true;
>> + new_opp->available = available;
>> + new_opp->boost = boost;
>>
>> /* Insert new OPP in order of increasing frequency */
>> head = &dev_opp->opp_list;
>> @@ -462,6 +467,27 @@ int dev_pm_opp_add(struct device *dev, unsigned long
>> freq, unsigned long u_volt)
>> srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ADD, new_opp);
>> return 0;
>> }
>> +
>> +/**
>> + * dev_pm_opp_add() - Add an OPP table from a table definitions
>> + * @dev: device for which we do this operation
>> + * @freq:Frequency in Hz for this OPP
>> + * @u_volt: Voltage in uVolts for this OPP
>> + *
>> + * This function adds an opp definition to the opp list and returns status.
>> + * The opp is made available by default and it can be controlled using
>> + * dev_pm_opp_enable/disable functions.
>> + *
>> + * Locking: The internal device_opp and opp structures are RCU
[PATCH 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
From: Thomas Abraham
Certain CPUs or devices can support optional boost operating modes. Add a new
binding to list OPPs to be additionally made available in boost operating modes.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Thomas Abraham
---
Documentation/devicetree/bindings/power/opp.txt |9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt
b/Documentation/devicetree/bindings/power/opp.txt
index 74499e5..4df5cca 100644
--- a/Documentation/devicetree/bindings/power/opp.txt
+++ b/Documentation/devicetree/bindings/power/opp.txt
@@ -10,6 +10,10 @@ Properties:
freq: clock frequency in kHz
vol: voltage in microvolt
+Optional Properties:
+- boost-opp: Similar to "operating-points" property but usable only in
+ optional boost operating modes.
+
Examples:
cpu@0 {
@@ -22,4 +26,9 @@ cpu@0 {
396000 95
198000 85
>;
+ boost-opp = <
+ /* kHz uV */
+ 150 135
+ 140 1285000
+ >;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add device tree based lookup of boost mode OPPs
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode OPPs in dt node. This
requirement came up when Lukasz pointed out the regression caused by
the Exynos CPUfreq driver consolidation patches.
Thomas Abraham (2):
PM / OPP: Add support for 'boost' mode OPP
Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
Documentation/devicetree/bindings/power/opp.txt |9 +++
drivers/base/power/opp.c| 69 ++-
2 files changed, 65 insertions(+), 13 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] PM / OPP: Add support for 'boost' mode OPP
From: Thomas Abraham
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost OPPs from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon
Cc: Lukasz Majewski
Signed-off-by: Thomas Abraham
---
drivers/base/power/opp.c | 69 +-
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..de4d52d 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -62,6 +62,7 @@ struct dev_pm_opp {
struct list_head node;
bool available;
+ bool boost;
unsigned long rate;
unsigned long u_volt;
@@ -380,10 +381,12 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct
device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
/**
- * dev_pm_opp_add() - Add an OPP table from a table definitions
+ * dev_pm_opp_add_flags() - Add an OPP to device OPP list with flags
* @dev: device for which we do this operation
* @freq: Frequency in Hz for this OPP
* @u_volt:Voltage in uVolts for this OPP
+ * @available: initial availability of the OPP with adding it to the list.
+ * @boost: availability of this opp in controller's boost operating mode.
*
* This function adds an opp definition to the opp list and returns status.
* The opp is made available by default and it can be controlled using
@@ -395,7 +398,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
* that this function is *NOT* called under RCU protection or in contexts where
* mutex cannot be locked.
*/
-int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long
u_volt)
+static int dev_pm_opp_add_flags(struct device *dev, unsigned long freq,
+ unsigned long u_volt, bool available, bool boost)
{
struct device_opp *dev_opp = NULL;
struct dev_pm_opp *opp, *new_opp;
@@ -441,7 +445,8 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq,
unsigned long u_volt)
new_opp->dev_opp = dev_opp;
new_opp->rate = freq;
new_opp->u_volt = u_volt;
- new_opp->available = true;
+ new_opp->available = available;
+ new_opp->boost = boost;
/* Insert new OPP in order of increasing frequency */
head = &dev_opp->opp_list;
@@ -462,6 +467,27 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq,
unsigned long u_volt)
srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ADD, new_opp);
return 0;
}
+
+/**
+ * dev_pm_opp_add() - Add an OPP table from a table definitions
+ * @dev: device for which we do this operation
+ * @freq: Frequency in Hz for this OPP
+ * @u_volt:Voltage in uVolts for this OPP
+ *
+ * This function adds an opp definition to the opp list and returns status.
+ * The opp is made available by default and it can be controlled using
+ * dev_pm_opp_enable/disable functions.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected.
+ * Hence this function internally uses RCU updater strategy with mutex locks
+ * to keep the integrity of the internal data structures. Callers should ensure
+ * that this function is *NOT* called under RCU protection or in contexts where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long
u_volt)
+{
+ return dev_pm_opp_add_flags(dev, freq, u_volt, true, false);
+}
EXPORT_SYMBOL_GPL(dev_pm_opp_add);
/**
@@ -651,7 +677,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
list_for_each_entry(opp, &dev_opp->opp_list, node) {
if (opp->available) {
- freq_table[i].driver_data = i;
+ freq_table[i].driver_data =
+ opp->boost ? CPUFREQ_BOOST_FREQ : i;
freq_table[i].frequency = opp->rate / 1000;
i++;
}
@@ -701,19 +728,14 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(struct
device *dev)
}
#ifdef CONFIG_OF
-/**
- * of_init_opp_table() - Initialize opp table from device tree
- * @dev: device pointer used to lookup device OPPs.
- *
- * Register the initial OPP table with the OPP library for given device.
- */
-int of_init_opp_table(struct device *dev)
+static int of_parse_opp_table(struct device *dev, const char *prop_name,
+ bool boost)
{
const struct property *prop;
const __be32 *val;
int nr;
- prop = of_find_property(dev->of_node, "operating-points", NULL);
+ prop = of_find_property(dev->of_node, prop_name, NULL);
if (!prop)
return -ENODEV;
if (!prop->value)
@@ -734,7 +756,7 @@ int of_init_opp_table(struct device *dev)
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
On Thu, Jan 30, 2014 at 8:39 PM, Heiko Stübner wrote: > On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote: >> Hi Mike, >> >> On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette > wrote: >> > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham > wrote: >> >> Hi Mike, >> >> >> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette > wrote: >> >>> Quoting Thomas Abraham (2014-01-18 04:10:51) >> >>> >> > As far as I can tell >> > the remux does not happen because it is necessary to generate the >> > required clock rate, but because we don't want to run the ARM core out >> > of spec for a short time while the PLL relocks. Assuming I have that >> > part of it right, I prefer for the parent mux operation to be a part >> > of the CPUfreq driver's .target callback instead of hidden away in the >> > clock driver. >> >> The re-parenting is mostly done to keep the ARM CPU clocked while the >> PLL is stopped, reprogrammed and restarted. One of the side effects of >> that is, the clock speed of the temporary parent could be higher then >> what is allowed due to the ARM voltage at the time of re-parenting. >> That is the reason to use the safe voltage. > > The Rockchip-SoCs use something similar, so I'm following quite closely what > Thomas is trying to do here, as similar solution would also solve this issue > for me. > > On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced from > the divided armclk, creating additional constraints. > > But on the RKs (at least in the upstream sources) the armclk is simply equal > to the pll output. A divider exists, but is only used to make sure that the > armclk stays below the original rate when sourced from the temp-parent, like > > if (clk_get_rate(temp_parent) > clk_get_rate(main_parent) > set_divider(something so that rate(temp) <= rate(main) > clk_set_parent(...) > > Isn't there a similar possiblity on your platform, as it would remove the need > for the safe-voltage? Hi Heiko, Yes, this works too! I have tested this method on Exynos4210, Exynos4412 and Exynos5250 and it works fine without any need for safe voltage. This is much better than using safe voltage. Thank you for suggesting this. Regards, Thomas. > > > In general I also like the approach of hiding the rate-change logic inside > this composite clock, as the depending clocks can be easily kept in sync. As > with the Rockchips the depending clocks are different for each of the three > Cortex-A9 SoCs I looked at, it would be "interesting" if all of this would > need to be done in a cpufreq driver. > > > Heiko > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
On Sat, Feb 1, 2014 at 9:40 AM, Mike Turquette wrote:
> Quoting Heiko Stübner (2014-01-30 07:09:04)
>> On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
>> > Hi Mike,
>> >
>> > On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette
>> wrote:
>> > > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham
>> wrote:
>> > >> Hi Mike,
>> > >>
>> > >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette
>> wrote:
>> > >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
>> > >>>
>> > > As far as I can tell
>> > > the remux does not happen because it is necessary to generate the
>> > > required clock rate, but because we don't want to run the ARM core out
>> > > of spec for a short time while the PLL relocks. Assuming I have that
>> > > part of it right, I prefer for the parent mux operation to be a part
>> > > of the CPUfreq driver's .target callback instead of hidden away in the
>> > > clock driver.
>> >
>> > The re-parenting is mostly done to keep the ARM CPU clocked while the
>> > PLL is stopped, reprogrammed and restarted. One of the side effects of
>> > that is, the clock speed of the temporary parent could be higher then
>> > what is allowed due to the ARM voltage at the time of re-parenting.
>> > That is the reason to use the safe voltage.
>>
>> The Rockchip-SoCs use something similar, so I'm following quite closely what
>> Thomas is trying to do here, as similar solution would also solve this issue
>> for me.
>>
>> On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced from
>> the divided armclk, creating additional constraints.
>>
>> But on the RKs (at least in the upstream sources) the armclk is simply equal
>> to the pll output. A divider exists, but is only used to make sure that the
>> armclk stays below the original rate when sourced from the temp-parent, like
>>
>> if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
>> set_divider(something so that rate(temp) <= rate(main)
>> clk_set_parent(...)
>>
>> Isn't there a similar possiblity on your platform, as it would remove the
>> need
>> for the safe-voltage?
>>
>>
>> In general I also like the approach of hiding the rate-change logic inside
>> this composite clock, as the depending clocks can be easily kept in sync. As
>> with the Rockchips the depending clocks are different for each of the three
>> Cortex-A9 SoCs I looked at, it would be "interesting" if all of this would
>> need to be done in a cpufreq driver.
>
> I wonder if hiding these details inside of the composite clock
> implementation indicates the lack of some needed feature in the clk
> core? I've discussed the idea of "coordinated rate changes" before. E.g:
>
> _
> | clk | opp-low | opp-mid | opp-fast |
> | | | | |
> |pll| 30| 60 | 60 |
> | | | | |
> |div| 15| 30 | 60 |
> | | | | |
> |mpu_clk| 15| 30 | 60 |
> | | | | |
> |periph | 15| 15 | 30 |
> -
>
> A call to clk_set_rate() against any of those clocks will result in all
> of their dividers being updated. At the implementation level this might
> look something like this extremely simplified pseudocode:
>
> int clk_set_rate(struct clk* clk, unsigned long rate)
> {
> /* trap clks that support coordinated rate changes */
> if (clk->ops->coordinate_rate)
> return clk->ops->coordinate_rate(clk->hw, rate);
> ...
> }
>
> and,
>
> struct coord_rates {
> struct clk_hw *hw;
> struct clk *parent;
> struct clk *rate;
> };
>
> and in the clock driver,
>
> #define PLL 0
> #define DIV 1
> #define MPU 2
> #define PER 3
>
> #define NR_OPP 4
> #define NR_CLK 4
>
> struct coord_rates my_opps[NR_OPP][NR_CLK]; // populated from DT data
>
> int my_coordinate_rate_callback(struct clk_hw *hw, unsigned long rate)
> {
> struct coord_rate **selected_opp;
>
> for(i = 0; i < NR_OPP; i++) {
> for(j
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Hi Mike, On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette wrote: > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham wrote: >> Hi Mike, >> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette >> wrote: >>> Quoting Thomas Abraham (2014-01-18 04:10:51) >>>> From: Thomas Abraham >>>> >>>> On some platforms such as the Samsung Exynos, changing the frequency >>>> of the CPU clock requires changing the frequency of the PLL that is >>>> supplying the CPU clock. To change the frequency of the PLL, the CPU >>>> clock is temporarily reparented to another parent clock. >>>> >>>> The clock frequency of this temporary parent clock could be much higher >>>> than the clock frequency of the PLL at the time of reparenting. Due >>>> to the temporary increase in the CPU clock speed, the CPU (and any other >>>> components in the CPU clock domain such as dividers, mux, etc.) have to >>>> to be operated at a higher voltage level, called the safe voltage level. >>>> This patch adds optional support to temporarily switch to a safe voltage >>>> level during CPU frequency transitions. >>>> >>>> Cc: Shawn Guo >>>> Signed-off-by: Thomas Abraham >>> >>> I'm not a fan of this change. This corner case should be abstracted away >>> somehow. I had talked to Chander Kayshap previously about handling >>> voltage changes in clock notifier callbacks, which then renders any >>> voltage change as a trivial part of the clock rate transition. That >>> means that this "safe voltage" thing could be handled automagically >>> without any additional code in the CPUfreq driver. >>> >>> There are two nice ways to do this with the clock framework. First is >>> explicit re-parenting with voltage scaling done in the clock rate-change >>> notifiers: >>> >>> clk_set_parent(cpu_clk, temp_parent); >>> /* implicit voltage scaling to "safe voltage" happens above */ >>> clk_set_rate(pll, some_rate); >>> clk_set_parent(cpu_clk, pll); >>> /* implicit voltage scaling to nominal OPP voltage happens above */ >>> >>> The above sequence would require a separate exnyos CPUfreq driver, due >>> to the added clk_set_parent logic. >>> >>> The second way to do this is to abstract the clk re-muxing logic out >>> into the clk driver, which would allow cpufreq-cpu0 to be used for the >>> exynos chips. >> >> This is the approach this patch series takes (patch 2/7). The clock >> re-muxing logic is handled by a clock driver code. The difference from >> what you suggested is that the safe voltage (that may be optionally) >> required before doing the re-muxing is handled here in cpufreq-cpu0 >> driver. > > Right, I understand the approach taken in this series and I'm not sure > it is the right one. Why does the clock driver handle the remuxing if > it is a functional dependency of the ARM core? The output of the PLL is the input to a tree of clock nodes. One of the outputs from this tree is the clock to ARM. And the other outputs do not serve as parents to any other clocks in the system but are used internally in the bus interconnect. In addition to that, there are clock speed restrictions for the clock outputs from this tree with respect to speeds of other clocks in this clock tree. Hence, this entire clock tree has been purged into a single composite clock which includes mux and dividers. So the clock tree now looks like PLL Output -> Custom Composite Clock -> ARM clock output. But there is a problem when changing the ARM clock speed which in turn causes change in PLL clock speed. When PLL clock speed has to be changed, the PLL has to be first turned off. Which means the clock to ARM core is cut-off. To avoid that, the Custom Composite Clock now has to get its clock from another source until the PLL is ready to operate again. So this composite clock does an automatic re-parenting (the mux is within is composite clock) because it knows that it is its responsibility to ensure clock ARM all the time. > As far as I can tell > the remux does not happen because it is necessary to generate the > required clock rate, but because we don't want to run the ARM core out > of spec for a short time while the PLL relocks. Assuming I have that > part of it right, I prefer for the parent mux operation to be a part > of the CPUfreq driver's .target callback instead of hidden away in the > clock driver. The re-parenting is mostly done to keep the ARM CPU clocked while the PLL is stopped, reprogrammed and restarted. One of the
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Hi Lukasz, On Tue, Jan 28, 2014 at 8:36 PM, Lukasz Majewski wrote: > Hi Thomas, > >> Hi Lukasz, >> >> On Tue, Jan 28, 2014 at 1:47 PM, Lukasz Majewski >> wrote: >> > Hi Thomas, Mike >> > >> >> Hi Mike, >> >> >> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette >> >> wrote: >> >> > Quoting Thomas Abraham (2014-01-18 04:10:51) >> >> >> From: Thomas Abraham >> >> >> >> >> >> On some platforms such as the Samsung Exynos, changing the >> >> >> frequency of the CPU clock requires changing the frequency of >> >> >> the PLL that is supplying the CPU clock. To change the >> >> >> frequency of the PLL, the CPU clock is temporarily reparented >> >> >> to another parent clock. >> >> >> >> >> >> The clock frequency of this temporary parent clock could be much >> >> >> higher than the clock frequency of the PLL at the time of >> >> >> reparenting. Due to the temporary increase in the CPU clock >> >> >> speed, the CPU (and any other components in the CPU clock >> >> >> domain such as dividers, mux, etc.) have to to be operated at a >> >> >> higher voltage level, called the safe voltage level. This patch >> >> >> adds optional support to temporarily switch to a safe voltage >> >> >> level during CPU frequency transitions. >> >> >> >> >> >> Cc: Shawn Guo >> >> >> Signed-off-by: Thomas Abraham >> >> > >> >> > I'm not a fan of this change. This corner case should be >> >> > abstracted away somehow. I had talked to Chander Kayshap >> >> > previously about handling voltage changes in clock notifier >> >> > callbacks, which then renders any voltage change as a trivial >> >> > part of the clock rate transition. That means that this "safe >> >> > voltage" thing could be handled automagically without any >> >> > additional code in the CPUfreq driver. >> >> > >> >> > There are two nice ways to do this with the clock framework. >> >> > First is explicit re-parenting with voltage scaling done in the >> >> > clock rate-change notifiers: >> >> > >> >> > clk_set_parent(cpu_clk, temp_parent); >> >> > /* implicit voltage scaling to "safe voltage" happens above */ >> >> > clk_set_rate(pll, some_rate); >> >> > clk_set_parent(cpu_clk, pll); >> >> > /* implicit voltage scaling to nominal OPP voltage happens above >> >> > */ >> >> > >> > >> > I must agree with Mike here. In my opinion the above approach is >> > more compliant with CCF (as I've pointed it out in my other comment >> > - the cpu_clk has more than one parent and we could switch between >> > them when needed). >> >> The mux which is used to re-parent is part of the larger opaque cpu >> clock type (more like the composite clock). So I am not sure how this >> isn't compliant with ccf. > > My point here is to use the clk_set_parent() explicitly instead of > changing the mux with writing values directly to registers. > > However, I'm also aware, that we must reparent quickly. so I'm OK > with your approach. Okay. > >> >> > >> >> > The above sequence would require a separate exnyos CPUfreq >> >> > driver, due to the added clk_set_parent logic. >> >> > >> >> > The second way to do this is to abstract the clk re-muxing logic >> >> > out into the clk driver, which would allow cpufreq-cpu0 to be >> >> > used for the exynos chips. >> >> >> >> This is the approach this patch series takes (patch 2/7). The clock >> >> re-muxing logic is handled by a clock driver code. The difference >> >> from what you suggested is that the safe voltage (that may be >> >> optionally) required before doing the re-muxing is handled here in >> >> cpufreq-cpu0 driver. >> >> >> >> The safe voltage setup can be done in the notifier as you >> >> suggested. >> > >> > If the clk_set_parent() approach is not suitable, then cannot we >> > consider using the one from highbank-cpufreq.c? >> > >> > Here we have cpufreq-cpu0.c which sets voltage of the cpu_clk. >> > In the highban
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
On Tue, Jan 28, 2014 at 5:19 PM, Shawn Guo wrote: > On Tue, Jan 28, 2014 at 11:00:29AM +0530, Thomas Abraham wrote: >> Hi Mike, >> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette >> wrote: >> > Quoting Thomas Abraham (2014-01-18 04:10:51) >> >> From: Thomas Abraham >> >> >> >> On some platforms such as the Samsung Exynos, changing the frequency >> >> of the CPU clock requires changing the frequency of the PLL that is >> >> supplying the CPU clock. To change the frequency of the PLL, the CPU >> >> clock is temporarily reparented to another parent clock. >> >> >> >> The clock frequency of this temporary parent clock could be much higher >> >> than the clock frequency of the PLL at the time of reparenting. Due >> >> to the temporary increase in the CPU clock speed, the CPU (and any other >> >> components in the CPU clock domain such as dividers, mux, etc.) have to >> >> to be operated at a higher voltage level, called the safe voltage level. >> >> This patch adds optional support to temporarily switch to a safe voltage >> >> level during CPU frequency transitions. >> >> >> >> Cc: Shawn Guo >> >> Signed-off-by: Thomas Abraham >> > >> > I'm not a fan of this change. This corner case should be abstracted away >> > somehow. I had talked to Chander Kayshap previously about handling >> > voltage changes in clock notifier callbacks, which then renders any >> > voltage change as a trivial part of the clock rate transition. That >> > means that this "safe voltage" thing could be handled automagically >> > without any additional code in the CPUfreq driver. >> > >> > There are two nice ways to do this with the clock framework. First is >> > explicit re-parenting with voltage scaling done in the clock rate-change >> > notifiers: >> > >> > clk_set_parent(cpu_clk, temp_parent); >> > /* implicit voltage scaling to "safe voltage" happens above */ >> > clk_set_rate(pll, some_rate); >> > clk_set_parent(cpu_clk, pll); >> > /* implicit voltage scaling to nominal OPP voltage happens above */ >> > >> > The above sequence would require a separate exnyos CPUfreq driver, due >> > to the added clk_set_parent logic. >> > >> > The second way to do this is to abstract the clk re-muxing logic out >> > into the clk driver, which would allow cpufreq-cpu0 to be used for the >> > exynos chips. >> >> This is the approach this patch series takes (patch 2/7). The clock >> re-muxing logic is handled by a clock driver code. The difference from >> what you suggested is that the safe voltage (that may be optionally) >> required before doing the re-muxing is handled here in cpufreq-cpu0 >> driver. >> >> The safe voltage setup can be done in the notifier as you suggested. >> But, doing that in cpufreq-cpu0 driver will help other platforms reuse >> this feature if required. Also, if done here, the regulator handling >> is localized in this driver which otherwise would need to be handled >> in two places, cpufreq-cpu0 driver and the clock notifier. >> >> So I tend to prefer the approach in this patch but I am willing to >> consider any suggestions. Shawn, it would be helpful if you could let >> us know your thoughts on this. I am almost done with testing the v3 of >> this series and want to post it so if there are any objections to the >> changes in this patch, please let me know. > > To me, it's the best that we reuse cpufreq-cpu0 for exynos without any > changes on cpufreq-cpu0 driver ;) Okay, so that leaves us with the only option of handling "safe voltage" using clock notifier callbacks as suggested by Mike. So there are two options - a samsung specific cpufreq driver handling the clock notifiers (and reusing cpufreq-cpu0 driver) or the samsung clock driver handles the clock notifiers (and reusing cpufreq-cpu0 driver). With the second option, the clock driver will have to handle the regulator lookup from the cpu node, deferring regulator lookup until the cpu and regulator devices are registered and using regulator api inside clock driver. This seems like too much code to just manage the "safe voltage". So how about the first option of samsung specific cpufreq driver. If there are any other alternatives, please let me know. Thanks, Thomas. > > Shawn > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Hi Lukasz, On Tue, Jan 28, 2014 at 1:47 PM, Lukasz Majewski wrote: > Hi Thomas, Mike > >> Hi Mike, >> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette >> wrote: >> > Quoting Thomas Abraham (2014-01-18 04:10:51) >> >> From: Thomas Abraham >> >> >> >> On some platforms such as the Samsung Exynos, changing the >> >> frequency of the CPU clock requires changing the frequency of the >> >> PLL that is supplying the CPU clock. To change the frequency of >> >> the PLL, the CPU clock is temporarily reparented to another parent >> >> clock. >> >> >> >> The clock frequency of this temporary parent clock could be much >> >> higher than the clock frequency of the PLL at the time of >> >> reparenting. Due to the temporary increase in the CPU clock speed, >> >> the CPU (and any other components in the CPU clock domain such as >> >> dividers, mux, etc.) have to to be operated at a higher voltage >> >> level, called the safe voltage level. This patch adds optional >> >> support to temporarily switch to a safe voltage level during CPU >> >> frequency transitions. >> >> >> >> Cc: Shawn Guo >> >> Signed-off-by: Thomas Abraham >> > >> > I'm not a fan of this change. This corner case should be abstracted >> > away somehow. I had talked to Chander Kayshap previously about >> > handling voltage changes in clock notifier callbacks, which then >> > renders any voltage change as a trivial part of the clock rate >> > transition. That means that this "safe voltage" thing could be >> > handled automagically without any additional code in the CPUfreq >> > driver. >> > >> > There are two nice ways to do this with the clock framework. First >> > is explicit re-parenting with voltage scaling done in the clock >> > rate-change notifiers: >> > >> > clk_set_parent(cpu_clk, temp_parent); >> > /* implicit voltage scaling to "safe voltage" happens above */ >> > clk_set_rate(pll, some_rate); >> > clk_set_parent(cpu_clk, pll); >> > /* implicit voltage scaling to nominal OPP voltage happens above */ >> > > > I must agree with Mike here. In my opinion the above approach is more > compliant with CCF (as I've pointed it out in my other comment - the > cpu_clk has more than one parent and we could switch between them when > needed). The mux which is used to re-parent is part of the larger opaque cpu clock type (more like the composite clock). So I am not sure how this isn't compliant with ccf. > >> > The above sequence would require a separate exnyos CPUfreq driver, >> > due to the added clk_set_parent logic. >> > >> > The second way to do this is to abstract the clk re-muxing logic out >> > into the clk driver, which would allow cpufreq-cpu0 to be used for >> > the exynos chips. >> >> This is the approach this patch series takes (patch 2/7). The clock >> re-muxing logic is handled by a clock driver code. The difference from >> what you suggested is that the safe voltage (that may be optionally) >> required before doing the re-muxing is handled here in cpufreq-cpu0 >> driver. >> >> The safe voltage setup can be done in the notifier as you suggested. > > If the clk_set_parent() approach is not suitable, then cannot we > consider using the one from highbank-cpufreq.c? > > Here we have cpufreq-cpu0.c which sets voltage of the cpu_clk. > In the highbank-cpufreq.c there are clock notifiers to change the > voltage. > > Cannot Exynos reuse such approach? Why shall we pollute cpufreq-cpu0.c > with another solution? The highbank-cpufreq.c file was introduced because platforms using this driver did not have the usual regulator to control the voltage. The first commit of this driver explains this (copied below). "Highbank processors depend on the external ECME to perform voltage management based on a requested frequency. Communication between the A9 cores and the ECME happens over the pl320 IPC channel." So those platforms had no choice but to use an alternative approach to control the voltage (and reuse cpufreq-cpu0 as much as possible). The case with exynos is a different one. cpufreq-cpu0 is fully re-usable for exynos with the additional support for "safe voltage". If we agree that there might be existing or future platforms with single clock/voltage rail that require the "safe voltage" feature, then adding "safe voltage" support in cpufreq-cpu0 driver seems to be the right approach. >
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Hi Mike,
On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette wrote:
> Quoting Thomas Abraham (2014-01-18 04:10:51)
>> From: Thomas Abraham
>>
>> On some platforms such as the Samsung Exynos, changing the frequency
>> of the CPU clock requires changing the frequency of the PLL that is
>> supplying the CPU clock. To change the frequency of the PLL, the CPU
>> clock is temporarily reparented to another parent clock.
>>
>> The clock frequency of this temporary parent clock could be much higher
>> than the clock frequency of the PLL at the time of reparenting. Due
>> to the temporary increase in the CPU clock speed, the CPU (and any other
>> components in the CPU clock domain such as dividers, mux, etc.) have to
>> to be operated at a higher voltage level, called the safe voltage level.
>> This patch adds optional support to temporarily switch to a safe voltage
>> level during CPU frequency transitions.
>>
>> Cc: Shawn Guo
>> Signed-off-by: Thomas Abraham
>
> I'm not a fan of this change. This corner case should be abstracted away
> somehow. I had talked to Chander Kayshap previously about handling
> voltage changes in clock notifier callbacks, which then renders any
> voltage change as a trivial part of the clock rate transition. That
> means that this "safe voltage" thing could be handled automagically
> without any additional code in the CPUfreq driver.
>
> There are two nice ways to do this with the clock framework. First is
> explicit re-parenting with voltage scaling done in the clock rate-change
> notifiers:
>
> clk_set_parent(cpu_clk, temp_parent);
> /* implicit voltage scaling to "safe voltage" happens above */
> clk_set_rate(pll, some_rate);
> clk_set_parent(cpu_clk, pll);
> /* implicit voltage scaling to nominal OPP voltage happens above */
>
> The above sequence would require a separate exnyos CPUfreq driver, due
> to the added clk_set_parent logic.
>
> The second way to do this is to abstract the clk re-muxing logic out
> into the clk driver, which would allow cpufreq-cpu0 to be used for the
> exynos chips.
This is the approach this patch series takes (patch 2/7). The clock
re-muxing logic is handled by a clock driver code. The difference from
what you suggested is that the safe voltage (that may be optionally)
required before doing the re-muxing is handled here in cpufreq-cpu0
driver.
The safe voltage setup can be done in the notifier as you suggested.
But, doing that in cpufreq-cpu0 driver will help other platforms reuse
this feature if required. Also, if done here, the regulator handling
is localized in this driver which otherwise would need to be handled
in two places, cpufreq-cpu0 driver and the clock notifier.
So I tend to prefer the approach in this patch but I am willing to
consider any suggestions. Shawn, it would be helpful if you could let
us know your thoughts on this. I am almost done with testing the v3 of
this series and want to post it so if there are any objections to the
changes in this patch, please let me know.
Thanks,
Thomas.
>
> I'm more a fan of explicitly listing the Exact Steps for the cpu opp
> transition in a separate exynos-specific CPUfreq driver, but that's
> probably an unpopular view.
>
> Regards,
> Mike
>
>> ---
>> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |7
>> drivers/cpufreq/cpufreq-cpu0.c | 37
>> +--
>> 2 files changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> index f055515..37453ab 100644
>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> @@ -19,6 +19,12 @@ Optional properties:
>> - cooling-min-level:
>> - cooling-max-level:
>> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
>> +- safe-opp: Certain platforms require that during a opp transition,
>> + a system should not go below a particular opp level. For such systems,
>> + this property specifies the minimum opp to be maintained during the
>> + opp transitions. The safe-opp value is a tuple with first element
>> + representing the safe frequency and the second element representing the
>> + safe voltage.
>>
>> Examples:
>>
>> @@ -36,6 +42,7 @@ cpus {
>> 396000 95
>> 198000 85
>> >;
>> + safe-opp = <396000 95>
>> clock-latency = <61036>; /* two CLK32 periods
Re: [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Hi Shawn,
On Mon, Jan 27, 2014 at 12:46 PM, Shawn Guo wrote:
> On Sat, Jan 18, 2014 at 05:40:51PM +0530, Thomas Abraham wrote:
>> From: Thomas Abraham
>>
>> On some platforms such as the Samsung Exynos, changing the frequency
>> of the CPU clock requires changing the frequency of the PLL that is
>> supplying the CPU clock. To change the frequency of the PLL, the CPU
>> clock is temporarily reparented to another parent clock.
>>
>> The clock frequency of this temporary parent clock could be much higher
>> than the clock frequency of the PLL at the time of reparenting. Due
>> to the temporary increase in the CPU clock speed, the CPU (and any other
>> components in the CPU clock domain such as dividers, mux, etc.) have to
>> to be operated at a higher voltage level, called the safe voltage level.
>> This patch adds optional support to temporarily switch to a safe voltage
>> level during CPU frequency transitions.
>>
>> Cc: Shawn Guo
>> Signed-off-by: Thomas Abraham
>> ---
>> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |7
>
> The devicetree list should be copied for this change.
Okay, will do in the next version.
>
>> drivers/cpufreq/cpufreq-cpu0.c | 37
>> +--
>> 2 files changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> index f055515..37453ab 100644
>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>> @@ -19,6 +19,12 @@ Optional properties:
>> - cooling-min-level:
>> - cooling-max-level:
>> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
>> +- safe-opp: Certain platforms require that during a opp transition,
>> + a system should not go below a particular opp level. For such systems,
>> + this property specifies the minimum opp to be maintained during the
>> + opp transitions. The safe-opp value is a tuple with first element
>> + representing the safe frequency and the second element representing the
>> + safe voltage.
>>
>> Examples:
>>
>> @@ -36,6 +42,7 @@ cpus {
>> 396000 95
>> 198000 85
>> >;
>> + safe-opp = <396000 95>
>> clock-latency = <61036>; /* two CLK32 periods */
>> #cooling-cells = <2>;
>> cooling-min-level = <0>;
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index 0c12ffc..075d3d1 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -27,6 +27,8 @@
>>
>> static unsigned int transition_latency;
>> static unsigned int voltage_tolerance; /* in percentage */
>> +static unsigned long safe_frequency;
>> +static unsigned long safe_voltage;
>>
>> static struct device *cpu_dev;
>> static struct clk *cpu_clk;
>> @@ -64,17 +66,30 @@ static int cpu0_set_target(struct cpufreq_policy
>> *policy, unsigned int index)
>> volt_old = regulator_get_voltage(cpu_reg);
>> }
>>
>> - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
>> + pr_debug("\n\n%u MHz, %ld mV --> %u MHz, %ld mV\n",
>
> This is an unnecessary change?
Yes, sorry missed that.
>
> Otherwise,
>
> Acked-by: Shawn Guo
Thanks for your review.
Regards,
Thomas.
>
> Shawn
>
>>old_freq / 1000, volt_old ? volt_old / 1000 : -1,
>>new_freq / 1000, volt ? volt / 1000 : -1);
>>
>> /* scaling up? scale voltage before frequency */
>> - if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
>> + if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
>> + new_freq >= safe_frequency) {
>> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
>> if (ret) {
>> pr_err("failed to scale voltage up: %d\n", ret);
>> return ret;
>> }
>> + } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
>> + /*
>> + * the scaled up voltage level for the new_freq is lower
>> + * than the safe voltage level. so set safe_voltage
>> + * as the intermediate voltage leve
Re: [PATCH v2 3/7] devicetree: bindings: add cpu clock configuration data binding for Exynos4/5
Hi Rob, On Tue, Jan 21, 2014 at 1:01 PM, Thomas Abraham wrote: > Hi Rob, > > > On Sat, Jan 18, 2014 at 8:52 PM, Rob Herring wrote: >> On Sat, Jan 18, 2014 at 6:10 AM, Thomas Abraham wrote: >>> From: Thomas Abraham >>> >>> The clk ops of the new Samsung cpu clock provider type requires >>> configuration >>> data that will be programmed in the multiple clock blocks encapsulated >>> within >>> the cpu clock provider type. This configuration data is held in the clock >>> controller node. Update clock binding documentation about this configuration >>> data format for Samsung Exynos4 and Exynos5 platforms. >>> >>> Cc: Rob Herring >> >> Please copy all maintainers. > > Okay. > >> >>> Cc: Tomasz Figa >>> Cc: >>> Signed-off-by: Thomas Abraham >>> --- >>> .../devicetree/bindings/clock/exynos4-clock.txt| 30 >>> >>> .../devicetree/bindings/clock/exynos5250-clock.txt | 21 ++ >>> 2 files changed, 51 insertions(+), 0 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >>> b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >>> index a2ac2d9..c28aabd 100644 >>> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >>> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >>> @@ -15,6 +15,29 @@ Required Properties: >>> >>> - #clock-cells: should be 1. >>> >>> +- arm-frequency-table: defines the list of arm clock speeds supported and >> >> Seems like a Samsung specific property and nothing to do with ARM, so >> it should be named accordingly. > > Okay. > >> >>> + the associated configuration values required to setup the clock >>> controller >>> + for generating those speeds. The format of each entry included in the >>> + arm-frequency-table should be as defined below (#cells per entry = 13) >>> + >>> + - for Exynos4210 and Exynos4212 based platforms: >>> + cell #1: arm clock frequency >>> + cell #2: expected arm clock parent frequency >>> + cell #3 ~ cell 12#: value of clock divider in the following order >>> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, >>> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, >>> + copy_ratio, hpm_ratio. >>> + cell #13: reserved (should be zero). >>> + >>> + - for Exynos4412 based platforms: >>> + cell #1: arm clock frequency >>> + cell #2: expected arm clock parent frequency >>> + cell #3 ~ cell #13: value of clock divider in the following order >>> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, >>> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, >>> + copy_ratio, hpm_ratio, cores_ratio >> >> You don't need voltages? Are the h/w limitations really ratios or each >> clock has a max frequency that must be maintained? I would expect the >> latter and think it would be better to specify maximum frequencies of >> each clock. Then you can calculate the dividers to keep frequencies in >> range. > > Voltage is not needed here since the cpu clock speed is managed by the > cpufreq driver which will take care of setting appropriate voltage. > Any other users apart from cpufreq will have to setup the voltage > appropriately. > > About the ratios, yes the user manual lists the optimal clock > frequency for these clocks. As suggested, I will remove the ratio list > for these clocks. I tried the approach of listing the optimal frequencies of these clocks in dt and then calculating a divider value. But it turns out that the divider values for these clocks is dependent on the frequency of the PLL from which they are derived (or the voltage applied to the CPU clock domain). During tests, the system is unstable if divider values are calculated using the optimal clock speed listed in the SoC manual. So the list of divider values as used in this series (and documented above) is required. Can I continue to use the binding as documented above? Thanks, Thomas. > >> >> How will this scale to multi-cluster chips with different frequency ranges? > > Usually, each cluster would have its own independent clock input. So > there will be two or more cpu clocks in multi-cluster chips. So the > clocks can be independently programmed as required by the cluster. > >> >> Rob &g
Re: [PATCH v2 5/7] clk: exynos: use cpu-clock provider type to represent arm clock
Hi Lukasz,
On Tue, Jan 21, 2014 at 4:08 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> On Mon, Jan 20, 2014 at 1:17 PM, Lukasz Majewski
>> wrote:
>> > Hi Thomas,
>> >
>> >> From: Thomas Abraham
>> >>
>> >> With the addition of the new Samsung specific cpu-clock type, the
>> >> arm clock can be represented as a cpu-clock type and the
>> >> independent clock blocks that made up the arm clock can be removed.
>> >>
>> >> Signed-off-by: Thomas Abraham
>> >> ---
>> >> .../devicetree/bindings/clock/exynos5250-clock.txt |1 +
>> >> drivers/clk/samsung/clk-exynos4.c | 11
>> >> +-- drivers/clk/samsung/clk-exynos5250.c
>> >> |8 include/dt-bindings/clock/exynos5250.h
>> >> |1 + 4 files changed, 11 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git
>> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> >> index 99eae9c..acf867a 100644 ---
>> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++
>> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@
>> >> -38,6 +38,7 @@ clock which they consume.
>> >> fin_pll1
>> >> + armclk 12
>> >>
>> >>[Clock Gate for Special Clocks]
>> >>
>> >> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> >> b/drivers/clk/samsung/clk-exynos4.c index 010f071..efcf4a3 100644
>> >> --- a/drivers/clk/samsung/clk-exynos4.c
>> >> +++ b/drivers/clk/samsung/clk-exynos4.c
>> >> @@ -437,8 +437,6 @@ static struct samsung_mux_clock
>> >> exynos4x12_mux_clks[] __initdata = {
>> >> /* list of divider clocks supported in all exynos4 soc's */
>> >> static struct samsung_div_clock exynos4_div_clks[] __initdata = {
>> >> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
>> >> - DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
>> >> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
>> >> DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
>> >> DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
>> >> @@ -484,8 +482,8 @@ static struct samsung_div_clock
>> >> exynos4_div_clks[] __initdata = { DIV(0, "div_spi_pre2",
>> >> "div_spi2", DIV_PERIL2, 8, 8), DIV(0, "div_audio1", "mout_audio1",
>> >> DIV_PERIL4, 0, 4), DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4,
>> >> 16, 4),
>> >> - DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
>> >> - DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24,
>> >> 3),
>> >> + DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24,
>> >> 3,
>> >> + CLK_GET_RATE_NOCACHE, 0),
>> >> DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
>> >> CLK_SET_RATE_PARENT, 0),
>> >> DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
>> >> @@ -870,7 +868,6 @@ static struct samsung_gate_clock
>> >> exynos4x12_gate_clks[] __initdata = {
>> >> static struct samsung_clock_alias exynos4_aliases[] __initdata = {
>> >> ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
>> >> - ALIAS(CLK_ARM_CLK, NULL, "armclk"),
>> >> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
>> >> };
>> >>
>> >> @@ -1125,12 +1122,14 @@ static void __init exynos4_clk_init(struct
>> >> device_node *np, samsung_clk_register_alias(exynos4_aliases,
>> >> ARRAY_SIZE(exynos4_aliases));
>> >>
>> >> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
>> >> reg_base); +
>> >
>> > I've got some doubts about allowing only the "mout_apll" clock to
>> > be the only parent for armclk Samsung clock.
>> >
>> > For the Exynos4412 it is also valid to have SCLK_MPLL_USER_C [*] as
>> > a parent for this clock.
>> >
>> > The problem is that you are reparenting the armc
Re: [PATCH v2 2/7] clk: samsung: add infrastructure to register cpu clocks
On Tue, Jan 21, 2014 at 3:55 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> Hi Lukasz,
>>
>> On Mon, Jan 20, 2014 at 1:54 PM, Lukasz Majewski
>> wrote:
>> > Hi Thomas,
>> >
>> >> From: Thomas Abraham
>> >>
>> >> The CPU clock provider supplies the clock to the CPU clock domain.
>> >> The composition and organization of the CPU clock provider could
>> >> vary among Exynos SoCs. A CPU clock provider can be composed of
>> >> clock mux, dividers and gates. This patch defines a new clock type
>> >> for CPU clock provider and adds infrastructure to register the CPU
>> >> clock providers for Samsung platforms.
>> >>
>> >> In addition to this, the arm cpu clock provider for Exynos4210 and
>> >> compatible SoCs is instantiated using the new cpu clock type. The
>> >> clock frequency table and the clock configuration data for this
>> >> clock is obtained from device tree. This implementation is
>> >> reusable for Exynos4x12 and Exynos5250 SoCs as well.
>> >>
>> >> Cc: Tomasz Figa
>> >> Cc: Lukasz Majewski
>> >> Signed-off-by: Thomas Abraham
>> >> ---
>> >> drivers/clk/samsung/Makefile |2 +-
>> >> drivers/clk/samsung/clk-cpu.c | 345
>> >> +
>> >> drivers/clk/samsung/clk.h |3 + 3 files changed, 349
>> >> insertions(+), 1 deletions(-) create mode 100644
>> >> drivers/clk/samsung/clk-cpu.c
>> >>
>> >> diff --git a/drivers/clk/samsung/Makefile
>> >> b/drivers/clk/samsung/Makefile index 8eb4799..e2b453f 100644
>> >> --- a/drivers/clk/samsung/Makefile
>> >> +++ b/drivers/clk/samsung/Makefile
>> >> @@ -2,7 +2,7 @@
>> >> # Samsung Clock specific Makefile
>> >> #
>> >>
>> >> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>> >> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>> >> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> >> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>> >> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
>> >> diff --git a/drivers/clk/samsung/clk-cpu.c
>> >> b/drivers/clk/samsung/clk-cpu.c new file mode 100644
>> >> index 000..92fba45
>> >> --- /dev/null
>> >> +++ b/drivers/clk/samsung/clk-cpu.c
>> >> @@ -0,0 +1,345 @@
>> >> +/*
>> >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> >> + * Author: Thomas Abraham
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or
>> >> modify
>> >> + * it under the terms of the GNU General Public License version 2
>> >> as
>> >> + * published by the Free Software Foundation.
>> >> + *
>> >> + * This file contains the utility functions to register the cpu
>> >> clocks
>> >> + * for samsung platforms.
>> >> +*/
>> >> +
>> >> +#include
>> >> +#include "clk.h"
>> >> +
>> >> +#define SRC_CPU 0x0
>> >> +#define STAT_CPU 0x200
>> >> +#define DIV_CPU0 0x300
>> >> +#define DIV_CPU1 0x304
>> >> +#define DIV_STAT_CPU00x400
>> >> +#define DIV_STAT_CPU10x404
>> >> +
>> >> +/**
>> >> + * struct samsung_cpuclk_freq_table: table of frequency supported
>> >> by
>> >> + * a cpu clock and associated data if any.
>> >> + * @freq: points to a table of supported frequencies (in KHz)
>> >> + * @freq_count: number of entries in the frequency table
>> >> + * @data: cpu clock specific data, if any
>> >> + *
>> >> + * This structure holds the frequency options supported by the cpu
>> >> clock in
>> >> + * which this structure is contained. The data pointer is an
>> >> optional data
>> >> + * that can provide any additional configuration options for the
>> >> supported
>> >> + * frequencies. This structure is intended to be reusable for all
>> >> cpu clocks
>> >> + * in Samsung SoC based platforms
>> >> + */
>> >> +struct samsung_cpuclk_freq_table {
>> >> + const unsigned long *freq; /* in KHz */
>> >> + unsigned long freq_count;
Re: [PATCH v2 2/7] clk: samsung: add infrastructure to register cpu clocks
Hi Lukasz,
On Mon, Jan 20, 2014 at 1:54 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> From: Thomas Abraham
>>
>> The CPU clock provider supplies the clock to the CPU clock domain. The
>> composition and organization of the CPU clock provider could vary
>> among Exynos SoCs. A CPU clock provider can be composed of clock mux,
>> dividers and gates. This patch defines a new clock type for CPU clock
>> provider and adds infrastructure to register the CPU clock providers
>> for Samsung platforms.
>>
>> In addition to this, the arm cpu clock provider for Exynos4210 and
>> compatible SoCs is instantiated using the new cpu clock type. The
>> clock frequency table and the clock configuration data for this clock
>> is obtained from device tree. This implementation is reusable for
>> Exynos4x12 and Exynos5250 SoCs as well.
>>
>> Cc: Tomasz Figa
>> Cc: Lukasz Majewski
>> Signed-off-by: Thomas Abraham
>> ---
>> drivers/clk/samsung/Makefile |2 +-
>> drivers/clk/samsung/clk-cpu.c | 345
>> +
>> drivers/clk/samsung/clk.h |3 + 3 files changed, 349
>> insertions(+), 1 deletions(-) create mode 100644
>> drivers/clk/samsung/clk-cpu.c
>>
>> diff --git a/drivers/clk/samsung/Makefile
>> b/drivers/clk/samsung/Makefile index 8eb4799..e2b453f 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -2,7 +2,7 @@
>> # Samsung Clock specific Makefile
>> #
>>
>> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
>> diff --git a/drivers/clk/samsung/clk-cpu.c
>> b/drivers/clk/samsung/clk-cpu.c new file mode 100644
>> index 000..92fba45
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-cpu.c
>> @@ -0,0 +1,345 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * Author: Thomas Abraham
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This file contains the utility functions to register the cpu
>> clocks
>> + * for samsung platforms.
>> +*/
>> +
>> +#include
>> +#include "clk.h"
>> +
>> +#define SRC_CPU 0x0
>> +#define STAT_CPU 0x200
>> +#define DIV_CPU0 0x300
>> +#define DIV_CPU1 0x304
>> +#define DIV_STAT_CPU00x400
>> +#define DIV_STAT_CPU10x404
>> +
>> +/**
>> + * struct samsung_cpuclk_freq_table: table of frequency supported by
>> + * a cpu clock and associated data if any.
>> + * @freq: points to a table of supported frequencies (in KHz)
>> + * @freq_count: number of entries in the frequency table
>> + * @data: cpu clock specific data, if any
>> + *
>> + * This structure holds the frequency options supported by the cpu
>> clock in
>> + * which this structure is contained. The data pointer is an
>> optional data
>> + * that can provide any additional configuration options for the
>> supported
>> + * frequencies. This structure is intended to be reusable for all
>> cpu clocks
>> + * in Samsung SoC based platforms
>> + */
>> +struct samsung_cpuclk_freq_table {
>> + const unsigned long *freq; /* in KHz */
>> + unsigned long freq_count;
>> + const void *data;
>> +};
>> +
>> +/**
>> + * struct exynos4210_freq_data: format of auxillary data associated
>> with
>> + * each frequency supported by the cpu clock for exynos4210.
>> + * @parent_freq: The frequency of the parent clock required to
>> generate the
>> + * supported cpu clock speed.
>> + * @div0: value to be programmed in the div_cpu0 register.
>> + * @div1: value to be programmed in the div_cpu1 register.
>> + *
>> + * This structure holds the auxillary configuration data for each
>> supported
>> + * cpu clock frequency on Exynos4210 and compatible SoCs.
>> + */
>> +struct exynos4210_freq_data {
>> + unsigned long parent_freq;
>> + unsigned intdiv0;
>> + unsigned intdiv1;
>> +};
>> +
>> +/**
>> + * struct samsung_cpuclk: information abo
Re: [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Lukasz, On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski wrote: > Hi Thomas, > >> From: Thomas Abraham >> >> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched >> over to use cpufreq-cpu0 driver for cpufreq functionality. So the >> Exynos specific cpufreq drivers for these platforms can be removed. >> >> Cc: Kukjin Kim >> Cc: Jaecheol Lee >> Signed-off-by: Thomas Abraham >> --- >> drivers/cpufreq/Kconfig.arm | 36 >> drivers/cpufreq/Makefile |4 - >> drivers/cpufreq/exynos-cpufreq.c | 292 >> -- >> drivers/cpufreq/exynos-cpufreq.h | 91 --- >> drivers/cpufreq/exynos4210-cpufreq.c | 157 -- >> drivers/cpufreq/exynos4x12-cpufreq.c | 211 >> drivers/cpufreq/exynos5250-cpufreq.c | 183 - 7 >> files changed, 0 insertions(+), 974 deletions(-) delete mode 100644 >> drivers/cpufreq/exynos-cpufreq.c delete mode 100644 >> drivers/cpufreq/exynos-cpufreq.h delete mode 100644 >> drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 >> drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 >> drivers/cpufreq/exynos5250-cpufreq.c >> >> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm >> index 3129749..704656d 100644 >> --- a/drivers/cpufreq/Kconfig.arm >> +++ b/drivers/cpufreq/Kconfig.arm >> @@ -16,42 +16,6 @@ config ARM_DT_BL_CPUFREQ >> This enables probing via DT for Generic CPUfreq driver for >> ARM big.LITTLE platform. This gets frequency tables from DT. >> >> -config ARM_EXYNOS_CPUFREQ >> - bool >> - >> -config ARM_EXYNOS4210_CPUFREQ >> - bool "SAMSUNG EXYNOS4210" >> - depends on CPU_EXYNOS4210 >> - default y >> - select ARM_EXYNOS_CPUFREQ >> - help >> - This adds the CPUFreq driver for Samsung EXYNOS4210 >> - SoC (S5PV310 or S5PC210). >> - >> - If in doubt, say N. >> - >> -config ARM_EXYNOS4X12_CPUFREQ >> - bool "SAMSUNG EXYNOS4x12" >> - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) >> - default y >> - select ARM_EXYNOS_CPUFREQ >> - help >> - This adds the CPUFreq driver for Samsung EXYNOS4X12 >> - SoC (EXYNOS4212 or EXYNOS4412). >> - >> - If in doubt, say N. >> - >> -config ARM_EXYNOS5250_CPUFREQ >> - bool "SAMSUNG EXYNOS5250" >> - depends on SOC_EXYNOS5250 >> - default y >> - select ARM_EXYNOS_CPUFREQ >> - help >> - This adds the CPUFreq driver for Samsung EXYNOS5250 >> - SoC. >> - >> - If in doubt, say N. >> - >> config ARM_EXYNOS5440_CPUFREQ >> bool "SAMSUNG EXYNOS5440" >> depends on SOC_EXYNOS5440 >> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile >> index 7494565..3abfe05 100644 >> --- a/drivers/cpufreq/Makefile >> +++ b/drivers/cpufreq/Makefile >> @@ -49,10 +49,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)+= >> arm_big_little_dt.o >> obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o >> obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o >> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o >> -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o >> -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o >> -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o >> obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o >> obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o >> obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o >> diff --git a/drivers/cpufreq/exynos-cpufreq.c >> b/drivers/cpufreq/exynos-cpufreq.c deleted file mode 100644 >> index fcd2914..000 >> --- a/drivers/cpufreq/exynos-cpufreq.c >> +++ /dev/null >> @@ -1,292 +0,0 @@ >> -/* >> - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. >> - * http://www.samsung.com >> - * >> - * EXYNOS - CPU frequency scaling support for EXYNOS series >> - * >> - * This program is free software; you can redistribute it and/or >> modify >> - * it under the terms of the GNU General Public License version 2 as >> - * published by the Free Software Foundation. >> -*/ >> - >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> - &
Re: [PATCH v2 5/7] clk: exynos: use cpu-clock provider type to represent arm clock
On Mon, Jan 20, 2014 at 1:17 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> From: Thomas Abraham
>>
>> With the addition of the new Samsung specific cpu-clock type, the
>> arm clock can be represented as a cpu-clock type and the independent
>> clock blocks that made up the arm clock can be removed.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> .../devicetree/bindings/clock/exynos5250-clock.txt |1 +
>> drivers/clk/samsung/clk-exynos4.c | 11 +--
>> drivers/clk/samsung/clk-exynos5250.c |8
>> include/dt-bindings/clock/exynos5250.h |1 +
>> 4 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index
>> 99eae9c..acf867a 100644 ---
>> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++
>> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@
>> -38,6 +38,7 @@ clock which they consume.
>>fin_pll1
>> + armclk 12
>>
>>[Clock Gate for Special Clocks]
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> b/drivers/clk/samsung/clk-exynos4.c index 010f071..efcf4a3 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>> @@ -437,8 +437,6 @@ static struct samsung_mux_clock
>> exynos4x12_mux_clks[] __initdata = {
>> /* list of divider clocks supported in all exynos4 soc's */
>> static struct samsung_div_clock exynos4_div_clks[] __initdata = {
>> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
>> - DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
>> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
>> DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
>> DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
>> @@ -484,8 +482,8 @@ static struct samsung_div_clock
>> exynos4_div_clks[] __initdata = { DIV(0, "div_spi_pre2", "div_spi2",
>> DIV_PERIL2, 8, 8), DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0,
>> 4), DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
>> - DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
>> - DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24,
>> 3),
>> + DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24,
>> 3,
>> + CLK_GET_RATE_NOCACHE, 0),
>> DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
>> CLK_SET_RATE_PARENT, 0),
>> DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
>> @@ -870,7 +868,6 @@ static struct samsung_gate_clock
>> exynos4x12_gate_clks[] __initdata = {
>> static struct samsung_clock_alias exynos4_aliases[] __initdata = {
>> ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
>> - ALIAS(CLK_ARM_CLK, NULL, "armclk"),
>> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
>> };
>>
>> @@ -1125,12 +1122,14 @@ static void __init exynos4_clk_init(struct
>> device_node *np, samsung_clk_register_alias(exynos4_aliases,
>> ARRAY_SIZE(exynos4_aliases));
>>
>> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
>> reg_base); +
>
> I've got some doubts about allowing only the "mout_apll" clock to be the
> only parent for armclk Samsung clock.
>
> For the Exynos4412 it is also valid to have SCLK_MPLL_USER_C [*] as a
> parent for this clock.
>
> The problem is that you are reparenting the armclk to [*] with the
> register modification - no CCF involved.
The MUX_CORE mux is part of the larger cpu clock type and not
registered as a separate mux clock with CCF. So I would like to know
if there are any potential issues you see if this mux clock is
internally managed within the set_rate of the larger cpu clock type.
>
> I just would like to know if this is yours design decision or
> something, that we have overlooked in the v1 of this patch series.
I did overlook this one. This will be fixed in the next version by
ensuring that the dividers for SCLK_HPM clock will be updated only if
mout_apll is the parent of the MUX_HPM clock mux.
Thanks,
Thomas.
>
>> pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
>>
Re: [PATCH v2 4/7] ARM: dts: Exynos: add cpu nodes, opp and cpu clock frequency table
Hi Lukasz,
On Mon, Jan 20, 2014 at 1:02 PM, Lukasz Majewski wrote:
> Hi Thomas,
>
>> From: Thomas Abraham
>>
>> For all Exynos based platforms, add CPU nodes, operating points and
>> cpu clock frequency table for migrating from Exynos specific cpufreq
>> driver to using generic cpufreq-cpu0 driver.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> 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 | 35
>> ++ arch/arm/boot/dts/exynos4212.dtsi
>> | 17 + arch/arm/boot/dts/exynos4412-odroidx.dts|
>> 6 +++ arch/arm/boot/dts/exynos4412-origen.dts |6 +++
>> arch/arm/boot/dts/exynos4412-trats2.dts |6 +++
>> arch/arm/boot/dts/exynos4412.dtsi | 30
>> arch/arm/boot/dts/exynos4x12.dtsi |
>> 35 ++ arch/arm/boot/dts/exynos5250-arndale.dts
>> |6 +++ arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +++
>> arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +++
>> arch/arm/boot/dts/exynos5250.dtsi | 43
>> ++- 14 files changed, 213 insertions(+), 1
>> deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
>> b/arch/arm/boot/dts/exynos4210-origen.dts index 2aa13cb..dd17e93
>> 100644 --- a/arch/arm/boot/dts/exynos4210-origen.dts
>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>> @@ -32,6 +32,12 @@
>> bootargs ="root=/dev/ram0 rw ramdisk=8192
>> initrd=0x4100,8M console=ttySAC2,115200 init=/linuxrc"; };
>>
>> + cpus {
>> + cpu@0 {
>> + cpu0-supply = <&buck1_reg>;
>> + };
>> + };
>> +
>> regulators {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
>> b/arch/arm/boot/dts/exynos4210-trats.dts index 63cc571..25487d7 100644
>> --- a/arch/arm/boot/dts/exynos4210-trats.dts
>> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
>> @@ -30,6 +30,12 @@
>> bootargs = "console=ttySAC2,115200N8
>> root=/dev/mmcblk0p5 rootwait earlyprintk panic=5"; };
>>
>> + cpus {
>> + cpu: cpu@0 {
>> + cpu0-supply = <&varm_breg>;
>> + };
>> + };
>> +
>> regulators {
>> compatible = "simple-bus";
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
>> b/arch/arm/boot/dts/exynos4210-universal_c210.dts index
>> d2e3f5f..74d5a70 100644 ---
>> a/arch/arm/boot/dts/exynos4210-universal_c210.dts +++
>> b/arch/arm/boot/dts/exynos4210-universal_c210.dts @@ -28,6 +28,12 @@
>> bootargs = "console=ttySAC2,115200N8
>> root=/dev/mmcblk0p5 rw rootwait earlyprintk panic=5 maxcpus=1"; };
>>
>> + cpus {
>> + cpu: cpu@0 {
>> + cpu0-supply = <&vdd_arm_reg>;
>> + };
>> + };
>> +
>> mct@1005 {
>> compatible = "none";
>> };
>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
>> b/arch/arm/boot/dts/exynos4210.dtsi index 48ecd7a..40cd663 100644
>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> @@ -36,6 +36,34 @@
>> reg = <0x10023CA0 0x20>;
>> };
>>
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <0>;
>> + clocks = <&clock 12>;
>> + clock-names = "cpu";
>> +
>> + operating-points = <
>> + 20 95
>> + 40 975000
>> + 50 975000
>> + 80 1075000
>> + 100 115
>> + 120 125
>
> Please be consistent with "operating-points" definition. Her
Re: [PATCH v2 3/7] devicetree: bindings: add cpu clock configuration data binding for Exynos4/5
Hi Rob, On Sat, Jan 18, 2014 at 8:52 PM, Rob Herring wrote: > On Sat, Jan 18, 2014 at 6:10 AM, Thomas Abraham wrote: >> From: Thomas Abraham >> >> The clk ops of the new Samsung cpu clock provider type requires configuration >> data that will be programmed in the multiple clock blocks encapsulated within >> the cpu clock provider type. This configuration data is held in the clock >> controller node. Update clock binding documentation about this configuration >> data format for Samsung Exynos4 and Exynos5 platforms. >> >> Cc: Rob Herring > > Please copy all maintainers. Okay. > >> Cc: Tomasz Figa >> Cc: >> Signed-off-by: Thomas Abraham >> --- >> .../devicetree/bindings/clock/exynos4-clock.txt| 30 >> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 21 ++ >> 2 files changed, 51 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> index a2ac2d9..c28aabd 100644 >> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt >> @@ -15,6 +15,29 @@ Required Properties: >> >> - #clock-cells: should be 1. >> >> +- arm-frequency-table: defines the list of arm clock speeds supported and > > Seems like a Samsung specific property and nothing to do with ARM, so > it should be named accordingly. Okay. > >> + the associated configuration values required to setup the clock controller >> + for generating those speeds. The format of each entry included in the >> + arm-frequency-table should be as defined below (#cells per entry = 13) >> + >> + - for Exynos4210 and Exynos4212 based platforms: >> + cell #1: arm clock frequency >> + cell #2: expected arm clock parent frequency >> + cell #3 ~ cell 12#: value of clock divider in the following order >> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, >> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, >> + copy_ratio, hpm_ratio. >> + cell #13: reserved (should be zero). >> + >> + - for Exynos4412 based platforms: >> + cell #1: arm clock frequency >> + cell #2: expected arm clock parent frequency >> + cell #3 ~ cell #13: value of clock divider in the following order >> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, >> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, >> + copy_ratio, hpm_ratio, cores_ratio > > You don't need voltages? Are the h/w limitations really ratios or each > clock has a max frequency that must be maintained? I would expect the > latter and think it would be better to specify maximum frequencies of > each clock. Then you can calculate the dividers to keep frequencies in > range. Voltage is not needed here since the cpu clock speed is managed by the cpufreq driver which will take care of setting appropriate voltage. Any other users apart from cpufreq will have to setup the voltage appropriately. About the ratios, yes the user manual lists the optimal clock frequency for these clocks. As suggested, I will remove the ratio list for these clocks. > > How will this scale to multi-cluster chips with different frequency ranges? Usually, each cluster would have its own independent clock input. So there will be two or more cpu clocks in multi-cluster chips. So the clocks can be independently programmed as required by the cluster. > > Rob > Thanks Rob for your review. Thomas. >> + >> + >> The following is the list of clocks generated by the controller. Each clock >> is >> assigned an identifier and client nodes use this identifier to specify the >> clock which they consume. Some of the clocks are available only on a >> particular >> @@ -275,6 +298,13 @@ Example 1: An example of a clock controller node is >> listed below. >> compatible = "samsung,exynos4210-clock"; >> reg = <0x1003 0x2>; >> #clock-cells = <1>; >> + >> + arm-frequency-table = <120 120 0 3 7 3 4 1 7 0 5 0>, >> + <100 100 0 3 7 3 4 1 7 0 4 0>, >> + < 80 80 0 3 7 3 3 1 7 0 3 0>, >> + < 50 50 0 3 7 3 3 1 7 0 3 0>, >> + < 40 40 0 3 7 3 3 1 7 0
[PATCH v2 3/7] devicetree: bindings: add cpu clock configuration data binding for Exynos4/5
From: Thomas Abraham The clk ops of the new Samsung cpu clock provider type requires configuration data that will be programmed in the multiple clock blocks encapsulated within the cpu clock provider type. This configuration data is held in the clock controller node. Update clock binding documentation about this configuration data format for Samsung Exynos4 and Exynos5 platforms. Cc: Rob Herring Cc: Tomasz Figa Cc: Signed-off-by: Thomas Abraham --- .../devicetree/bindings/clock/exynos4-clock.txt| 30 .../devicetree/bindings/clock/exynos5250-clock.txt | 21 ++ 2 files changed, 51 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index a2ac2d9..c28aabd 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,6 +15,29 @@ Required Properties: - #clock-cells: should be 1. +- arm-frequency-table: defines the list of arm clock speeds supported and + the associated configuration values required to setup the clock controller + for generating those speeds. The format of each entry included in the + arm-frequency-table should be as defined below (#cells per entry = 13) + + - for Exynos4210 and Exynos4212 based platforms: + cell #1: arm clock frequency + cell #2: expected arm clock parent frequency + cell #3 ~ cell 12#: value of clock divider in the following order + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, + copy_ratio, hpm_ratio. + cell #13: reserved (should be zero). + + - for Exynos4412 based platforms: + cell #1: arm clock frequency + cell #2: expected arm clock parent frequency + cell #3 ~ cell #13: value of clock divider in the following order + core_ratio, corem0_ratio, corem1_ratio, periph_ratio, + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio, + copy_ratio, hpm_ratio, cores_ratio + + The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. Some of the clocks are available only on a particular @@ -275,6 +298,13 @@ Example 1: An example of a clock controller node is listed below. compatible = "samsung,exynos4210-clock"; reg = <0x1003 0x2>; #clock-cells = <1>; + + arm-frequency-table = <120 120 0 3 7 3 4 1 7 0 5 0>, + <100 100 0 3 7 3 4 1 7 0 4 0>, + < 80 80 0 3 7 3 3 1 7 0 3 0>, + < 50 50 0 3 7 3 3 1 7 0 3 0>, + < 40 40 0 3 7 3 3 1 7 0 3 0>, + < 20 20 0 1 3 1 1 1 0 0 3 0>; }; Example 2: UART controller node that consumes the clock generated by the clock diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 72ce617..99eae9c 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,6 +13,20 @@ Required Properties: - #clock-cells: should be 1. +- arm-frequency-table: defines the list of arm clock speeds supported and + the associated configuration values required to setup the clock controller + for generating those speeds. The format of each entry included in the + arm-frequency-table should be as defined below (#cells per entry = 13) + + cell #1: arm clock frequency + cell #2: expected arm clock parent frequency + cell #3 ~ cell #12: value of clock divider in the following order + arm_ratio, cpud_ratio, acp_ratio, periph_ratio, + atb_ratio, pclk_dbg_ratio, apll_ratio, arm2_ratio, + copy_ratio, hpm_ratio + cell #13: reserved (should be zero) + + The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. @@ -177,6 +191,13 @@ Example 1: An example of a clock controller node is listed below. compatible = "samsung,exynos5250-clock"; reg = <0x1001 0x3>; #clock-cells = <1>; + + arm-frequency-table = <170 170 0 3 7 7 7 3 5 0 0 2>, + <160 160 0 3 7 7 7 1 4 0 0 2>, + <150 150 0 2 7 7 7 1 4 0 0 2>, +
