cpufreq: use generic cpufreq drivers for exynos platforms
Subsystems (7)
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Changes since v8:
- Fixes suggested by Tomasz Figa.
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 enables cpufreq support for Exynos5420 using arm_big_little cpufreq driver.
This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicate div_core2 divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.html
Thomas Abraham (6):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: add cpu clock configuration data and instantiate cpu clock
ARM: dts: Exynos: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
clk: samsung: remove unused clock aliases and update clock flags
arch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- arch/arm/boot/dts/exynos5250-arndale.dts | 4 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 + arch/arm/boot/dts/exynos5250-snow.dts | 4 + arch/arm/boot/dts/exynos5250.dtsi | 25 +- arch/arm/boot/dts/exynos5420.dtsi | 38 +++ arch/arm/mach-exynos/exynos.c | 24 +- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 ++++++ drivers/clk/samsung/clk-exynos4.c | 63 +++-- drivers/clk/samsung/clk-exynos5250.c | 44 ++- drivers/clk/samsung/clk-exynos5420.c | 72 ++++- 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 + 22 files changed, 690 insertions(+), 463 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
Signature · 1 line
1.7.9.5
PATCH v9 1/6 clk: samsung: add infrastructure to register cpu clocks
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.
--- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 +++++++++++ 3 files changed, 427 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h
drivers/clk/samsung/Makefile +1 -1
@@ -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
drivers/clk/samsung/clk-cpu.c new file +335 -0
335 lines not on this page · raw message
drivers/clk/samsung/clk-cpu.h new file +91 -0
91 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH v9 1/6 clk: samsung: add infrastructure to register cpu clocks
Quoting Thomas Abraham (2014-07-30 01:07:38)
Quoted 9 lines
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.
Signed-off-by Thomas Abraham <[email protected]>Reviewed-by Tomasz Figa <[email protected]>
Quoted 462 lines
--- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 +++++++++++ 3 files changed, 427 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.hdrivers/clk/samsung/Makefile +1
-1@@ -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.odrivers/clk/samsung/clk-cpu.c new file +335
-0@@ -0,0 +1,335 @@ +/* +* Copyright (c) 2014 Samsung Electronics Co., Ltd. +* Author: Thomas Abraham <[email protected]> +* +* 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 function to register CPU clock for Samsung +* Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or a +* group of CPUs. The CPU clock is typically derived from a hierarchy of clock +* blocks which includes mux and divider blocks. There are a number of other +* auxiliary clocks supplied to the CPU domain such as the debug blocks and AXI +* clock for CPU domain. The rates of these auxiliary clocks are related to the +* CPU clock rate and this relation is usually specified in the hardware manual +* of the SoC or supplied after the SoC characterization. +* +* The below implementation of the CPU clock allows the rate changes of the CPU +* clock and the corresponding rate changes of the auxillary clocks of the CPU +* domain. The platform clock driver provides a clock register configuration +* for each configurable rate which is then used to program the clock hardware +* registers to acheive a fast co-oridinated rate change for all the CPU domain +* clocks. +* +* On a rate change request for the CPU clock, the rate change is propagated +* upto the PLL supplying the clock to the CPU domain clock blocks. While the +* CPU domain PLL is reconfigured, the CPU domain clocks are driven using an +* alternate clock source. If required, the alternate clock source is divided +* down in order to keep the output clock rate within the previous OPP limits. +*/ + +#include <linux/errno.h> +#include "clk-cpu.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_CPU0 0x400 +#define E4210_DIV_STAT_CPU1 0x404 + +#define E4210_DIV0_RATIO0_MASK 0x7 +#define E4210_DIV1_HPM_MASK (0x7 << 4) +#define E4210_DIV1_COPY_MASK (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 MAX_DIV 8 +#define DIV_MASK 7 +#define DIV_MASK_ALL 0xffffffff +#define MUX_MASK 7 + +/* +* Helper function to wait until divider(s) have stabilized after the divider +* value has changed. +*/ +static void wait_until_divider_stable (void __iomem *div_reg,unsigned long mask) +{ +unsigned long timeout = jiffies +msecs_to_jiffies (10 ); + +do { +if (!(readl (div_reg) & mask)) +return ; + }while (time_before (jiffies, timeout)); + +pr_err ("%s: timeout in divider stablization\n" , __func__); +} + +/* +* Helper function to wait until mux has stabilized after the mux selection +* value was changed. +*/ +static void wait_until_mux_stable (void __iomem *mux_reg,u32 mux_pos, +unsigned long mux_value) +{ +unsigned long timeout = jiffies +msecs_to_jiffies (10 ); + +do { +if (((readl (mux_reg) >> mux_pos) &MUX_MASK ) == mux_value) +return ; + }while (time_before (jiffies, timeout)); + +pr_err ("%s: re-parenting mux timed-out\n" , __func__); +} + +/* common round rate callback useable for all types of CPU clocks */ +static long exynos_cpuclk_round_rate (struct clk_hw *hw, +unsigned long drate,unsigned long *prate) +{ +struct clk *parent =__clk_get_parent (hw->clk); + *prate =__clk_round_rate (parent, drate); +return *prate; +} + +/* common recalc rate callback useable for all types of CPU clocks */ +static unsigned long exynos_cpuclk_recalc_rate (struct clk_hw *hw, +unsigned long parent_rate) +{ +/* +* The CPU clock output (armclk) rate is the same as its parent +* rate. Although there exist certain dividers inside the CPU +* clock block that could be used to divide the parent clock, +* the driver does not make use of them currently, except during +* frequency transitions. +*/ +return parent_rate; +} + +static const struct clk_ops exynos_cpuclk_clk_ops = { + .recalc_rate = exynos_cpuclk_recalc_rate, + .round_rate = exynos_cpuclk_round_rate, +}; + +/* +* Helper function to set the 'safe' dividers for the CPU clock. The parameters +* div and mask contain the divider value and the register bit mask of the +* dividers to be programmed. +*/ +static void exynos_set_safe_div (void __iomem *base,unsigned long div, +unsigned long mask) +{ +unsigned long div0; + + div0 =readl (base +E4210_DIV_CPU0 ); + div0 = (div0 & ~mask) | (div & mask); +writel (div0, base +E4210_DIV_CPU0 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU0 , mask); +} + +/* handler for pre-rate change notification from parent clock */ +static int exynos_cpuclk_pre_rate_change (struct clk_notifier_data *ndata, +struct exynos_cpuclk *cpuclk,void __iomem *base) +{ +const struct exynos_cpuclk_cfg_data *cfg_data = cpuclk->cfg; +unsigned long alt_prate =clk_get_rate (cpuclk->alt_parent); +unsigned long alt_div =0 , alt_div_mask =DIV_MASK ; +unsigned long div0, div1 =0 , mux_reg; + +/* find out the divider values to use for clock data */ +while ((cfg_data->prate *1000 ) != ndata->new_rate) { +if (cfg_data->prate ==0 ) +return -EINVAL ; + cfg_data++; + } + +/* +* For the selected PLL clock frequency, get the pre-defined divider +* values. If the clock for sclk_hpm is not sourced from apll, then +* the values for DIV_COPY and DIV_HPM dividers need not be set. +*/ + div0 = cfg_data->div0; +if (test_bit (CLK_CPU_HAS_DIV1 , &cpuclk->flags)) { + div1 = cfg_data->div1; +if (readl (base +E4210_SRC_CPU ) &E4210_MUX_HPM_MASK ) + div1 =readl (base +E4210_DIV_CPU1 ) & + (E4210_DIV1_HPM_MASK |E4210_DIV1_COPY_MASK ); + } + +spin_lock (cpuclk->lock); + +/* +* 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. +*/ +if (alt_prate > ndata->old_rate) { + alt_div =DIV_ROUND_UP (alt_prate, ndata->old_rate) -1 ; +WARN_ON (alt_div >=MAX_DIV ); + +if (test_bit (CLK_CPU_NEEDS_DEBUG_ALT_DIV , &cpuclk->flags)) { +/* +* In Exynos4210, ATB clock parent is also mout_core. So +* ATB clock also needs to be mantained at safe speed. +*/ + alt_div |=E4210_DIV0_ATB_MASK ; + alt_div_mask |=E4210_DIV0_ATB_MASK ; + } +exynos_set_safe_div (base, alt_div, alt_div_mask); + div0 |= alt_div; + } + +/* select sclk_mpll as the alternate parent */ + mux_reg =readl (base +E4210_SRC_CPU ); +writel (mux_reg | (1 <<16 ), base +E4210_SRC_CPU ); +wait_until_mux_stable (base +E4210_STAT_CPU ,16 ,2 ); + +/* alternate parent is active now. set the dividers */ +writel (div0, base +E4210_DIV_CPU0 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU0 ,DIV_MASK_ALL ); + +if (test_bit (CLK_CPU_HAS_DIV1 , &cpuclk->flags)) { +writel (div1, base +E4210_DIV_CPU1 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU1 , +DIV_MASK_ALL ); + } + +spin_unlock (cpuclk->lock); +return 0 ; +} + +/* handler for post-rate change notification from parent clock */ +static int exynos_cpuclk_post_rate_change (struct clk_notifier_data *ndata, +struct exynos_cpuclk *cpuclk,void __iomem *base) +{ +const struct exynos_cpuclk_cfg_data *cfg_data = cpuclk->cfg; +unsigned long div =0 , div_mask =DIV_MASK ; +unsigned long mux_reg; + +spin_lock (cpuclk->lock); + +/* select mout_apll as the alternate parent */ + mux_reg =readl (base +E4210_SRC_CPU ); +writel (mux_reg & ~(1 <<16 ), base +E4210_SRC_CPU ); +wait_until_mux_stable (base +E4210_STAT_CPU ,16 ,1 ); + +if (test_bit (CLK_CPU_NEEDS_DEBUG_ALT_DIV , &cpuclk->flags)) { +/* find out the divider values to use for clock data */ +while ((cfg_data->prate *1000 ) != ndata->new_rate) { +if (cfg_data->prate ==0 ) +return -EINVAL ; + cfg_data++; + } + + div |= (cfg_data->div0 &E4210_DIV0_ATB_MASK ); + div_mask |=E4210_DIV0_ATB_MASK ; + } + +exynos_set_safe_div (base, div, div_mask); +spin_unlock (cpuclk->lock); +return 0 ; +} + +/* +* This notifier function is called for the pre-rate and post-rate change +* notifications of the parent clock of cpuclk. +*/ +static int exynos_cpuclk_notifier_cb (struct notifier_block *nb, +unsigned long event,void *data) +{ +struct clk_notifier_data *ndata = data; +struct exynos_cpuclk *cpuclk; +void __iomem *base; +int err =0 ; + + cpuclk = container_of(nb, struct exynos_cpuclk, clk_nb); + base = cpuclk->ctrl_base; + +if (event ==PRE_RATE_CHANGE ) + err =exynos_cpuclk_pre_rate_change (ndata, cpuclk, base); +else if (event ==POST_RATE_CHANGE ) + err =exynos_cpuclk_post_rate_change (ndata, cpuclk, base); + +return notifier_from_errno (err); +} + +/* helper function to register a CPU clock */ +int __init exynos_register_cpu_clock (struct samsung_clk_provider *ctx, +unsigned int lookup_id,const char *name,const char *parent, +const char *alt_parent,unsigned long offset, +const struct exynos_cpuclk_cfg_data *cfg, +unsigned long num_cfgs,unsigned long flags) +{ +struct exynos_cpuclk *cpuclk; +struct clk_init_data init; +struct clk *clk; +int ret =0 ; + + cpuclk =kzalloc (sizeof (*cpuclk),GFP_KERNEL ); +if (!cpuclk) +return -ENOMEM ; + + init.name = name; + init.flags =CLK_SET_RATE_PARENT ; + init.parent_names = &parent; + init.num_parents =1 ; + init.ops = &exynos_cpuclk_clk_ops; + + cpuclk->hw.init = &init; + cpuclk->ctrl_base = ctx->reg_base + offset; + cpuclk->lock = &ctx->lock; + cpuclk->flags = flags; + cpuclk->clk_nb.notifier_call = exynos_cpuclk_notifier_cb; + + cpuclk->alt_parent =__clk_lookup (alt_parent); +if (!cpuclk->alt_parent) { +pr_err ("%s: could not lookup alternate parent %s\n" , + __func__, alt_parent); + ret = -EINVAL ; + goto free_cpuclk; + } + + clk =__clk_lookup (parent); +if (!clk) { +pr_err ("%s: could not lookup parent clock %s\n" , + __func__, parent); + ret = -EINVAL ; + goto free_cpuclk; + } + + ret =clk_notifier_register (clk, &cpuclk->clk_nb); +if (ret) { +pr_err ("%s: failed to register clock notifier for %s\n" , + __func__, name); + goto free_cpuclk; + } + + cpuclk->cfg =kmemdup (cfg,sizeof (*cfg) * num_cfgs,GFP_KERNEL ); +if (!cpuclk->cfg) { +pr_err ("%s: could not allocate memory for cpuclk data\n" , + __func__); +kfree (cpuclk); + ret = -ENOMEM ; + goto unregister_clk_nb; + } + + clk =clk_register (NULL , &cpuclk->hw); +if (IS_ERR (clk)) { +pr_err ("%s: could not register cpuclk %s\n" , __func__, name); + ret =PTR_ERR (clk); + goto free_cpuclk_data; + } + +samsung_clk_add_lookup (ctx, clk, lookup_id); +return 0 ; + +free_cpuclk_data: +kfree (cpuclk->cfg); +unregister_clk_nb: +clk_notifier_unregister (__clk_lookup (parent), &cpuclk->clk_nb); +free_cpuclk: +kfree (cpuclk); +return ret; +}drivers/clk/samsung/clk-cpu.h new file +91
-0@@ -0,0 +1,91 @@ +/* +* Copyright (c) 2014 Samsung Electronics Co., Ltd. +* +* 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. +* +* Common Clock Framework support for all PLL's in Samsung platforms +*/ + +#ifndef __SAMSUNG_CLK_CPU_H +#define __SAMSUNG_CLK_CPU_H + +#include "clk.h" + +#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))) + +/** +* struct exynos_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 +* value is not used. +*/ +struct exynos_cpuclk_cfg_data { +unsigned long prate; +unsigned long div0; +unsigned long div1; +}; + +/** +* 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. +* @lock: cpu clock domain register access lock. +* @cfg: cpu clock rate configuration data. +* @num_cfgs: number of array elements in @cfg array. +* @clk_nb: clock notifier registered for changes in clock speed of the +* primary parent clock. +* @flags: configuration flags for the CPU clock. +* +* This structure holds information required for programming the CPU clock for +* various clock speeds. +*/ +struct exynos_cpuclk { +struct clk_hw hw; +struct clk *alt_parent; +void __iomem *ctrl_base; +spinlock_t *lock; +const struct exynos_cpuclk_cfg_data *cfg; +const unsigned long num_cfgs; +struct notifier_block clk_nb; +unsigned long flags; + +/* The CPU clock registers has DIV1 configuration register */ +#define CLK_CPU_HAS_DIV1 (1 << 0) +/* When ALT parent is active, debug clocks need safe divider values */ +#define CLK_CPU_NEEDS_DEBUG_ALT_DIV (1 << 1) +}; + +extern int __init exynos_register_cpu_clock (struct samsung_clk_provider *ctx, +unsigned int lookup_id,const char *name, +const char *parent,const char *alt_parent, +unsigned long offset, +const struct exynos_cpuclk_cfg_data *cfg, +unsigned long num_cfgs,unsigned long flags); + +#endif /* __SAMSUNG_CLK_CPU_H */ Signature · 1 line
1.7.9.5
PATCH v9 1/6 clk: samsung: add infrastructure to register cpu clocks
Quoted 8 lines · Mike Turquette
Quoting Thomas Abraham (2014-07-30 01:07:38)
Quoted 7 lines
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.
Quoted 4 lines
Quoted 2 lines
Signed-off-by Thomas Abraham <[email protected]>Reviewed-by Tomasz Figa <[email protected]>Acked-by Mike Turquette <[email protected]>
Thank you Mike.
Regards,
Thomas.
Quoted 467 lines
Quoted 461 lines
--- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 +++++++++++ 3 files changed, 427 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.hdrivers/clk/samsung/Makefile +1
-1@@ -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.odrivers/clk/samsung/clk-cpu.c new file +335
-0@@ -0,0 +1,335 @@ +/* +* Copyright (c) 2014 Samsung Electronics Co., Ltd. +* Author: Thomas Abraham <[email protected]> +* +* 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 function to register CPU clock for Samsung +* Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or a +* group of CPUs. The CPU clock is typically derived from a hierarchy of clock +* blocks which includes mux and divider blocks. There are a number of other +* auxiliary clocks supplied to the CPU domain such as the debug blocks and AXI +* clock for CPU domain. The rates of these auxiliary clocks are related to the +* CPU clock rate and this relation is usually specified in the hardware manual +* of the SoC or supplied after the SoC characterization. +* +* The below implementation of the CPU clock allows the rate changes of the CPU +* clock and the corresponding rate changes of the auxillary clocks of the CPU +* domain. The platform clock driver provides a clock register configuration +* for each configurable rate which is then used to program the clock hardware +* registers to acheive a fast co-oridinated rate change for all the CPU domain +* clocks. +* +* On a rate change request for the CPU clock, the rate change is propagated +* upto the PLL supplying the clock to the CPU domain clock blocks. While the +* CPU domain PLL is reconfigured, the CPU domain clocks are driven using an +* alternate clock source. If required, the alternate clock source is divided +* down in order to keep the output clock rate within the previous OPP limits. +*/ + +#include <linux/errno.h> +#include "clk-cpu.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_CPU0 0x400 +#define E4210_DIV_STAT_CPU1 0x404 + +#define E4210_DIV0_RATIO0_MASK 0x7 +#define E4210_DIV1_HPM_MASK (0x7 << 4) +#define E4210_DIV1_COPY_MASK (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 MAX_DIV 8 +#define DIV_MASK 7 +#define DIV_MASK_ALL 0xffffffff +#define MUX_MASK 7 + +/* +* Helper function to wait until divider(s) have stabilized after the divider +* value has changed. +*/ +static void wait_until_divider_stable (void __iomem *div_reg,unsigned long mask) +{ +unsigned long timeout = jiffies +msecs_to_jiffies (10 ); + +do { +if (!(readl (div_reg) & mask)) +return ; + }while (time_before (jiffies, timeout)); + +pr_err ("%s: timeout in divider stablization\n" , __func__); +} + +/* +* Helper function to wait until mux has stabilized after the mux selection +* value was changed. +*/ +static void wait_until_mux_stable (void __iomem *mux_reg,u32 mux_pos, +unsigned long mux_value) +{ +unsigned long timeout = jiffies +msecs_to_jiffies (10 ); + +do { +if (((readl (mux_reg) >> mux_pos) &MUX_MASK ) == mux_value) +return ; + }while (time_before (jiffies, timeout)); + +pr_err ("%s: re-parenting mux timed-out\n" , __func__); +} + +/* common round rate callback useable for all types of CPU clocks */ +static long exynos_cpuclk_round_rate (struct clk_hw *hw, +unsigned long drate,unsigned long *prate) +{ +struct clk *parent =__clk_get_parent (hw->clk); + *prate =__clk_round_rate (parent, drate); +return *prate; +} + +/* common recalc rate callback useable for all types of CPU clocks */ +static unsigned long exynos_cpuclk_recalc_rate (struct clk_hw *hw, +unsigned long parent_rate) +{ +/* +* The CPU clock output (armclk) rate is the same as its parent +* rate. Although there exist certain dividers inside the CPU +* clock block that could be used to divide the parent clock, +* the driver does not make use of them currently, except during +* frequency transitions. +*/ +return parent_rate; +} + +static const struct clk_ops exynos_cpuclk_clk_ops = { + .recalc_rate = exynos_cpuclk_recalc_rate, + .round_rate = exynos_cpuclk_round_rate, +}; + +/* +* Helper function to set the 'safe' dividers for the CPU clock. The parameters +* div and mask contain the divider value and the register bit mask of the +* dividers to be programmed. +*/ +static void exynos_set_safe_div (void __iomem *base,unsigned long div, +unsigned long mask) +{ +unsigned long div0; + + div0 =readl (base +E4210_DIV_CPU0 ); + div0 = (div0 & ~mask) | (div & mask); +writel (div0, base +E4210_DIV_CPU0 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU0 , mask); +} + +/* handler for pre-rate change notification from parent clock */ +static int exynos_cpuclk_pre_rate_change (struct clk_notifier_data *ndata, +struct exynos_cpuclk *cpuclk,void __iomem *base) +{ +const struct exynos_cpuclk_cfg_data *cfg_data = cpuclk->cfg; +unsigned long alt_prate =clk_get_rate (cpuclk->alt_parent); +unsigned long alt_div =0 , alt_div_mask =DIV_MASK ; +unsigned long div0, div1 =0 , mux_reg; + +/* find out the divider values to use for clock data */ +while ((cfg_data->prate *1000 ) != ndata->new_rate) { +if (cfg_data->prate ==0 ) +return -EINVAL ; + cfg_data++; + } + +/* +* For the selected PLL clock frequency, get the pre-defined divider +* values. If the clock for sclk_hpm is not sourced from apll, then +* the values for DIV_COPY and DIV_HPM dividers need not be set. +*/ + div0 = cfg_data->div0; +if (test_bit (CLK_CPU_HAS_DIV1 , &cpuclk->flags)) { + div1 = cfg_data->div1; +if (readl (base +E4210_SRC_CPU ) &E4210_MUX_HPM_MASK ) + div1 =readl (base +E4210_DIV_CPU1 ) & + (E4210_DIV1_HPM_MASK |E4210_DIV1_COPY_MASK ); + } + +spin_lock (cpuclk->lock); + +/* +* 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. +*/ +if (alt_prate > ndata->old_rate) { + alt_div =DIV_ROUND_UP (alt_prate, ndata->old_rate) -1 ; +WARN_ON (alt_div >=MAX_DIV ); + +if (test_bit (CLK_CPU_NEEDS_DEBUG_ALT_DIV , &cpuclk->flags)) { +/* +* In Exynos4210, ATB clock parent is also mout_core. So +* ATB clock also needs to be mantained at safe speed. +*/ + alt_div |=E4210_DIV0_ATB_MASK ; + alt_div_mask |=E4210_DIV0_ATB_MASK ; + } +exynos_set_safe_div (base, alt_div, alt_div_mask); + div0 |= alt_div; + } + +/* select sclk_mpll as the alternate parent */ + mux_reg =readl (base +E4210_SRC_CPU ); +writel (mux_reg | (1 <<16 ), base +E4210_SRC_CPU ); +wait_until_mux_stable (base +E4210_STAT_CPU ,16 ,2 ); + +/* alternate parent is active now. set the dividers */ +writel (div0, base +E4210_DIV_CPU0 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU0 ,DIV_MASK_ALL ); + +if (test_bit (CLK_CPU_HAS_DIV1 , &cpuclk->flags)) { +writel (div1, base +E4210_DIV_CPU1 ); +wait_until_divider_stable (base +E4210_DIV_STAT_CPU1 , +DIV_MASK_ALL ); + } + +spin_unlock (cpuclk->lock); +return 0 ; +} + +/* handler for post-rate change notification from parent clock */ +static int exynos_cpuclk_post_rate_change (struct clk_notifier_data *ndata, +struct exynos_cpuclk *cpuclk,void __iomem *base) +{ +const struct exynos_cpuclk_cfg_data *cfg_data = cpuclk->cfg; +unsigned long div =0 , div_mask =DIV_MASK ; +unsigned long mux_reg; + +spin_lock (cpuclk->lock); + +/* select mout_apll as the alternate parent */ + mux_reg =readl (base +E4210_SRC_CPU ); +writel (mux_reg & ~(1 <<16 ), base +E4210_SRC_CPU ); +wait_until_mux_stable (base +E4210_STAT_CPU ,16 ,1 ); + +if (test_bit (CLK_CPU_NEEDS_DEBUG_ALT_DIV , &cpuclk->flags)) { +/* find out the divider values to use for clock data */ +while ((cfg_data->prate *1000 ) != ndata->new_rate) { +if (cfg_data->prate ==0 ) +return -EINVAL ; + cfg_data++; + } + + div |= (cfg_data->div0 &E4210_DIV0_ATB_MASK ); + div_mask |=E4210_DIV0_ATB_MASK ; + } + +exynos_set_safe_div (base, div, div_mask); +spin_unlock (cpuclk->lock); +return 0 ; +} + +/* +* This notifier function is called for the pre-rate and post-rate change +* notifications of the parent clock of cpuclk. +*/ +static int exynos_cpuclk_notifier_cb (struct notifier_block *nb, +unsigned long event,void *data) +{ +struct clk_notifier_data *ndata = data; +struct exynos_cpuclk *cpuclk; +void __iomem *base; +int err =0 ; + + cpuclk = container_of(nb, struct exynos_cpuclk, clk_nb); + base = cpuclk->ctrl_base; + +if (event ==PRE_RATE_CHANGE ) + err =exynos_cpuclk_pre_rate_change (ndata, cpuclk, base); +else if (event ==POST_RATE_CHANGE ) + err =exynos_cpuclk_post_rate_change (ndata, cpuclk, base); + +return notifier_from_errno (err); +} + +/* helper function to register a CPU clock */ +int __init exynos_register_cpu_clock (struct samsung_clk_provider *ctx, +unsigned int lookup_id,const char *name,const char *parent, +const char *alt_parent,unsigned long offset, +const struct exynos_cpuclk_cfg_data *cfg, +unsigned long num_cfgs,unsigned long flags) +{ +struct exynos_cpuclk *cpuclk; +struct clk_init_data init; +struct clk *clk; +int ret =0 ; + + cpuclk =kzalloc (sizeof (*cpuclk),GFP_KERNEL ); +if (!cpuclk) +return -ENOMEM ; + + init.name = name; + init.flags =CLK_SET_RATE_PARENT ; + init.parent_names = &parent; + init.num_parents =1 ; + init.ops = &exynos_cpuclk_clk_ops; + + cpuclk->hw.init = &init; + cpuclk->ctrl_base = ctx->reg_base + offset; + cpuclk->lock = &ctx->lock; + cpuclk->flags = flags; + cpuclk->clk_nb.notifier_call = exynos_cpuclk_notifier_cb; + + cpuclk->alt_parent =__clk_lookup (alt_parent); +if (!cpuclk->alt_parent) { +pr_err ("%s: could not lookup alternate parent %s\n" , + __func__, alt_parent); + ret = -EINVAL ; + goto free_cpuclk; + } + + clk =__clk_lookup (parent); +if (!clk) { +pr_err ("%s: could not lookup parent clock %s\n" , + __func__, parent); + ret = -EINVAL ; + goto free_cpuclk; + } + + ret =clk_notifier_register (clk, &cpuclk->clk_nb); +if (ret) { +pr_err ("%s: failed to register clock notifier for %s\n" , + __func__, name); + goto free_cpuclk; + } + + cpuclk->cfg =kmemdup (cfg,sizeof (*cfg) * num_cfgs,GFP_KERNEL ); +if (!cpuclk->cfg) { +pr_err ("%s: could not allocate memory for cpuclk data\n" , + __func__); +kfree (cpuclk); + ret = -ENOMEM ; + goto unregister_clk_nb; + } + + clk =clk_register (NULL , &cpuclk->hw); +if (IS_ERR (clk)) { +pr_err ("%s: could not register cpuclk %s\n" , __func__, name); + ret =PTR_ERR (clk); + goto free_cpuclk_data; + } + +samsung_clk_add_lookup (ctx, clk, lookup_id); +return 0 ; + +free_cpuclk_data: +kfree (cpuclk->cfg); +unregister_clk_nb: +clk_notifier_unregister (__clk_lookup (parent), &cpuclk->clk_nb); +free_cpuclk: +kfree (cpuclk); +return ret; +}drivers/clk/samsung/clk-cpu.h new file +91
-1@@ -0,0 +1,91 @@ +/* +* Copyright (c) 2014 Samsung Electronics Co., Ltd. +* +* 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. +* +* Common Clock Framework support for all PLL's in Samsung platforms +*/ + +#ifndef __SAMSUNG_CLK_CPU_H +#define __SAMSUNG_CLK_CPU_H + +#include "clk.h" + +#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))) + +/** +* struct exynos_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 +* value is not used. +*/ +struct exynos_cpuclk_cfg_data { +unsigned long prate; +unsigned long div0; +unsigned long div1; +}; + +/** +* 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. +* @lock: cpu clock domain register access lock. +* @cfg: cpu clock rate configuration data. +* @num_cfgs: number of array elements in @cfg array. +* @clk_nb: clock notifier registered for changes in clock speed of the +* primary parent clock. +* @flags: configuration flags for the CPU clock. +* +* This structure holds information required for programming the CPU clock for +* various clock speeds. +*/ +struct exynos_cpuclk { +struct clk_hw hw; +struct clk *alt_parent; +void __iomem *ctrl_base; +spinlock_t *lock; +const struct exynos_cpuclk_cfg_data *cfg; +const unsigned long num_cfgs; +struct notifier_block clk_nb; +unsigned long flags; + +/* The CPU clock registers has DIV1 configuration register */ +#define CLK_CPU_HAS_DIV1 (1 << 0) +/* When ALT parent is active, debug clocks need safe divider values */ +#define CLK_CPU_NEEDS_DEBUG_ALT_DIV (1 << 1) +}; + +extern int __init exynos_register_cpu_clock (struct samsung_clk_provider *ctx, +unsigned int lookup_id,const char *name, +const char *parent,const char *alt_parent, +unsigned long offset, +const struct exynos_cpuclk_cfg_data *cfg, +unsigned long num_cfgs,unsigned long flags); + +#endif /* __SAMSUNG_CLK_CPU_H */ --Quoted 2 lines
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v9 2/6 clk: samsung: add cpu clock configuration data and instantiate cpu clock
In reply to Thomas AbrahamWith the addition of the new Samsung specific cpu-clock type, the arm clock can be represented as a cpu-clock type. Add the CPU clock configuration data and instantiate the CPU clock type for Exynos4210, Exynos5250 and Exynos5420.
--- drivers/clk/samsung/clk-exynos4.c | 15 +++++++++++ drivers/clk/samsung/clk-exynos5250.c | 25 ++++++++++++++++++ drivers/clk/samsung/clk-exynos5420.c | 45 ++++++++++++++++++++++++++++++++ include/dt-bindings/clock/exynos5250.h | 1 + include/dt-bindings/clock/exynos5420.h | 2 ++ 5 files changed, 88 insertions(+)
drivers/clk/samsung/clk-exynos4.c +15 -0
@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" /* Exynos4 clock controller register offsets */ #define SRC_LEFTBUS 0x4200
@@ -1355,6 +1356,16 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] __initdata = { VPLL_LOCK, VPLL_CON0, NULL), }; +static const struct exynos_cpuclk_cfg_data e4210_armclk_d[]__initconst = { + {1200000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,5 ), }, + {1000000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,4 ), }, + {800000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {500000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {400000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {200000 ,E4210_CPU_DIV0 (0 ,1 ,1 ,1 ,3 ,1 ),E4210_CPU_DIV1 (0 ,3 ), }, + {0 }, +}; +static void __init exynos4_core_down_clock (enum exynos4_soc soc) {unsigned int tmp;
@@ -1458,6 +1469,10 @@ static void __init exynos4_clk_init(struct device_node *np,samsung_clk_register_fixed_factor (ctx, exynos4210_fixed_factor_clks,ARRAY_SIZE (exynos4210_fixed_factor_clks)); +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_core_p4210[0 ], mout_core_p4210[1 ],0x14200 , + e4210_armclk_d,ARRAY_SIZE (e4210_armclk_d), +CLK_CPU_NEEDS_DEBUG_ALT_DIV |CLK_CPU_HAS_DIV1 ); }else {samsung_clk_register_mux (ctx, exynos4x12_mux_clks,ARRAY_SIZE (exynos4x12_mux_clks));
drivers/clk/samsung/clk-exynos5250.c +25 -0
@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" #define APLL_LOCK 0x0#define APLL_CON0 0x100
@@ -748,6 +749,26 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls] __initdata = { VPLL_LOCK, VPLL_CON0, NULL), }; +static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[]__initconst = { + {1700000 ,E5250_CPU_DIV0 (5 ,3 ,7 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1600000 ,E5250_CPU_DIV0 (4 ,1 ,7 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1500000 ,E5250_CPU_DIV0 (4 ,1 ,7 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1400000 ,E5250_CPU_DIV0 (4 ,1 ,6 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1300000 ,E5250_CPU_DIV0 (3 ,1 ,6 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1200000 ,E5250_CPU_DIV0 (3 ,1 ,5 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1100000 ,E5250_CPU_DIV0 (3 ,1 ,5 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1000000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {900000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {800000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {700000 ,E5250_CPU_DIV0 (1 ,1 ,3 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {600000 ,E5250_CPU_DIV0 (1 ,1 ,3 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {500000 ,E5250_CPU_DIV0 (1 ,1 ,2 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {400000 ,E5250_CPU_DIV0 (1 ,1 ,2 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {300000 ,E5250_CPU_DIV0 (1 ,1 ,1 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {200000 ,E5250_CPU_DIV0 (1 ,1 ,1 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {0 }, +}; +static const struct of_device_id ext_clk_match[]__initconst = { { .compatible ="samsung,clock-xxti" , .data = (void *)0 , }, { },
@@ -797,6 +818,10 @@ static void __init exynos5250_clk_init(struct device_node *np) ARRAY_SIZE(exynos5250_div_clks));samsung_clk_register_gate (ctx, exynos5250_gate_clks,ARRAY_SIZE (exynos5250_gate_clks)); +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_cpu_p[0 ], mout_cpu_p[1 ],0x200 , + exynos5250_armclk_d,ARRAY_SIZE (exynos5250_armclk_d), +CLK_CPU_HAS_DIV1 );/* * Enable arm clock down (in idle) and set arm divider
drivers/clk/samsung/clk-exynos5420.c +45 -0
63 lines not on this page · raw message
include/dt-bindings/clock/exynos5250.h +1 -0
@@ -21,6 +21,7 @@#define CLK_FOUT_CPLL 6#define CLK_FOUT_EPLL 7#define CLK_FOUT_VPLL 8 +#define CLK_ARM_CLK 9/* gate for special clocks (sclk) */ #define CLK_SCLK_CAM_BAYER 128
include/dt-bindings/clock/exynos5420.h +2 -0
@@ -25,6 +25,8 @@#define CLK_FOUT_MPLL 10#define CLK_FOUT_BPLL 11#define CLK_FOUT_KPLL 12 +#define CLK_ARM_CLK 13 +#define CLK_KFC_CLK 14/* gate for special clocks (sclk) */ #define CLK_SCLK_UART0 128
Signature · 1 line
1.7.9.5
PATCH v9 2/6 clk: samsung: add cpu clock configuration data and instantiate cpu clock
Quoting Thomas Abraham (2014-07-30 01:07:39)
Quoted 7 lines
With the addition of the new Samsung specific cpu-clock type, the arm clock can be represented as a cpu-clock type. Add the CPU clock configuration data and instantiate the CPU clock type for Exynos4210, Exynos5250 and Exynos5420.
Cc Tomasz Figa <[email protected]>Signed-off-by Thomas Abraham <[email protected]>
Quoted 196 lines
--- drivers/clk/samsung/clk-exynos4.c | 15 +++++++++++ drivers/clk/samsung/clk-exynos5250.c | 25 ++++++++++++++++++ drivers/clk/samsung/clk-exynos5420.c | 45 ++++++++++++++++++++++++++++++++ include/dt-bindings/clock/exynos5250.h | 1 + include/dt-bindings/clock/exynos5420.h | 2 ++ 5 files changed, 88 insertions(+)drivers/clk/samsung/clk-exynos4.c +15
-0@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" /* Exynos4 clock controller register offsets */ #define SRC_LEFTBUS 0x4200@@ -1355,6 +1356,16 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] __initdata = { VPLL_LOCK, VPLL_CON0, NULL), }; +static const struct exynos_cpuclk_cfg_data e4210_armclk_d[]__initconst = { + {1200000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,5 ), }, + {1000000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,4 ), }, + {800000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {500000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {400000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {200000 ,E4210_CPU_DIV0 (0 ,1 ,1 ,1 ,3 ,1 ),E4210_CPU_DIV1 (0 ,3 ), }, + {0 }, +}; +static void __init exynos4_core_down_clock (enum exynos4_soc soc) {unsigned int tmp;@@ -1458,6 +1469,10 @@ static void __init exynos4_clk_init(struct device_node *np,samsung_clk_register_fixed_factor (ctx, exynos4210_fixed_factor_clks,ARRAY_SIZE (exynos4210_fixed_factor_clks)); +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_core_p4210[0 ], mout_core_p4210[1 ],0x14200 , + e4210_armclk_d,ARRAY_SIZE (e4210_armclk_d), +CLK_CPU_NEEDS_DEBUG_ALT_DIV |CLK_CPU_HAS_DIV1 ); }else {samsung_clk_register_mux (ctx, exynos4x12_mux_clks,ARRAY_SIZE (exynos4x12_mux_clks));drivers/clk/samsung/clk-exynos5250.c +25
-0@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" #define APLL_LOCK 0x0#define APLL_CON0 0x100@@ -748,6 +749,26 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls] __initdata = { VPLL_LOCK, VPLL_CON0, NULL), }; +static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[]__initconst = { + {1700000 ,E5250_CPU_DIV0 (5 ,3 ,7 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1600000 ,E5250_CPU_DIV0 (4 ,1 ,7 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1500000 ,E5250_CPU_DIV0 (4 ,1 ,7 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1400000 ,E5250_CPU_DIV0 (4 ,1 ,6 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1300000 ,E5250_CPU_DIV0 (3 ,1 ,6 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1200000 ,E5250_CPU_DIV0 (3 ,1 ,5 ,7 ,7 ,2 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1100000 ,E5250_CPU_DIV0 (3 ,1 ,5 ,7 ,7 ,3 ),E5250_CPU_DIV1 (2 ,0 ), }, + {1000000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {900000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {800000 ,E5250_CPU_DIV0 (2 ,1 ,4 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {700000 ,E5250_CPU_DIV0 (1 ,1 ,3 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {600000 ,E5250_CPU_DIV0 (1 ,1 ,3 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {500000 ,E5250_CPU_DIV0 (1 ,1 ,2 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {400000 ,E5250_CPU_DIV0 (1 ,1 ,2 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {300000 ,E5250_CPU_DIV0 (1 ,1 ,1 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {200000 ,E5250_CPU_DIV0 (1 ,1 ,1 ,7 ,7 ,1 ),E5250_CPU_DIV1 (2 ,0 ), }, + {0 }, +}; +static const struct of_device_id ext_clk_match[]__initconst = { { .compatible ="samsung,clock-xxti" , .data = (void *)0 , }, { },@@ -797,6 +818,10 @@ static void __init exynos5250_clk_init(struct device_node *np) ARRAY_SIZE(exynos5250_div_clks));samsung_clk_register_gate (ctx, exynos5250_gate_clks,ARRAY_SIZE (exynos5250_gate_clks)); +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_cpu_p[0 ], mout_cpu_p[1 ],0x200 , + exynos5250_armclk_d,ARRAY_SIZE (exynos5250_armclk_d), +CLK_CPU_HAS_DIV1 );/* * Enable arm clock down (in idle) and set arm divider drivers/clk/samsung/clk-exynos5420.c +45
-0@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" #define APLL_LOCK 0x0#define APLL_CON0 0x100@@ -1245,6 +1246,43 @@ static struct samsung_pll_clock exynos5x_plls[nr_plls] __initdata = { KPLL_CON0, NULL), }; +static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[]__initconst = { + {1800000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,4 ), }, + {1700000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,3 ), }, + {1600000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,3 ), }, + {1500000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,3 ), }, + {1400000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,3 ), }, + {1300000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,2 ), }, + {1200000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,2 ), }, + {1100000 ,E5420_EGL_DIV0 (3 ,7 ,7 ,2 ), }, + {1000000 ,E5420_EGL_DIV0 (3 ,6 ,6 ,2 ), }, + {900000 ,E5420_EGL_DIV0 (3 ,6 ,6 ,2 ), }, + {800000 ,E5420_EGL_DIV0 (3 ,5 ,5 ,2 ), }, + {700000 ,E5420_EGL_DIV0 (3 ,5 ,5 ,2 ), }, + {600000 ,E5420_EGL_DIV0 (3 ,4 ,4 ,2 ), }, + {500000 ,E5420_EGL_DIV0 (3 ,3 ,3 ,2 ), }, + {400000 ,E5420_EGL_DIV0 (3 ,3 ,3 ,2 ), }, + {300000 ,E5420_EGL_DIV0 (3 ,3 ,3 ,2 ), }, + {200000 ,E5420_EGL_DIV0 (3 ,3 ,3 ,2 ), }, + {0 }, +}; + +static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[]__initconst = { + {1300000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {1200000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {1100000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {1000000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {900000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {800000 ,E5420_KFC_DIV (3 ,5 ,2 ), }, + {700000 ,E5420_KFC_DIV (3 ,4 ,2 ), }, + {600000 ,E5420_KFC_DIV (3 ,4 ,2 ), }, + {500000 ,E5420_KFC_DIV (3 ,4 ,2 ), }, + {400000 ,E5420_KFC_DIV (3 ,3 ,2 ), }, + {300000 ,E5420_KFC_DIV (3 ,3 ,2 ), }, + {200000 ,E5420_KFC_DIV (3 ,3 ,2 ), }, + {0 }, +}; +static const struct of_device_id ext_clk_match[]__initconst = { { .compatible ="samsung,exynos5420-oscclk" , .data = (void *)0 , }, { },@@ -1309,6 +1347,13 @@ static void __init exynos5x_clk_init(struct device_node *np, ARRAY_SIZE(exynos5800_gate_clks)); } +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_cpu_p[0 ], mout_cpu_p[1 ],0x200 , + exynos5420_eglclk_d,ARRAY_SIZE (exynos5420_eglclk_d),0 ); +exynos_register_cpu_clock (ctx,CLK_KFC_CLK ,"kfcclk" , + mout_kfc_p[0 ], mout_kfc_p[1 ],0x28200 , + exynos5420_kfcclk_d,ARRAY_SIZE (exynos5420_kfcclk_d),0 ); +exynos5420_clk_sleep_init ();samsung_clk_of_add_provider (np, ctx);include/dt-bindings/clock/exynos5250.h +1
-0@@ -21,6 +21,7 @@#define CLK_FOUT_CPLL 6#define CLK_FOUT_EPLL 7#define CLK_FOUT_VPLL 8 +#define CLK_ARM_CLK 9/* gate for special clocks (sclk) */ #define CLK_SCLK_CAM_BAYER 128include/dt-bindings/clock/exynos5420.h +2
-0@@ -25,6 +25,8 @@#define CLK_FOUT_MPLL 10#define CLK_FOUT_BPLL 11#define CLK_FOUT_KPLL 12 +#define CLK_ARM_CLK 13 +#define CLK_KFC_CLK 14/* gate for special clocks (sclk) */ #define CLK_SCLK_UART0 128Signature · 1 line
1.7.9.5
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
In reply to Thomas AbrahamFor Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq drivers.
--- arch/arm/boot/dts/exynos4210-origen.dts | 4 +++ arch/arm/boot/dts/exynos4210-trats.dts | 4 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +++ arch/arm/boot/dts/exynos4210.dtsi | 14 ++++++++- arch/arm/boot/dts/exynos5250-arndale.dts | 4 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++ arch/arm/boot/dts/exynos5250-snow.dts | 4 +++ arch/arm/boot/dts/exynos5250.dtsi | 25 ++++++++++++++- arch/arm/boot/dts/exynos5420.dtsi | 38 +++++++++++++++++++++++ 9 files changed, 99 insertions(+), 2 deletions(-)
arch/arm/boot/dts/exynos4210-origen.dts +4 -0
@@ -334,3 +334,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck1_reg>; +};
arch/arm/boot/dts/exynos4210-trats.dts +4 -0
@@ -446,3 +446,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&varm_breg>; +};
arch/arm/boot/dts/exynos4210-universal_c210.dts +4 -0
@@ -492,3 +492,7 @@ &mdma1 { reg = <0x12840000 0x1000>; }; + +&cpu0 { + cpu0-supply = <&vdd_arm_reg>; +};
arch/arm/boot/dts/exynos4210.dtsi +13 -1
@@ -35,10 +35,22 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 900 { + cpu0: cpu at 900 { device_type = "cpu"; compatible = "arm,cortex-a9"; reg = <0x900>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <160000>; + + operating-points = < + 1200000 1250000 + 1000000 1150000 + 800000 1075000 + 500000 975000 + 400000 975000 + 200000 950000 + >; }; cpu at 901 {
arch/arm/boot/dts/exynos5250-arndale.dts +4 -0
@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};
arch/arm/boot/dts/exynos5250-smdk5250.dts +4 -0
@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};
arch/arm/boot/dts/exynos5250-snow.dts +4 -0
@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"
arch/arm/boot/dts/exynos5250.dtsi +24 -1
@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>; + + operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";
arch/arm/boot/dts/exynos5420.dtsi +38 -0
@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {
@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {
@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {
@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {
@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {
@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu7: cpu at 103 {
@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };
Signature · 1 line
1.7.9.5
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Am 30.07.2014 10:07, schrieb Thomas Abraham:
Quoted 72 lines
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq drivers.
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Signed-off-by Thomas Abraham <[email protected]>--- arch/arm/boot/dts/exynos4210-origen.dts | 4 +++ arch/arm/boot/dts/exynos4210-trats.dts | 4 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +++ arch/arm/boot/dts/exynos4210.dtsi | 14 ++++++++- arch/arm/boot/dts/exynos5250-arndale.dts | 4 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++ arch/arm/boot/dts/exynos5250-snow.dts | 4 +++ arch/arm/boot/dts/exynos5250.dtsi | 25 ++++++++++++++- arch/arm/boot/dts/exynos5420.dtsi | 38 +++++++++++++++++++++++ 9 files changed, 99 insertions(+), 2 deletions(-)arch/arm/boot/dts/exynos4210-origen.dts +4
-0@@ -334,3 +334,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck1_reg>; +};arch/arm/boot/dts/exynos4210-trats.dts +4
-0@@ -446,3 +446,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&varm_breg>; +};arch/arm/boot/dts/exynos4210-universal_c210.dts +4
-0@@ -492,3 +492,7 @@ &mdma1 { reg = <0x12840000 0x1000>; }; + +&cpu0 { + cpu0-supply = <&vdd_arm_reg>; +};arch/arm/boot/dts/exynos4210.dtsi +2
-1@@ -35,10 +35,22 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 900 { + cpu0: cpu at 900 { device_type = "cpu"; compatible = "arm,cortex-a9"; reg = <0x900>; + clocks = <&clock CLK_ARM_CLK>;
arch/arm/boot/dts/exynos4210.dtsi line 52
Quoted 10 lines
arch/arm/boot/dts/exynos4210.dtsi +10
-0+ clock-names = "cpu"; + clock-latency = <160000>; + + operating-points = < + 1200000 1250000 + 1000000 1150000 + 800000 1075000 + 500000 975000 + 400000 975000 + 200000 950000
Nit: Here you left-align the columns ...
Quoted 67 lines
arch/arm/boot/dts/exynos4210.dtsi +1
-0+ >; }; cpu at 901 {arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +13
-1@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>; + + operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000
arch/arm/boot/dts/exynos5250.dtsi line 87
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +10
-0+ 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000
... here you right-align both ...
Quoted 21 lines
arch/arm/boot/dts/exynos5250.dtsi +1
-0+ >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +7
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500
arch/arm/boot/dts/exynos5420.dtsi line 80
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +10
-0+ 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500
... but here only the left column.
Quoted 36 lines
arch/arm/boot/dts/exynos5420.dtsi +7
-0+ >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>;
arch/arm/boot/dts/exynos5420.dtsi line 129
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +10
-0+ + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500
Dito.
Quoted 21 lines
arch/arm/boot/dts/exynos5420.dtsi +3
-0+ >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu7: cpu at 103 {
arch/arm/boot/dts/exynos5420.dtsi line 160
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };
Since I don't really care which template you choose and can't judge most numbers, FWIW
Thanks for resolving the conflict,
Andreas
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Quoted 281 lines · Andreas F?rber
Am 30.07.2014 10:07, schrieb Thomas Abraham:
Quoted 72 lines
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq drivers.
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Signed-off-by Thomas Abraham <[email protected]>--- arch/arm/boot/dts/exynos4210-origen.dts | 4 +++ arch/arm/boot/dts/exynos4210-trats.dts | 4 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +++ arch/arm/boot/dts/exynos4210.dtsi | 14 ++++++++- arch/arm/boot/dts/exynos5250-arndale.dts | 4 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++ arch/arm/boot/dts/exynos5250-snow.dts | 4 +++ arch/arm/boot/dts/exynos5250.dtsi | 25 ++++++++++++++- arch/arm/boot/dts/exynos5420.dtsi | 38 +++++++++++++++++++++++ 9 files changed, 99 insertions(+), 2 deletions(-)arch/arm/boot/dts/exynos4210-origen.dts +4
-0@@ -334,3 +334,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck1_reg>; +};arch/arm/boot/dts/exynos4210-trats.dts +4
-0@@ -446,3 +446,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&varm_breg>; +};arch/arm/boot/dts/exynos4210-universal_c210.dts +4
-0@@ -492,3 +492,7 @@ &mdma1 { reg = <0x12840000 0x1000>; }; + +&cpu0 { + cpu0-supply = <&vdd_arm_reg>; +};arch/arm/boot/dts/exynos4210.dtsi +2
-1@@ -35,10 +35,22 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 900 { + cpu0: cpu at 900 { device_type = "cpu"; compatible = "arm,cortex-a9"; reg = <0x900>; + clocks = <&clock CLK_ARM_CLK>;arch/arm/boot/dts/exynos4210.dtsi line 52
Quoted 10 lines
arch/arm/boot/dts/exynos4210.dtsi +10
-0+ clock-names = "cpu"; + clock-latency = <160000>; + + operating-points = < + 1200000 1250000 + 1000000 1150000 + 800000 1075000 + 500000 975000 + 400000 975000 + 200000 950000Nit: Here you left-align the columns ...
Quoted 67 lines
arch/arm/boot/dts/exynos4210.dtsi +1
-0+ >; }; cpu at 901 {arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +13
-1@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>; - cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>; + + operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000arch/arm/boot/dts/exynos5250.dtsi line 87
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +10
-0+ 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000... here you right-align both ...
Quoted 21 lines
arch/arm/boot/dts/exynos5250.dtsi +1
-0+ >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +7
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500arch/arm/boot/dts/exynos5420.dtsi line 80
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +10
-0+ 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500... but here only the left column.
Quoted 36 lines
arch/arm/boot/dts/exynos5420.dtsi +7
-0+ >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>;arch/arm/boot/dts/exynos5420.dtsi line 129
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +10
-0+ + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500Dito.
Quoted 21 lines
arch/arm/boot/dts/exynos5420.dtsi +3
-0+ >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu7: cpu at 103 {arch/arm/boot/dts/exynos5420.dtsi line 160
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Since I don't really care which template you choose and can't judge most numbers, FWIW
Quoted 5 lines
Reviewed-by Andreas F?rber <[email protected]>Thanks for resolving the conflict,
Andreas
Hi Andreas,
If I have to do one more revision of this series, I will fix the alignment. Thanks for finding this.
Thanks,
Thomas.
Quoted 8 lines
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg --
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
In reply to Thomas AbrahamThomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;
Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
Quoted 72 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +20
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>;
arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +3
-0+ clock-latency = <140000>; }; cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;
It does't start out at its maximum?
Quoted 33 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu7: cpu at 103 {
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 6 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };
Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
-Doug
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Doug,
Quoted 48 lines · Doug Anderson
Thomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;
Quoted 13 lines
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
I measured the time taken by clk_set_rate call in the cpufreq driver using do_gettimeofday(). The time taken to change the clock speed was between 87us to 134us for Exynos5420. So I just took the worst case time of 140us. Also, the time taken to change the CPU clock speed includes the settling time for changes to dividers and mux clock blocks.
Quoted 77 lines
Quoted 77 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +21
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; };
Quoted 9 lines
arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +2
-0cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;It does't start out at its maximum?
The A7 CPU clock need not start with the maximum. On the SMDK5420 board, the firmware has set the A7 CPU clock to 1GHz. So I used the same value here.
Quoted 33 lines
Quoted 33 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; };
Quoted 12 lines
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 8 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0cpu7: cpu at 103 {@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
The arm big.little cpufreq driver does not have voltage scaling support yet. So the supply was not mentioned.
Quoted 4 lines
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
This patch series has support for Exynos5800 as well. But it is A15 clock is restricted to 1.8GHz for now since we do not have a way to handle the vdd_arm and vdd_int voltage difference with 1.9GHz and 2.0GHZ in upstream yet.
Thanks,
Thomas.
Quoted 8 lines
-Doug
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Thomas,
Quoted 65 lines · Thomas Abraham
Hi Doug,
Quoted 48 lines · Doug Anderson
Thomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;Quoted 13 lines
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
Quoted 6 lines
I measured the time taken by
clk_set_ratecall in the cpufreq driver usingdo_gettimeofday(). The time taken to change the clock speed was between 87us to 134us for Exynos5420. So I just took the worst case time of 140us. Also, the time taken to change the CPU clock speed includes the settling time for changes to dividers and mux clock blocks.
Interesting. I wonder why the difference between my earlier calculations. It seems just about double. :-/
Quoted 85 lines
Quoted 75 lines
Quoted 75 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +21
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; };Quoted 9 lines
arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +2
-0cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;It does't start out at its maximum?
Quoted 3 lines
The A7 CPU clock need not start with the maximum. On the SMDK5420 board, the firmware has set the A7 CPU clock to 1GHz. So I used the same value here.
Does it need to match the firmware? On exynos5420-peach-pit and peach-pi I think the firmware starts the kernel at 1.7GHz.
Quoted 48 lines
Quoted 31 lines
Quoted 31 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; };Quoted 12 lines
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 8 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0cpu7: cpu at 103 {@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
The arm big.little cpufreq driver does not have voltage scaling support yet. So the supply was not mentioned.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
This patch series has support for Exynos5800 as well. But it is A15 clock is restricted to 1.8GHz for now since we do not have a way to handle the
vdd_armandvdd_intvoltage difference with 1.9GHz and 2.0GHZ in upstream yet.
Oh, right! The 5800 includes the 5420 dtsi...
-Doug
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Quoted 75 lines · Doug Anderson
Thomas,
Quoted 65 lines · Thomas Abraham
Hi Doug,
Quoted 48 lines · Doug Anderson
Thomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;Quoted 13 lines
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
Quoted 6 lines
I measured the time taken by
clk_set_ratecall in the cpufreq driver usingdo_gettimeofday(). The time taken to change the clock speed was between 87us to 134us for Exynos5420. So I just took the worst case time of 140us. Also, the time taken to change the CPU clock speed includes the settling time for changes to dividers and mux clock blocks.
Quoted 2 lines
Interesting. I wonder why the difference between my earlier calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But the 140us latency is for the whole clk_set_rate() call.
Quoted 87 lines
Quoted 87 lines
Quoted 86 lines
Quoted 74 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +20
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>;arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 10 lines
arch/arm/boot/dts/exynos5420.dtsi +3
-0+ clock-latency = <140000>; }; cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;It does't start out at its maximum?
Quoted 6 lines
Quoted 3 lines
The A7 CPU clock need not start with the maximum. On the SMDK5420 board, the firmware has set the A7 CPU clock to 1GHz. So I used the same value here.
Does it need to match the firmware? On exynos5420-peach-pit and peach-pi I think the firmware starts the kernel at 1.7GHz.
It need not strictly match with the firmware. 1.7GHz for A7 seems too high since the max A7 speed was 1.3GHz. Probably peach-pit/pi had 600MHz starting frequency for A7 CPU.
Thanks,
Thomas.
Quoted 62 lines
Quoted 50 lines
Quoted 33 lines
Quoted 33 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; };Quoted 12 lines
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 8 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0cpu7: cpu at 103 {@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
The arm big.little cpufreq driver does not have voltage scaling support yet. So the supply was not mentioned.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
This patch series has support for Exynos5800 as well. But it is A15 clock is restricted to 1.8GHz for now since we do not have a way to handle the
vdd_armandvdd_intvoltage difference with 1.9GHz and 2.0GHZ in upstream yet.Oh, right! The 5800 includes the 5420 dtsi...
-Doug
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Thomas,
Quoted 173 lines · Thomas Abraham
Quoted 75 lines · Doug Anderson
Thomas,
Quoted 65 lines · Thomas Abraham
Hi Doug,
Quoted 48 lines · Doug Anderson
Thomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;Quoted 13 lines
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
Quoted 6 lines
I measured the time taken by
clk_set_ratecall in the cpufreq driver usingdo_gettimeofday(). The time taken to change the clock speed was between 87us to 134us for Exynos5420. So I just took the worst case time of 140us. Also, the time taken to change the CPU clock speed includes the settling time for changes to dividers and mux clock blocks.Quoted 2 lines
Interesting. I wonder why the difference between my earlier calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But the 140us latency is for the whole
clk_set_rate()call.Quoted 91 lines
Quoted 90 lines
Quoted 77 lines
Quoted 77 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +21
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; };Quoted 9 lines
arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +2
-0cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;It does't start out at its maximum?
The A7 CPU clock need not start with the maximum. On the SMDK5420 board, the firmware has set the A7 CPU clock to 1GHz. So I used the same value here.
Quoted 6 lines
Quoted 2 lines
Does it need to match the firmware? On exynos5420-peach-pit and peach-pi I think the firmware starts the kernel at 1.7GHz.
It need not strictly match with the firmware. 1.7GHz for A7 seems too high since the max A7 speed was 1.3GHz. Probably peach-pit/pi had 600MHz starting frequency for A7 CPU.
Sorry, the ARM was at 1.7, not the KFC. ...but above the default for ARM was listed as 1.8
Quoted 66 lines
Thanks,
Thomas.Quoted 62 lines
Quoted 50 lines
Quoted 33 lines
Quoted 33 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; };Quoted 12 lines
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 8 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0cpu7: cpu at 103 {@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
The arm big.little cpufreq driver does not have voltage scaling support yet. So the supply was not mentioned.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
This patch series has support for Exynos5800 as well. But it is A15 clock is restricted to 1.8GHz for now since we do not have a way to handle the
vdd_armandvdd_intvoltage difference with 1.9GHz and 2.0GHZ in upstream yet.Oh, right! The 5800 includes the 5420 dtsi...
-Doug
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Quoted 179 lines · Doug Anderson
Thomas,
Quoted 176 lines · Thomas Abraham
Quoted 75 lines · Doug Anderson
Thomas,
Quoted 65 lines · Thomas Abraham
Hi Doug,
Quoted 48 lines · Doug Anderson
Thomas,
Quoted 45 lines · Thomas Abraham
arch/arm/boot/dts/exynos5250-arndale.dts +4
-0@@ -575,3 +575,7 @@ usb-phy = <&usb2_phy>; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-smdk5250.dts +4
-0@@ -414,3 +414,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck2_reg>; +};arch/arm/boot/dts/exynos5250-snow.dts +4
-0@@ -509,4 +509,8 @@ }; }; +&cpu0 { + cpu0-supply = <&buck2_reg>; +}; + #include "cros-ec-keyboard.dtsi"arch/arm/boot/dts/exynos5250.dtsi +0
-0@@ -58,11 +58,34 @@ #address-cells = <1>; #size-cells = <0>;Quoted 13 lines
arch/arm/boot/dts/exynos5250.dtsi line 69
Quoted 10 lines
arch/arm/boot/dts/exynos5250.dtsi +5
-1- cpu at 0 { + cpu0: cpu at 0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; clock-frequency = <1700000000>; + + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <140000>;Where did the 140000 number come from? My old calculations show that with lock time of 270 ad P up to 6 we were at 67.5us lock time.
Quoted 6 lines
I measured the time taken by
clk_set_ratecall in the cpufreq driver usingdo_gettimeofday(). The time taken to change the clock speed was between 87us to 134us for Exynos5420. So I just took the worst case time of 140us. Also, the time taken to change the CPU clock speed includes the settling time for changes to dividers and mux clock blocks.Quoted 2 lines
Interesting. I wonder why the difference between my earlier calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But the 140us latency is for the whole
clk_set_rate()call.Quoted 93 lines
Quoted 87 lines
Quoted 77 lines
Quoted 77 lines
arch/arm/boot/dts/exynos5250.dtsi +18
-0+ operating-points = < + 1700000 1300000 + 1600000 1250000 + 1500000 1225000 + 1400000 1200000 + 1300000 1150000 + 1200000 1125000 + 1100000 1100000 + 1000000 1075000 + 900000 1050000 + 800000 1025000 + 700000 1012500 + 600000 1000000 + 500000 975000 + 400000 950000 + 300000 937500 + 200000 925000 + >; }; cpu at 1 { device_type = "cpu";arch/arm/boot/dts/exynos5420.dtsi +21
-0@@ -59,8 +59,26 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu-cluster.0"; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; + + operating-points = < + 1800000 1250000 + 1700000 1212500 + 1600000 1175000 + 1500000 1137500 + 1400000 1112500 + 1300000 1062500 + 1200000 1037500 + 1100000 1012500 + 1000000 987500 + 900000 962500 + 800000 937500 + 700000 912500 + >; }; cpu1: cpu at 1 {@@ -69,6 +87,7 @@ reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu2: cpu at 2 {@@ -77,6 +96,7 @@ reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; }; cpu3: cpu at 3 {@@ -85,14 +105,29 @@ reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; + clock-latency = <140000>; };Quoted 9 lines
arch/arm/boot/dts/exynos5420.dtsi line 117
Quoted 7 lines
arch/arm/boot/dts/exynos5420.dtsi +2
-0cpu4: cpu at 100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + clocks = <&clock CLK_KFC_CLK>; + clock-names = "cpu-cluster.1"; clock-frequency = <1000000000>;It does't start out at its maximum?
Quoted 3 lines
The A7 CPU clock need not start with the maximum. On the SMDK5420 board, the firmware has set the A7 CPU clock to 1GHz. So I used the same value here.
Does it need to match the firmware? On exynos5420-peach-pit and peach-pi I think the firmware starts the kernel at 1.7GHz.
Quoted 6 lines
Quoted 3 lines
It need not strictly match with the firmware. 1.7GHz for A7 seems too high since the max A7 speed was 1.3GHz. Probably peach-pit/pi had 600MHz starting frequency for A7 CPU.
Sorry, the ARM was at 1.7, not the KFC. ...but above the default for ARM was listed as 1.8
I think the listed frequency need not strictly match the initial firmware frequency. If it has to match, then this value can be overridden in the peach-pit/pi board dts files.
Thanks,
Thomas.
Quoted 67 lines
Quoted 67 lines
Thanks,
Thomas.Quoted 62 lines
Quoted 50 lines
Quoted 33 lines
Quoted 33 lines
arch/arm/boot/dts/exynos5420.dtsi +14
-0cci-control-port = <&cci_control0>; + clock-latency = <140000>; + + operating-points = < + 1300000 1275000 + 1200000 1212500 + 1100000 1162500 + 1000000 1112500 + 900000 1062500 + 800000 1025000 + 700000 975000 + 600000 937500 + >; }; cpu5: cpu at 101 {@@ -101,6 +136,7 @@ reg = <0x101>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; cpu6: cpu at 102 {@@ -109,6 +145,7 @@ reg = <0x102>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; };Quoted 12 lines
arch/arm/boot/dts/exynos5420.dtsi line 159
Quoted 8 lines
arch/arm/boot/dts/exynos5420.dtsi +1
-0cpu7: cpu at 103 {@@ -117,6 +154,7 @@ reg = <0x103>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; + clock-latency = <140000>; }; };Don't you need to put a reference to the supply in the 5420 board files? ...or is that not possible yet since the max77802 hasn't landed yet?
The arm big.little cpufreq driver does not have voltage scaling support yet. So the supply was not mentioned.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
If that's not possible, is there any reason to post the 5420.dtsi patch now? Also: what about 5800? It's so similar to 5420 that it seems a shame not to do them at the same time.
This patch series has support for Exynos5800 as well. But it is A15 clock is restricted to 1.8GHz for now since we do not have a way to handle the
vdd_armandvdd_intvoltage difference with 1.9GHz and 2.0GHZ in upstream yet.Oh, right! The 5800 includes the 5420 dtsi...
-Doug
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
In reply to Thomas AbrahamHello Thomas,
Quoted 10 lines · Thomas Abraham
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq drivers.
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Signed-off-by Thomas Abraham <[email protected]>
Quoted 12 lines
--- arch/arm/boot/dts/exynos4210-origen.dts | 4 +++ arch/arm/boot/dts/exynos4210-trats.dts | 4 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +++ arch/arm/boot/dts/exynos4210.dtsi | 14 ++++++++- arch/arm/boot/dts/exynos5250-arndale.dts | 4 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++ arch/arm/boot/dts/exynos5250-snow.dts | 4 +++ arch/arm/boot/dts/exynos5250.dtsi | 25 ++++++++++++++- arch/arm/boot/dts/exynos5420.dtsi | 38 +++++++++++++++++++++++ 9 files changed, 99 insertions(+), 2 deletions(-)
Tested the series on a Exynos5420 based Peach Pit Chromebook by doing the following for CPU0-3:
1) Verified that the big.LITTLE CPUFreq (arm-big-little) driver was reported as used in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver.
2) Set all available governors (conservative, ondemand, userspace, powersave and performance).
3) Confirmed that cpuinfo_cur_freq and scaling_cur_freq values were fixed or changing according to the selected governor policy.
4) Verified that the statistics in /sys/devices/system/cpu/cpu*/cpufreq/stats/* were filled.
Everything is working correctly so please feel free to add for the whole series:
Best regards,
Javier
PATCH v9 3/6 ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Javier,
Quoted 38 lines · Javier Martinez Canillas
Hello Thomas,
Quoted 10 lines · Thomas Abraham
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq drivers.
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Quoted 12 lines
--- arch/arm/boot/dts/exynos4210-origen.dts | 4 +++ arch/arm/boot/dts/exynos4210-trats.dts | 4 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +++ arch/arm/boot/dts/exynos4210.dtsi | 14 ++++++++- arch/arm/boot/dts/exynos5250-arndale.dts | 4 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++ arch/arm/boot/dts/exynos5250-snow.dts | 4 +++ arch/arm/boot/dts/exynos5250.dtsi | 25 ++++++++++++++- arch/arm/boot/dts/exynos5420.dtsi | 38 +++++++++++++++++++++++ 9 files changed, 99 insertions(+), 2 deletions(-)Tested the series on a Exynos5420 based Peach Pit Chromebook by doing the following for CPU0-3:
1) Verified that the big.LITTLE CPUFreq (arm-big-little) driver was reported as used in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_driver.2) Set all available governors (conservative, ondemand, userspace, powersave and performance).
3) Confirmed that
cpuinfo_cur_freqandscaling_cur_freqvalues were fixed or changing according to the selected governor policy.
Quoted 6 lines
4) Verified that the statistics in
/sys/devices/system/cpu/cpu*/cpufreq/stats/*were filled.Everything is working correctly so please feel free to add for the whole series:
Thank you for using this series and the details of what has worked. This is very helpful.
Regards,
Thomas.
Quoted 8 lines
Best regards,
Javier--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
In reply to Thomas AbrahamThe new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
--- arch/arm/mach-exynos/exynos.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
arch/arm/mach-exynos/exynos.c +23 -1
@@ -281,6 +281,28 @@ static void __init exynos_init_irq(void)exynos_map_pmu (); } +static const struct of_device_id exynos_cpufreq_matches[] = { + { .compatible ="samsung,exynos5420" , .data ="arm-bL-cpufreq-dt" }, + { .compatible ="samsung,exynos5250" , .data ="cpufreq-cpu0" }, + { .compatible ="samsung,exynos4210" , .data ="cpufreq-cpu0" }, + { .compatible ="samsung,exynos5440" , .data ="exynos5440-cpufreq" }, + {/* sentinel */ } +}; + +static void __init exynos_cpufreq_init (void ) +{ +struct device_node *root =of_find_node_by_path ("/" ); +const struct of_device_id *match; + + match =of_match_node (exynos_cpufreq_matches, root); +if (!match) { +platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +return ; + } + +platform_device_register_simple (match->data,-1 ,NULL ,0 ); +} +static void __init exynos_dt_machine_init (void ) {struct device_node *i2c_np;
@@ -320,7 +342,7 @@ static void __init exynos_dt_machine_init(void) of_machine_is_compatible("samsung,exynos5250"))platform_device_register (&exynos_cpuidle); -platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +exynos_cpufreq_init ();of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); }
Signature · 1 line
1.7.9.5
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 7 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>
Looks good to me,
BTW, who will handle this series? I hope see this series in 3.17.
- Kukjin
Quoted 48 lines
Signed-off-by Thomas Abraham<[email protected]>Reviewed-by Tomasz Figa<[email protected]>--- arch/arm/mach-exynos/exynos.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)arch/arm/mach-exynos/exynos.c +23
-1@@ -281,6 +281,28 @@ static void __init exynos_init_irq(void)exynos_map_pmu (); } +static const struct of_device_id exynos_cpufreq_matches[] = { + { .compatible ="samsung,exynos5420" , .data ="arm-bL-cpufreq-dt" }, + { .compatible ="samsung,exynos5250" , .data ="cpufreq-cpu0" }, + { .compatible ="samsung,exynos4210" , .data ="cpufreq-cpu0" }, + { .compatible ="samsung,exynos5440" , .data ="exynos5440-cpufreq" }, + {/* sentinel */ } +}; + +static void __init exynos_cpufreq_init (void ) +{ +struct device_node *root =of_find_node_by_path ("/" ); +const struct of_device_id *match; + + match =of_match_node (exynos_cpufreq_matches, root); +if (!match) { +platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +return ; + } + +platform_device_register_simple (match->data,-1 ,NULL ,0 ); +} +static void __init exynos_dt_machine_init (void ) {struct device_node *i2c_np;@@ -320,7 +342,7 @@ static void __init exynos_dt_machine_init(void) of_machine_is_compatible("samsung,exynos5250"))platform_device_register (&exynos_cpuidle); -platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +exynos_cpufreq_init ();of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); }
Signature · 7 lines
Thanks. Best regards, Kgene. -- Kukjin Kim <[email protected]>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree.
[1] ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
Best regards,
Tomasz
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 25 lines · Tomasz Figa
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree.
Quoted 4 lines
[1] ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
Aha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards.
This would also have the advantage of having the two patches mentioned above already merged.
Best regards,
Tomasz
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 28 lines · Tomasz Figa
Quoted 25 lines · Tomasz Figa
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree.
Quoted 8 lines
Quoted 4 lines
[1] ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.htmlAha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards.
The v9 revision of this series has completed about 2 days of testing now on 4210/5250/5420 boards. I will let it run for few more days. For v8 and previous versions, the tests had completed 3 or more days. So I really don't think there is anything fundamentally wrong with this series. It would be nice to have this series merged and we start migrating other Exynos based boards to use generic cpufreq drivers.
Thanks,
Thomas.
Quoted 11 lines
This would also have the advantage of having the two patches mentioned above already merged.
Best regards,
Tomasz_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 38 lines · Thomas Abraham
Quoted 28 lines · Tomasz Figa
Quoted 25 lines · Tomasz Figa
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree.
Quoted 8 lines
Quoted 4 lines
[1] ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.htmlAha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards.
Quoted 6 lines
The v9 revision of this series has completed about 2 days of testing now on 4210/5250/5420 boards. I will let it run for few more days. For v8 and previous versions, the tests had completed 3 or more days. So I really don't think there is anything fundamentally wrong with this series. It would be nice to have this series merged and we start migrating other Exynos based boards to use generic cpufreq drivers.
We have 22 Exynos-based boards currently supported in mainline. Is the testing running on all of them? This is the purpose of linux-next and for series that completely replace one driver with another I'd consider this as the only reasonable choice, if not keeping the old driver for a release.
Of course we have never had good testing traditions on Samsung SoC (see OMAP and Tegra baseline tests), but does it mean that we shouldn't start doing the right thing?
Best regards,
Tomasz
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Tomasz,
Quoted 46 lines · Tomasz Figa
Quoted 38 lines · Thomas Abraham
Quoted 28 lines · Tomasz Figa
Quoted 25 lines · Tomasz Figa
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree.
Quoted 8 lines
Quoted 4 lines
[1] ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.htmlAha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards.
Quoted 6 lines
The v9 revision of this series has completed about 2 days of testing now on 4210/5250/5420 boards. I will let it run for few more days. For v8 and previous versions, the tests had completed 3 or more days. So I really don't think there is anything fundamentally wrong with this series. It would be nice to have this series merged and we start migrating other Exynos based boards to use generic cpufreq drivers.
Quoted 2 lines
We have 22 Exynos-based boards currently supported in mainline. Is the testing running on all of them? This is the purpose of linux-next and
This series replaces existing cpufreq driver for Exynos4210 and Exynos5250 which impact 7 Exynos boards - Exynos4210 (smdk, origen, trats, universal), Exynos5250 (smdk, arndale, snow). Out of these, it is trats and universal that have not been tested. Which other 15 Exynos boards did you feel this series needs to be tested on? Sanity testing for Exynos4x12 cpufreq support was done on Exynos4412 Origen board.
Quoted 7 lines
for series that completely replace one driver with another I'd consider this as the only reasonable choice, if not keeping the old driver for a release.
Of course we have never good testing traditions on Samsung SoC (see OMAP and Tegra baseline tests), but does it mean that we shouldn't start doing the right thing?
Aren't Tegra/OMAP baseline tests for upstream kernel versions only, not for linux-next?
Thanks,
Thomas.
Quoted 3 lines
Best regards,
Tomasz
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
In reply to Tomasz FigaQuoted 14 lines · Tomasz Figa
Kukjin,
Quoted 11 lines · Kukjin Kim
Quoted 7 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Quoted 7 lines
Quoted 3 lines
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next.
Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git wip/exynos/integ
[2]
Quoted 1 line
From
72ee00246c0fbdcf5dbb0bf910b8a427da4ac002Mon Sep 17 00:00:00 2001
From: Kevin Hilman <[email protected]>
Date: Fri, 22 Aug 2014 16:04:11 -0700
Subject: [PATCH] ARM: Exynos: use generic cpufreq driver for Exynos5800
As a derivative of the 5420, the 5800 SoC should use the generic big.LITTLE driver for Exynos5800 as well.
--- arch/arm/mach-exynos/exynos.c | 1 + 1 file changed, 1 insertion(+)
arch/arm/mach-exynos/exynos.c +1 -0
@@ -283,6 +283,7 @@ static void __init exynos_init_irq(void)static const struct of_device_id exynos_cpufreq_matches[] = { { .compatible ="samsung,exynos5420" , .data ="arm-bL-cpufreq-dt" }, + { .compatible ="samsung,exynos5800" , .data ="arm-bL-cpufreq-dt" }, { .compatible ="samsung,exynos5250" , .data ="cpufreq-cpu0" }, { .compatible ="samsung,exynos4210" , .data ="cpufreq-cpu0" }, { .compatible ="samsung,exynos5440" , .data ="exynos5440-cpufreq" },
Signature · 1 line
1.9.2
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin,
Thanks for taking a look at this.
Quoted 18 lines · Kevin Hilman
Quoted 16 lines · Tomasz Figa
Kukjin,
Quoted 13 lines · Kukjin Kim
Quoted 7 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next.
No, it has not. In general it was already too late in the release cycle when the last version was posted.
I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it...
Quoted 10 lines
Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs. Also I'd like to hear some confirmation from Samsung Poland R&D Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2).
Quoted 6 lines
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing.
The patch looks fine to me (well, it's trivial :)), thanks.
Best regards,
Tomasz
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Tomasz,
Quoted 47 lines
Hi Kevin,
Thanks for taking a look at this.
Quoted 18 lines · Kevin Hilman
Quoted 16 lines · Tomasz Figa
Kukjin,
Quoted 13 lines · Kukjin Kim
Quoted 7 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>Quoted 8 lines
Quoted 5 lines
Quoted 1 line
BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next.
No, it has not. In general it was already too late in the release cycle when the last version was posted.
I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it...
Quoted 9 lines
Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
Quoted 5 lines
Quoted 2 lines
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs.
It is a huge step forward - to be honest it is a serious rework of cpufreq subsystem for Exynos SoCs.
Quoted 4 lines
Also I'd like to hear some confirmation from Samsung Poland R&D Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2).
Since we have missed the merge window with this code, I can declare that I will provide code, which means that I will do the cleanup for excluded from this series Exynos4 SoCs, to test the cpufreq-cpu0.
However, I'm concerned with Exynos4412, which supports BOOST. It might not be trivial to provide support for it.
I think, that we shall not drop behind any functionality during clean up.
Quoted 17 lines
Quoted 7 lines
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing.
The patch looks fine to me (well, it's trivial :)), thanks.
Best regards,
Tomasz_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 5 lines
Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
In reply to Tomasz FigaHi Kevin, Tomasz,
Quoted 29 lines · Tomasz Figa
Hi Kevin,
Thanks for taking a look at this.
Quoted 24 lines · Kevin Hilman
Quoted 21 lines · Tomasz Figa
Kukjin,
Quoted 6 lines · Kukjin Kim
Quoted 5 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Quoted 8 lines
Quoted 2 lines
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree.
Quoted 19 lines
Quoted 2 lines
So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next.
No, it has not. In general it was already too late in the release cycle when the last version was posted.
I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it...
Quoted 10 lines
Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled).
As of now voltage scaling support is not there in generic big-little cpufreq driver (arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.
Without this change stability issues are there, but with this change everything is stable.
Quoted 16 lines
I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs. Also I'd like to hear some confirmation from Samsung Poland R&D Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2).
Quoted 6 lines
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing.
The patch looks fine to me (well, it's trivial :)), thanks.
Quoted 7 lines
Best regards,
Tomasz_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
regards,
Chander
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Chander,
Chander Kashyap <[email protected]> writes:
[...]
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled).
Quoted 6 lines
As of now voltage scaling support is not there in generic big-little cpufreq driver (
arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.Without this change stability issues are there, but with this change everything is stable.
Can you clarify how you're setting the voltages to ensure stability?
Tomasz, I didn't mean to suggest this isn't ready for mainline. For the 5420/5800 it seems cpufreq support is a new feature, so this isn't a regression against previous (mainline) behavior. Maybe the big.LITTLE cpufreq support should've been separated out from the cleanup since it's more of a new feature, but that's up to you.
Kevin
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 20 lines · Kevin Hilman
Hi Chander,
Chander Kashyap <[email protected]> writes:
[...]
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled).
As of now voltage scaling support is not there in generic big-little cpufreq driver (
arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.
Quoted 6 lines
Quoted 2 lines
Without this change stability issues are there, but with this change everything is stable.
Can you clarify how you're setting the voltages to ensure stability?
Tomasz, I didn't mean to suggest this isn't ready for mainline.
I haven't said that either. I'd just like to know in what state this series is in case of those SoCs. However, if there are stability issues on them, there is also a chance that the same is true for other boards.
Anyway, we're early in releasy cycle, so probably we could get better test coverage with this series in linux-next.
Kukjin, Viresh, how would you want to proceed with merging it? It touches mach-exynos, cpufreq and samsung-clk, so it is non-trivial to merge. However as far as I can see the cpufreq-related changes are just a number of full file deletes and minor Makefile/Kconfig updates. It will be more difficult with mach-exynos changes, as they are more likely to produce conflict.
The only solution that comes to my mind is that I first apply patches 1 and 2, create a stable branch for Kukjin, then he applies patches 3, 4, and 5 and creates a stable branch for me, on top of which I apply patch 6.
Best regards,
Tomasz
Viresh Kumar
maintainerPATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 1 line · Tomasz Figa
Kukjin, Viresh, how would you want to proceed with merging it? It
Me and Rafael has agreed earlier that Kukjin can take these through ARM-Soc tree..
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
In reply to Kevin HilmanHi Kevin,
Quoted 16 lines · Kevin Hilman
Hi Chander,
Chander Kashyap <[email protected]> writes:
[...]
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled).
Quoted 8 lines
Quoted 6 lines
As of now voltage scaling support is not there in generic big-little cpufreq driver (
arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.Without this change stability issues are there, but with this change everything is stable.
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
arch/arm/boot/dts/exynos5800-peach-pi.dts +2 -2
@@ -225,7 +225,7 @@ buck2_reg: BUCK2 { regulator-name = "vdd_arm"; - regulator-min-microvolt = <800000>; + regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; regulator-always-on; regulator-boot-on;
@@ -260,7 +260,7 @@ buck6_reg: BUCK6 { regulator-name = "vdd_kfc"; - regulator-min-microvolt = <800000>; + regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; regulator-always-on; regulator-boot-on;
Quoted 7 lines
Tomasz, I didn't mean to suggest this isn't ready for mainline. For the 5420/5800 it seems cpufreq support is a new feature, so this isn't a regression against previous (mainline) behavior. Maybe the big.LITTLE cpufreq support should've been separated out from the cleanup since it's more of a new feature, but that's up to you.
Quoted 6 lines
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
regards,
Chander
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 23 lines · Chander Kashyap
Hi Kevin,
Quoted 20 lines · Kevin Hilman
Hi Chander,
Chander Kashyap <[email protected]> writes:
[...]
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled).
As of now voltage scaling support is not there in generic big-little cpufreq driver (
arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Without this change stability issues are there, but with this change everything is stable.
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch atgit://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.
Are there other out of tree dependencies that I'm missing? Is the max77802 regulator support that's in mainline sufficient? or am I missing some stuff there?
Kevin
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.
Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.
I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated?
Kevin
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Sorry for the delaying in following up.
Thanks,
Thomas.
Quoted 8 lines
Kevin
[1]https://github.com/exynos-reference/kernel.git
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Thomas,
Quoted 44 lines · Thomas Abraham
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?
Quoted 8 lines
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Can you share your branch and temp hack(s) as well as your defconfig?
I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue.
It would be good if I can reproduce your exact tree/branch and see if I still have the same problem.
Thanks for looking into this,
Kevin
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin,
Quoted 56 lines · Kevin Hilman
Hi Thomas,
Quoted 44 lines · Thomas Abraham
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?Quoted 8 lines
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Quoted 8 lines
Can you share your branch and temp hack(s) as well as your defconfig?
I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue.
It would be good if I can reproduce your exact tree/branch and see if I still have the same problem.
The branch with the patches that have been used to test cpufreq on Exynos5800 is available at
https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq
Please let me know if this works or if there are any issues.
Thanks,
Thomas.
Quoted 4 lines
Thanks for looking into this,
Kevin
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
HI Thomas,
Quoted 66 lines · Thomas Abraham
Quoted 56 lines · Kevin Hilman
Hi Thomas,
Quoted 44 lines · Thomas Abraham
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?Quoted 8 lines
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Quoted 8 lines
Can you share your branch and temp hack(s) as well as your defconfig?
I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue.
It would be good if I can reproduce your exact tree/branch and see if I still have the same problem.
Quoted 6 lines
The branch with the patches that have been used to test cpufreq on Exynos5800 is available at
https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq
Please let me know if this works or if there are any issues.
Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]:
ARM: dts: remove all supplies sourced from tps65090 PMIC
That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread.
I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this.
One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.)
Are there any plans to update the main referece branch and include cpufreq?
Kevin
[1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin,
Quoted 73 lines · Kevin Hilman
HI Thomas,
Quoted 69 lines · Thomas Abraham
Quoted 56 lines · Kevin Hilman
Hi Thomas,
Quoted 44 lines · Thomas Abraham
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?Quoted 8 lines
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Quoted 8 lines
Can you share your branch and temp hack(s) as well as your defconfig?
I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue.
It would be good if I can reproduce your exact tree/branch and see if I still have the same problem.
The branch with the patches that have been used to test cpufreq on Exynos5800 is available at
Quoted 7 lines
Quoted 3 lines
https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq
Please let me know if this works or if there are any issues.
Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]:
ARM: dts: remove all supplies sourced from tps65090 PMIC
I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary.
Quoted 5 lines
That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread.
At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier.
Quoted 5 lines
I also noticed that the "force
vdd_armandvdd_kfcto max voltage" patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this.
This also is a temporary patch and by "max voltage" I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply.
Quoted 4 lines
One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.)
I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch.
Quoted 3 lines
Are there any plans to update the main referece branch and include cpufreq?
Yes, a new branch with all the latest patches (cpufreq + regulator + temp fixes) will be created. I will let you when that is ready.
Thanks,
Thomas.
Quoted 4 lines
Kevin
[1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 123 lines · Thomas Abraham
Hi Kevin,
Quoted 73 lines · Kevin Hilman
HI Thomas,
Quoted 69 lines · Thomas Abraham
Quoted 56 lines · Kevin Hilman
Hi Thomas,
Quoted 44 lines · Thomas Abraham
Hi Kevin,
Quoted 33 lines · Kevin Hilman
Quoted 1 line · Kevin Hilman
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 4 lines
Quoted 2 lines
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied your patch, and bootup shows
vdd_armandvdd_kfcat 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable.Quoted 4 lines
What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq.
Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs.
Quoted 7 lines
Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled.
So that leads to the question. Are all of the operating points in
exynos5420.dtsivalid for exynos5800, and have they been validated?Quoted 8 lines
I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz).
I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V.
Quoted 8 lines
Can you share your branch and temp hack(s) as well as your defconfig?
I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue.
It would be good if I can reproduce your exact tree/branch and see if I still have the same problem.
The branch with the patches that have been used to test cpufreq on Exynos5800 is available at
Quoted 7 lines
Quoted 3 lines
https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq
Please let me know if this works or if there are any issues.
Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]:
ARM: dts: remove all supplies sourced from tps65090 PMICI must have explicitly stated that I am using local changes to get
vdd_armandvdd_kfcto required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary.Quoted 5 lines
That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread.
At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier.
Quoted 5 lines
I also noticed that the "force
vdd_armandvdd_kfcto max voltage" patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this.This also is a temporary patch and by "max voltage" I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply.
Quoted 4 lines
One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.)
I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch.
Quoted 1 line
Quoted 5 lines
Quoted 2 lines
Are there any plans to update the main referece branch and include cpufreq?
Yes, a new branch with all the latest patches (cpufreq + regulator + temp fixes) will be created. I will let you when that is ready.
Hi Kevin,
A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3.
[1] https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3
Thanks,
Thomas.
Quoted 8 lines
Thanks,
Thomas.Quoted 4 lines
Kevin
[1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Thomas,
Thomas Abraham <[email protected]> writes:
[...]
Quoted 5 lines
A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3.
Excellent! Thank you.
The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up.
With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled?
Thanks again for your work on this, we're getting close!
Kevin
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279028.html
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 18 lines · Kevin Hilman
Hi Thomas,
Thomas Abraham <[email protected]> writes:
[...]
Quoted 5 lines
A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3.
Excellent! Thank you.
The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up.
Quoted 5 lines
With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled?
Yes, I have tested switcher + cpufreq + cpuidle with this branch and there are no issues found. I haven't tested with powertop yet. I will try and do that and let you know the result.
You mentioned that when you run powertop, it gets stuck. When that happens, is there any log on the console or does system just turn unresponsive?
Thanks,
Thomas.
Quoted 7 lines
Thanks again for your work on this, we're getting close!
Kevin
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279028.html
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 25 lines · Thomas Abraham
Quoted 18 lines · Kevin Hilman
Hi Thomas,
Thomas Abraham <[email protected]> writes:
[...]
Quoted 5 lines
A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3.
Excellent! Thank you.
The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up.
Quoted 5 lines
With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled?
Quoted 7 lines
Yes, I have tested switcher + cpufreq + cpuidle with this branch and there are no issues found. I haven't tested with powertop yet. I will try and do that and let you know the result.
You mentioned that when you run powertop, it gets stuck. When that happens, is there any log on the console or does system just turn unresponsive?
The console is not responsive, but kernel seems busy because I see periodic timeout messages from the samsung clock driver.
Note that I see these messages when things are functioning normally also.
Kevin
[1]
[ 337.832031] wait_until_divider_stable: timeout in divider stablization [ 337.847024] wait_until_divider_stable: timeout in divider stablization [ 337.862024] wait_until_divider_stable: timeout in divider stablization [ 337.957028] wait_until_divider_stable: timeout in divider stablization [ 337.972024] wait_until_divider_stable: timeout in divider stablization [ 337.987024] wait_until_divider_stable: timeout in divider stablization [ 340.082029] wait_until_divider_stable: timeout in divider stablization [ 340.097024] wait_until_divider_stable: timeout in divider stablization [ 340.112024] wait_until_divider_stable: timeout in divider stablization [ 346.242030] wait_until_divider_stable: timeout in divider stablization [ 346.257024] wait_until_divider_stable: timeout in divider stablization [ 346.272024] wait_until_divider_stable: timeout in divider stablization [ 348.322029] wait_until_divider_stable: timeout in divider stablization [ 348.337025] wait_until_divider_stable: timeout in divider stablization [ 348.352024] wait_until_divider_stable: timeout in divider stablization
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Quoted 31 lines · Kevin Hilman
Quoted 29 lines · Thomas Abraham
Quoted 18 lines · Kevin Hilman
Hi Thomas,
Thomas Abraham <[email protected]> writes:
[...]
Quoted 5 lines
A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3.
Excellent! Thank you.
The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up.
Quoted 5 lines
With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled?
Yes, I have tested switcher + cpufreq + cpuidle with this branch and there are no issues found. I haven't tested with powertop yet. I will try and do that and let you know the result.
Quoted 6 lines
Quoted 3 lines
You mentioned that when you run powertop, it gets stuck. When that happens, is there any log on the console or does system just turn unresponsive?
The console is not responsive, but kernel seems busy because I see periodic timeout messages from the samsung clock driver.
Ok, I haven't tried to recreate this issue. I will try and do that.
Quoted 3 lines
Note that I see these messages when things are functioning normally also.
I did notice this a few times before but today I was able to reproduce this consistently with other test cases. This timeout is because the CPU clock blocks of the cluster that has been turned down are being reconfigured, which on Exynos will not work. The following is a temporary patch which solves this issue.
Quoted 1 line
From
b0c4057d428134fe12446431ede1d9a579fd1d05Mon Sep 17 00:00:00 2001
From: Thomas Abraham <[email protected]>
Date: Fri, 5 Sep 2014 17:11:10 +0530
Subject: [PATCH] TEMP: cpufreq/bL: let the CPU switch complete before scaling frequency
On Exynos5420/Exyons5800, the clock blocks that make up the CPU clock supply do no operate when the cluster in which they belong is powered off. The CPU clock supply path is PLL -> Mux/Dividers -> CPU_clock.
In the arm_big_little CPUfreq driver, the frequency is scaled first and then the CPU is switched to the new cluster. In case the switch was for the first-man CPU in that new cluster, the frequency scaling step in arm_big_little CPUfreq driver would not work for Exynos since the in-bound cluster is powered off at that point. Note: On Exynos, the cluster is powered off when all the CPUs in that cluster are powered off which implies that the CPU clock blocks for that cluster do not operate anymore.
So when using arm_big_little CPUfreq driver for Exynos, two changes are required. The first change is to let the CPU to switch to the new cluster before scaling the frequency. The second change is to ensure that the switch has been completed before scaling the frequency.
With these changes, the message "wait_until_divider_stable: timeout in divider stabilization" is not seen anymore.
--- arch/arm/include/asm/bL_switcher.h | 15 ++++++++++++++- drivers/cpufreq/arm_big_little.c | 9 ++++++++- 2 files changed, 22 insertions(+), 2 deletions(-)
(quoted diff) +0 -0
b/arch/arm/include/asm/bL_switcher.h
index 1714800..d609b86 100644
arch/arm/include/asm/bL_switcher.h +7 -0
@@ -20,9 +20,22 @@ typedef void (*bL_switch_completion_handler)(void *cookie);int bL_switch_request_cb (unsigned int cpu,unsigned int new_cluster_id,bL_switch_completion_handler completer,void *completer_cookie); + +static void bL_switch_complete_cb (void *cookie) +{ +struct completion *switch_complete = (struct completion *) cookie; +complete (switch_complete); +} + static inline int bL_switch_request(unsigned int cpu, unsigned int
new_cluster_id)
{
- return bL_switch_request_cb(cpu, new_cluster_id, NULL, NULL);
+ struct completion complete;
+
+ init_completion(&complete);
+ bL_switch_request_cb(cpu, new_cluster_id, &bL_switch_complete_cb,
+ &complete);
+ wait_for_completion(&complete);
+ return 0;
}
/*
drivers/cpufreq/arm_big_little.c +0 -0
@@ -129,6 +129,13 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
new_cluster, u32 rate)
int ret;
bool bLs = is_bL_switching_enabled();+ /* Switch cluster */
+ if (old_cluster != new_cluster) {
+ pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d\n",
+ __func__, cpu, old_cluster, new_cluster);
+ bL_switch_request(cpu, new_cluster);
+ }
+
mutex_lock(&cluster_lock[new_cluster]);
if (bLs) {
@@ -167,7 +174,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
new_cluster, u32 rate)
__func__, cpu, old_cluster, new_cluster);
/* Switch cluster */- bL_switch_request(cpu, new_cluster);
+ /*bL_switch_request(cpu, new_cluster);*/
mutex_lock(&cluster_lock[old_cluster]);
Signature · 1 line
1.6.6.rc2
Quoted 20 lines
Kevin
[1]
[ 337.832031] wait_until_divider_stable: timeout in divider stablization [ 337.847024] wait_until_divider_stable: timeout in divider stablization [ 337.862024] wait_until_divider_stable: timeout in divider stablization [ 337.957028] wait_until_divider_stable: timeout in divider stablization [ 337.972024] wait_until_divider_stable: timeout in divider stablization [ 337.987024] wait_until_divider_stable: timeout in divider stablization [ 340.082029] wait_until_divider_stable: timeout in divider stablization [ 340.097024] wait_until_divider_stable: timeout in divider stablization [ 340.112024] wait_until_divider_stable: timeout in divider stablization [ 346.242030] wait_until_divider_stable: timeout in divider stablization [ 346.257024] wait_until_divider_stable: timeout in divider stablization [ 346.272024] wait_until_divider_stable: timeout in divider stablization [ 348.322029] wait_until_divider_stable: timeout in divider stablization [ 348.337025] wait_until_divider_stable: timeout in divider stablization [ 348.352024] wait_until_divider_stable: timeout in divider stablization
PATCH v9 4/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
In reply to Kevin HilmanHey,
Quoted 30 lines · Kevin Hilman
Quoted 14 lines · Tomasz Figa
Kukjin,
Quoted 11 lines · Kukjin Kim
Quoted 7 lines · Thomas Abraham
The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver.
Suggested-by Tomasz Figa<[email protected]>Cc Kukjin Kim<[email protected]>Looks good to me,
Quoted 7 lines
Quoted 3 lines
Acked-by Kukjin Kim <[email protected]>BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next.
Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs.
Quoted 8 lines
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher.
Also, the patch below[2] is needed for 5800.
For reference, I had the same patch in a kernel tree we recently used for a demo on the chromebook 2 13" (Exynos 5800). We didn't see any stability issues due to this without CPUidle (using the ondemand govenor). The kernel we ended up using had CONFIG_BL_SWITCHER disabled, but i don't remember seeing stability issues when i did a testrun with that enabled.
Signature · 9 lines
Sjoerd Simons <[email protected]> Collabora Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6170 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/e02aa78e/attachment.bin>
PATCH v9 5/6 cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
In reply to Thomas AbrahamExynos4210 and Exynos5250 based platforms have switched over to use generic cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed.
--- drivers/cpufreq/Kconfig.arm | 22 ---- drivers/cpufreq/Makefile | 2 - drivers/cpufreq/exynos4210-cpufreq.c | 184 ----------------------------- drivers/cpufreq/exynos5250-cpufreq.c | 210 ---------------------------------- 4 files changed, 418 deletions(-) delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
drivers/cpufreq/Kconfig.arm +0 -22
@@ -28,17 +28,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ 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
@@ -50,17 +39,6 @@ config ARM_EXYNOS4X12_CPUFREQ 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
drivers/cpufreq/Makefile +0 -2
@@ -52,9 +52,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI) += 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
drivers/cpufreq/exynos4210-cpufreq.c deleted +0 -184
184 lines not on this page · raw message
drivers/cpufreq/exynos5250-cpufreq.c deleted +0 -210
210 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
In reply to Thomas AbrahamWith some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
--- drivers/clk/samsung/clk-exynos4.c | 48 +++++++++++++++++----------------- drivers/clk/samsung/clk-exynos5250.c | 19 ++++++++------ drivers/clk/samsung/clk-exynos5420.c | 27 ++++++++++++------- 3 files changed, 53 insertions(+), 41 deletions(-)
drivers/clk/samsung/clk-exynos4.c +24 -24
@@ -578,7 +578,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 (0 ,"mout_hpm" , mout_core_p4210,SRC_CPU ,20 ,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),
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[] __initdata = {DIV (0 ,"div_clkout_rightbus" ,"mout_clkout_rightbus" ,CLKOUT_CMU_RIGHTBUS ,8 ,6 ), -DIV (0 ,"div_core" ,"mout_core" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"div_corem0" ,"div_core2" ,DIV_CPU0 ,4 ,3 ), -DIV (0 ,"div_corem1" ,"div_core2" ,DIV_CPU0 ,8 ,3 ), -DIV (0 ,"div_periph" ,"div_core2" ,DIV_CPU0 ,12 ,3 ), -DIV (0 ,"div_atb" ,"mout_core" ,DIV_CPU0 ,16 ,3 ), -DIV (0 ,"div_pclk_dbg" ,"div_atb" ,DIV_CPU0 ,20 ,3 ), -DIV (CLK_ARM_CLK ,"div_core2" ,"div_core" ,DIV_CPU0 ,28 ,3 ), -DIV (0 ,"div_copy" ,"mout_hpm" ,DIV_CPU1 ,0 ,3 ), -DIV (0 ,"div_hpm" ,"div_copy" ,DIV_CPU1 ,4 ,3 ), +DIV_F (0 ,"div_core" ,"mout_core" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_corem0" ,"div_core2" ,DIV_CPU0 ,4 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_corem1" ,"div_core2" ,DIV_CPU0 ,8 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_periph" ,"div_core2" ,DIV_CPU0 ,12 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_atb" ,"mout_core" ,DIV_CPU0 ,16 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_pclk_dbg" ,"div_atb" ,DIV_CPU0 ,20 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (CLK_ARM_CLK ,"div_core2" ,"div_core" ,DIV_CPU0 ,28 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_copy" ,"mout_hpm" ,DIV_CPU1 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_hpm" ,"div_copy" ,DIV_CPU1 ,4 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ),DIV (0 ,"div_clkout_cpu" ,"mout_clkout_cpu" ,CLKOUT_CMU_CPU ,8 ,6 ), DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
@@ -770,7 +780,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_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 ,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,
@@ -1187,17 +1198,10 @@ static struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = { 0), }; -static struct samsung_clock_alias exynos4_aliases[]__initdata = { +static struct samsung_clock_alias exynos4x12_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" ), -}; - -static struct samsung_clock_alias exynos4x12_aliases[]__initdata = {ALIAS (CLK_MOUT_MPLL_USER_C ,NULL ,"mout_mpll" ), };
@@ -1464,8 +1468,6 @@ static void __init exynos4_clk_init(struct device_node *np, ARRAY_SIZE(exynos4210_div_clks));samsung_clk_register_gate (ctx, exynos4210_gate_clks,ARRAY_SIZE (exynos4210_gate_clks)); -samsung_clk_register_alias (ctx, exynos4210_aliases, -ARRAY_SIZE (exynos4210_aliases));samsung_clk_register_fixed_factor (ctx, exynos4210_fixed_factor_clks,ARRAY_SIZE (exynos4210_fixed_factor_clks));
@@ -1487,9 +1489,6 @@ static void __init exynos4_clk_init(struct device_node *np, ARRAY_SIZE(exynos4x12_fixed_factor_clks)); } -samsung_clk_register_alias (ctx, exynos4_aliases, -ARRAY_SIZE (exynos4_aliases)); -exynos4_core_down_clock (soc);exynos4_clk_sleep_init ();
@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2")); }
drivers/clk/samsung/clk-exynos5250.c +11 -8
@@ -291,14 +291,14 @@ static struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {/* * CMU_CPU */ -MUX_FA (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , -CLK_SET_RATE_PARENT ,0 ,"mout_apll" ), -MUX_A (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,"mout_cpu" ), +MUX_F (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,0 ,CLK_MUX_READ_ONLY ),/* * CMU_CORE */ - MUX_A(0, "mout_mpll", mout_mpll_p, SRC_CORE1, 8, 1, "mout_mpll"), + MUX(0, "mout_mpll", mout_mpll_p, SRC_CORE1, 8, 1),/* * CMU_TOP
@@ -380,9 +380,12 @@ static struct samsung_div_clock exynos5250_div_clks[] __initdata = {/* * CMU_CPU */ -DIV (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"div_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 ), - DIV_A(0, "div_arm2", "div_arm", DIV_CPU0, 28, 3, "armclk"), +DIV_F (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_arm2" ,"div_arm" ,DIV_CPU0 ,28 ,3 , + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),/* * CMU_TOP
@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" )); }CLK_OF_DECLARE (exynos5250_clk,"samsung,exynos5250-clock" , exynos5250_clk_init);
drivers/clk/samsung/clk-exynos5420.c +18 -9
@@ -617,10 +617,14 @@ static struct samsung_mux_clock exynos5x_mux_clks[] __initdata = {MUX (0 ,"mout_mspll_kfc" , mout_mspll_cpu_p,SRC_TOP7 ,8 ,2 ),MUX (0 ,"mout_mspll_cpu" , mout_mspll_cpu_p,SRC_TOP7 ,12 ,2 ), -MUX (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 ), -MUX (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ), -MUX (0 ,"mout_kpll" , mout_kpll_p,SRC_KFC ,0 ,1 ), -MUX (0 ,"mout_kfc" , mout_kfc_p,SRC_KFC ,16 ,1 ), +MUX_F (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,0 , +CLK_MUX_READ_ONLY ), +MUX_F (0 ,"mout_kpll" , mout_kpll_p,SRC_KFC ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_kfc" , mout_kfc_p,SRC_KFC ,16 ,1 ,0 , +CLK_MUX_READ_ONLY ),MUX (0 ,"mout_aclk200" , mout_group1_p,SRC_TOP0 ,8 ,2 ), MUX(0, "mout_aclk200_fsys2", mout_group1_p, SRC_TOP0, 12, 2),
@@ -776,11 +780,16 @@ static struct samsung_mux_clock exynos5x_mux_clks[] __initdata = { };static struct samsung_div_clock exynos5x_div_clks[]__initdata = { -DIV (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"sclk_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 ), -DIV (0 ,"armclk2" ,"div_arm" ,DIV_CPU0 ,28 ,3 ), -DIV (0 ,"div_kfc" ,"mout_kfc" ,DIV_KFC0 ,0 ,3 ), -DIV (0 ,"sclk_kpll" ,"mout_kpll" ,DIV_KFC0 ,24 ,3 ), +DIV_F (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"sclk_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"armclk2" ,"div_arm" ,DIV_CPU0 ,28 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_kfc" ,"mout_kfc" ,DIV_KFC0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"sclk_kpll" ,"mout_kpll" ,DIV_KFC0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ),DIV (0 ,"dout_aclk400_isp" ,"mout_aclk400_isp" ,DIV_TOP0 ,0 ,3 ),DIV (0 ,"dout_aclk400_mscl" ,"mout_aclk400_mscl" ,DIV_TOP0 ,4 ,3 ),
Signature · 1 line
1.7.9.5
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));
I believe "div_core2" should work fine here for all SoCs without the need for this if.
Quoted 6 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0
[snip]
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));
Similarly here, no need for this change.
Best regards,
Tomasz
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Hi Tomasz,
Quoted 8 lines · Tomasz Figa
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
Quoted 9 lines
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));I believe "
div_core2" should work fine here for all SoCs without the need for this if.
The following patch is a pre-requisite for this patch.
http://www.spinics.net/lists/arm-kernel/msg351540.html
The rate can be obtained from div_core2 as well but with the cpu clock now registered, the rate can be obtained from the cpu clock instance instead of the div_core2 divider. And when Exynos4412 also add cpu clock instance, the 'if' above will be removed.
Quoted 10 lines
Quoted 7 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0[snip]
Quoted 8 lines
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));Similarly here, no need for this change.
Same here. Instead of getting the rate from div_core2 divider block, the cpu clock instance is used to find the rate. I would prefer to use cpu clock here. Is there any reason to prefer div_core2 over the cpu clock instance?
Thanks,
Thomas.
Quoted 8 lines
Best regards,
Tomasz_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Quoted 48 lines · Thomas Abraham
Hi Tomasz,
Quoted 8 lines · Tomasz Figa
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
Quoted 9 lines
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));I believe "
div_core2" should work fine here for all SoCs without the need for this if.The following patch is a pre-requisite for this patch.
http://www.spinics.net/lists/arm-kernel/msg351540.htmlThe rate can be obtained from
div_core2as well but with the cpu clock now registered, the rate can be obtained from the cpu clock instance instead of thediv_core2divider. And when Exynos4412 also add cpu clock instance, the 'if' above will be removed.Quoted 10 lines
Quoted 7 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0[snip]
Quoted 8 lines
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));Similarly here, no need for this change.
Quoted 4 lines
Same here. Instead of getting the rate from
div_core2divider block, the cpu clock instance is used to find the rate. I would prefer to use cpu clock here. Is there any reason to preferdiv_core2over the cpu clock instance?
Well, the reason is simple: if you don't need to change something (i.e. the change doesn't have any advantages), don't change it.
There is no difference between obtaining the rate from div_{arm,core}2 and armclk, so I don't see the point of changing this.
In fact now when thinking of it, this has revealed one hole that will be unhandled by your code - if cpufreq is disabled and the bootloader configures div_{arm,core}{,2} with non-zero values, armclk will return incorrect rate. However since I haven't observed such case on existing platforms, fixing this might be done on top of this series, in a separate patch.
Best regards,
Tomasz
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Quoted 49 lines · Tomasz Figa
Quoted 48 lines · Thomas Abraham
Hi Tomasz,
Quoted 8 lines · Tomasz Figa
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
Quoted 9 lines
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));I believe "
div_core2" should work fine here for all SoCs without the need for this if.The following patch is a pre-requisite for this patch.
http://www.spinics.net/lists/arm-kernel/msg351540.htmlThe rate can be obtained from
div_core2as well but with the cpu clock now registered, the rate can be obtained from the cpu clock instance instead of thediv_core2divider. And when Exynos4412 also add cpu clock instance, the 'if' above will be removed.Quoted 18 lines
Quoted 7 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0[snip]
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));Similarly here, no need for this change.
Quoted 7 lines
Quoted 4 lines
Same here. Instead of getting the rate from
div_core2divider block, the cpu clock instance is used to find the rate. I would prefer to use cpu clock here. Is there any reason to preferdiv_core2over the cpu clock instance?Well, the reason is simple: if you don't need to change something (i.e. the change doesn't have any advantages), don't change it.
The advantage with using cpu clock would be that get_rate can obtain the cached rate whereas when reading div_core2 rate, the clock tree will have to be traversed to determine the rate.
Quoted 10 lines
There is no difference between obtaining the rate from div_{arm,core}2 and armclk, so I don't see the point of changing this.
In fact now when thinking of it, this has revealed one hole that will be unhandled by your code - if cpufreq is disabled and the bootloader configures div_{arm,core}{,2} with non-zero values, armclk will return incorrect rate. However since I haven't observed such case on existing platforms, fixing this might be done on top of this series, in a separate patch.
Right. I will fix this later.
Thanks,
Thomas.
Quoted 3 lines
Best regards,
Tomasz
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Quoted 55 lines · Thomas Abraham
Quoted 54 lines · Tomasz Figa
Quoted 52 lines · Thomas Abraham
Hi Tomasz,
Quoted 8 lines · Tomasz Figa
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
Quoted 9 lines
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));I believe "
div_core2" should work fine here for all SoCs without the need for this if.The following patch is a pre-requisite for this patch.
http://www.spinics.net/lists/arm-kernel/msg351540.htmlThe rate can be obtained from
div_core2as well but with the cpu clock now registered, the rate can be obtained from the cpu clock instance instead of thediv_core2divider. And when Exynos4412 also add cpu clock instance, the 'if' above will be removed.Quoted 10 lines
Quoted 7 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0[snip]
Quoted 8 lines
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));Similarly here, no need for this change.
Same here. Instead of getting the rate from
div_core2divider block, the cpu clock instance is used to find the rate. I would prefer to use cpu clock here. Is there any reason to preferdiv_core2over the cpu clock instance?
Quoted 7 lines
Quoted 2 lines
Well, the reason is simple: if you don't need to change something (i.e. the change doesn't have any advantages), don't change it.
The advantage with using cpu clock would be that
get_ratecan obtain the cached rate whereas when readingdiv_core2rate, the clock tree will have to be traversed to determine the rate.
This is just one time printk at initialization, so still no real benefits. :)
Well anyway, if you really don't want to undo this change, then I guess I can live with it.
Best regards,
Tomasz
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
Quoted 64 lines · Tomasz Figa
Quoted 55 lines · Thomas Abraham
Quoted 54 lines · Tomasz Figa
Quoted 52 lines · Thomas Abraham
Hi Tomasz,
Quoted 8 lines · Tomasz Figa
Quoted 4 lines · Thomas Abraham
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
[snip]
Quoted 9 lines
drivers/clk/samsung/clk-exynos4.c static void __init exynos4_clk_init(struct device_node *np, · line 1503
Quoted 6 lines
drivers/clk/samsung/clk-exynos4.c +1
-0@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2"));I believe "
div_core2" should work fine here for all SoCs without the need for this if.The following patch is a pre-requisite for this patch.
http://www.spinics.net/lists/arm-kernel/msg351540.htmlThe rate can be obtained from
div_core2as well but with the cpu clock now registered, the rate can be obtained from the cpu clock instance instead of thediv_core2divider. And when Exynos4412 also add cpu clock instance, the 'if' above will be removed.Quoted 10 lines
Quoted 7 lines
(quoted diff) +0
-0}drivers/clk/samsung/clk-exynos5250.c +0
-0[snip]
Quoted 8 lines
drivers/clk/samsung/clk-exynos5250.c static void __init exynos5250_clk_init(struct device_node *np) · line 854
Quoted 6 lines
drivers/clk/samsung/clk-exynos5250.c +1
-1@@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" ));Similarly here, no need for this change.
Same here. Instead of getting the rate from
div_core2divider block, the cpu clock instance is used to find the rate. I would prefer to use cpu clock here. Is there any reason to preferdiv_core2over the cpu clock instance?Quoted 7 lines
Quoted 2 lines
Well, the reason is simple: if you don't need to change something (i.e. the change doesn't have any advantages), don't change it.
The advantage with using cpu clock would be that
get_ratecan obtain the cached rate whereas when readingdiv_core2rate, the clock tree will have to be traversed to determine the rate.
Quoted 5 lines
This is just one time printk at initialization, so still no real benefits. :)
Well anyway, if you really don't want to undo this change, then I guess I can live with it.
Thanks Tomasz. Probably, I would just use cpu clock for now.
Quoted 3 lines
Best regards,
Tomasz
PATCH v9 6/6 clk: samsung: remove unused clock aliases and update clock flags
In reply to Thomas AbrahamQuoting Thomas Abraham (2014-07-30 01:07:43)
Quoted 7 lines
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers, the unused clock aliases can be removed. In addition to this, the individual clock blocks which are now encapsulated with the consolidate CPU clock type can now be marked with read-only flags.
Cc Tomasz Figa <[email protected]>Signed-off-by Thomas Abraham <[email protected]>
Quoted 205 lines
--- drivers/clk/samsung/clk-exynos4.c | 48 +++++++++++++++++----------------- drivers/clk/samsung/clk-exynos5250.c | 19 ++++++++------ drivers/clk/samsung/clk-exynos5420.c | 27 ++++++++++++------- 3 files changed, 53 insertions(+), 41 deletions(-)drivers/clk/samsung/clk-exynos4.c +24
-24@@ -578,7 +578,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 (0 ,"mout_hpm" , mout_core_p4210,SRC_CPU ,20 ,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),@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[] __initdata = {DIV (0 ,"div_clkout_rightbus" ,"mout_clkout_rightbus" ,CLKOUT_CMU_RIGHTBUS ,8 ,6 ), -DIV (0 ,"div_core" ,"mout_core" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"div_corem0" ,"div_core2" ,DIV_CPU0 ,4 ,3 ), -DIV (0 ,"div_corem1" ,"div_core2" ,DIV_CPU0 ,8 ,3 ), -DIV (0 ,"div_periph" ,"div_core2" ,DIV_CPU0 ,12 ,3 ), -DIV (0 ,"div_atb" ,"mout_core" ,DIV_CPU0 ,16 ,3 ), -DIV (0 ,"div_pclk_dbg" ,"div_atb" ,DIV_CPU0 ,20 ,3 ), -DIV (CLK_ARM_CLK ,"div_core2" ,"div_core" ,DIV_CPU0 ,28 ,3 ), -DIV (0 ,"div_copy" ,"mout_hpm" ,DIV_CPU1 ,0 ,3 ), -DIV (0 ,"div_hpm" ,"div_copy" ,DIV_CPU1 ,4 ,3 ), +DIV_F (0 ,"div_core" ,"mout_core" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_corem0" ,"div_core2" ,DIV_CPU0 ,4 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_corem1" ,"div_core2" ,DIV_CPU0 ,8 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_periph" ,"div_core2" ,DIV_CPU0 ,12 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_atb" ,"mout_core" ,DIV_CPU0 ,16 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_pclk_dbg" ,"div_atb" ,DIV_CPU0 ,20 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (CLK_ARM_CLK ,"div_core2" ,"div_core" ,DIV_CPU0 ,28 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_copy" ,"mout_hpm" ,DIV_CPU1 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_hpm" ,"div_copy" ,DIV_CPU1 ,4 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ),DIV (0 ,"div_clkout_cpu" ,"mout_clkout_cpu" ,CLKOUT_CMU_CPU ,8 ,6 ), DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),@@ -770,7 +780,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_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 ,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,@@ -1187,17 +1198,10 @@ static struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = { 0), }; -static struct samsung_clock_alias exynos4_aliases[]__initdata = { +static struct samsung_clock_alias exynos4x12_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" ), -}; - -static struct samsung_clock_alias exynos4x12_aliases[]__initdata = {ALIAS (CLK_MOUT_MPLL_USER_C ,NULL ,"mout_mpll" ), };@@ -1464,8 +1468,6 @@ static void __init exynos4_clk_init(struct device_node *np, ARRAY_SIZE(exynos4210_div_clks));samsung_clk_register_gate (ctx, exynos4210_gate_clks,ARRAY_SIZE (exynos4210_gate_clks)); -samsung_clk_register_alias (ctx, exynos4210_aliases, -ARRAY_SIZE (exynos4210_aliases));samsung_clk_register_fixed_factor (ctx, exynos4210_fixed_factor_clks,ARRAY_SIZE (exynos4210_fixed_factor_clks));@@ -1487,9 +1489,6 @@ static void __init exynos4_clk_init(struct device_node *np, ARRAY_SIZE(exynos4x12_fixed_factor_clks)); } -samsung_clk_register_alias (ctx, exynos4_aliases, -ARRAY_SIZE (exynos4_aliases)); -exynos4_core_down_clock (soc);exynos4_clk_sleep_init ();@@ -1500,6 +1499,7 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_soc ==EXYNOS4210 ?"Exynos4210" :"Exynos4x12" ,_get_rate ("sclk_apll" ),_get_rate ("sclk_mpll" ),_get_rate ("sclk_epll" ),_get_rate ("sclk_vpll" ), + exynos4_soc ==EXYNOS4210 ?_get_rate ("armclk" ) : _get_rate("div_core2")); }drivers/clk/samsung/clk-exynos5250.c +11
-8@@ -291,14 +291,14 @@ static struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {/* * CMU_CPU */ -MUX_FA (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , -CLK_SET_RATE_PARENT ,0 ,"mout_apll" ), -MUX_A (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,"mout_cpu" ), +MUX_F (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,0 ,CLK_MUX_READ_ONLY ),/* * CMU_CORE */ - MUX_A(0, "mout_mpll", mout_mpll_p, SRC_CORE1, 8, 1, "mout_mpll"), + MUX(0, "mout_mpll", mout_mpll_p, SRC_CORE1, 8, 1),/* * CMU_TOP @@ -380,9 +380,12 @@ static struct samsung_div_clock exynos5250_div_clks[] __initdata = {/* * CMU_CPU */ -DIV (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"div_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 ), - DIV_A(0, "div_arm2", "div_arm", DIV_CPU0, 28, 3, "armclk"), +DIV_F (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_arm2" ,"div_arm" ,DIV_CPU0 ,28 ,3 , + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),/* * CMU_TOP @@ -848,6 +851,6 @@ static void __init exynos5250_clk_init(struct device_node *np)samsung_clk_of_add_provider (np, ctx);pr_info ("Exynos5250: clock setup completed, armclk=%ld\n" , -_get_rate ("div_arm2" )); +_get_rate ("armclk" )); }CLK_OF_DECLARE (exynos5250_clk,"samsung,exynos5250-clock" , exynos5250_clk_init);drivers/clk/samsung/clk-exynos5420.c +18
-9@@ -617,10 +617,14 @@ static struct samsung_mux_clock exynos5x_mux_clks[] __initdata = {MUX (0 ,"mout_mspll_kfc" , mout_mspll_cpu_p,SRC_TOP7 ,8 ,2 ),MUX (0 ,"mout_mspll_cpu" , mout_mspll_cpu_p,SRC_TOP7 ,12 ,2 ), -MUX (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 ), -MUX (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ), -MUX (0 ,"mout_kpll" , mout_kpll_p,SRC_KFC ,0 ,1 ), -MUX (0 ,"mout_kfc" , mout_kfc_p,SRC_KFC ,16 ,1 ), +MUX_F (0 ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_cpu" , mout_cpu_p,SRC_CPU ,16 ,1 ,0 , +CLK_MUX_READ_ONLY ), +MUX_F (0 ,"mout_kpll" , mout_kpll_p,SRC_KFC ,0 ,1 , +CLK_SET_RATE_PARENT ,0 ), +MUX_F (0 ,"mout_kfc" , mout_kfc_p,SRC_KFC ,16 ,1 ,0 , +CLK_MUX_READ_ONLY ),MUX (0 ,"mout_aclk200" , mout_group1_p,SRC_TOP0 ,8 ,2 ), MUX(0, "mout_aclk200_fsys2", mout_group1_p, SRC_TOP0, 12, 2),@@ -776,11 +780,16 @@ static struct samsung_mux_clock exynos5x_mux_clks[] __initdata = { };static struct samsung_div_clock exynos5x_div_clks[]__initdata = { -DIV (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 ), -DIV (0 ,"sclk_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 ), -DIV (0 ,"armclk2" ,"div_arm" ,DIV_CPU0 ,28 ,3 ), -DIV (0 ,"div_kfc" ,"mout_kfc" ,DIV_KFC0 ,0 ,3 ), -DIV (0 ,"sclk_kpll" ,"mout_kpll" ,DIV_KFC0 ,24 ,3 ), +DIV_F (0 ,"div_arm" ,"mout_cpu" ,DIV_CPU0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"sclk_apll" ,"mout_apll" ,DIV_CPU0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"armclk2" ,"div_arm" ,DIV_CPU0 ,28 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"div_kfc" ,"mout_kfc" ,DIV_KFC0 ,0 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ), +DIV_F (0 ,"sclk_kpll" ,"mout_kpll" ,DIV_KFC0 ,24 ,3 , +CLK_GET_RATE_NOCACHE ,CLK_DIVIDER_READ_ONLY ),DIV (0 ,"dout_aclk400_isp" ,"mout_aclk400_isp" ,DIV_TOP0 ,0 ,3 ),DIV (0 ,"dout_aclk400_mscl" ,"mout_aclk400_mscl" ,DIV_TOP0 ,4 ,3 ),Signature · 1 line
1.7.9.5
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
In reply to Thomas AbrahamQuoted 52 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.htmlThomas Abraham (6):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: add cpu clock configuration data and instantiate cpu clock
ARM: dts: Exynos: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
clk: samsung: remove unused clock aliases and update clock flagsarch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- arch/arm/boot/dts/exynos5250-arndale.dts | 4 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 + arch/arm/boot/dts/exynos5250-snow.dts | 4 + arch/arm/boot/dts/exynos5250.dtsi | 25 +- arch/arm/boot/dts/exynos5420.dtsi | 38 +++ arch/arm/mach-exynos/exynos.c | 24 +- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 ++++++ drivers/clk/samsung/clk-exynos4.c | 63 +++-- drivers/clk/samsung/clk-exynos5250.c | 44 ++- drivers/clk/samsung/clk-exynos5420.c | 72 ++++- 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 + 22 files changed, 690 insertions(+), 463 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
Quoted 2 lines
--
1.7.9.5
Working great.
tested on smdk5420, and arndale-5250
Quoted 8 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
thanks and regards, Chander M. Kashyap Contact Number: +918123738320 ------- TENSION LENE KA NAHI, DENE KE-----
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Quoted 53 lines · Chander M. Kashyap
Quoted 52 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.htmlThomas Abraham (6):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: add cpu clock configuration data and instantiate cpu clock
ARM: dts: Exynos: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
clk: samsung: remove unused clock aliases and update clock flagsarch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- arch/arm/boot/dts/exynos5250-arndale.dts | 4 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 + arch/arm/boot/dts/exynos5250-snow.dts | 4 + arch/arm/boot/dts/exynos5250.dtsi | 25 +- arch/arm/boot/dts/exynos5420.dtsi | 38 +++ arch/arm/mach-exynos/exynos.c | 24 +- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 ++++++ drivers/clk/samsung/clk-exynos4.c | 63 +++-- drivers/clk/samsung/clk-exynos5250.c | 44 ++- drivers/clk/samsung/clk-exynos5420.c | 72 ++++- 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 + 22 files changed, 690 insertions(+), 463 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
Quoted 5 lines
Quoted 2 lines
--
1.7.9.5Working great.
tested on smdk5420, and arndale-5250
Hi Chander,
Thanks for testing this series. Can I add a "Tested-by" tag for this series?
Thanks,
Thomas.
Quoted 22 lines
Quoted 9 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel--
thanks and regards,
Chander M. Kashyap
Contact Number: +918123738320
------- TENSION LENE KA NAHI, DENE KE-----_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Quoted 58 lines · Thomas Abraham
Quoted 56 lines · Chander M. Kashyap
Quoted 54 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.htmlThomas Abraham (6):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: add cpu clock configuration data and instantiate cpu clock
ARM: dts: Exynos: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
clk: samsung: remove unused clock aliases and update clock flagsarch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- arch/arm/boot/dts/exynos5250-arndale.dts | 4 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 + arch/arm/boot/dts/exynos5250-snow.dts | 4 + arch/arm/boot/dts/exynos5250.dtsi | 25 +- arch/arm/boot/dts/exynos5420.dtsi | 38 +++ arch/arm/mach-exynos/exynos.c | 24 +- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 335 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 91 ++++++ drivers/clk/samsung/clk-exynos4.c | 63 +++-- drivers/clk/samsung/clk-exynos5250.c | 44 ++- drivers/clk/samsung/clk-exynos5420.c | 72 ++++- 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 + 22 files changed, 690 insertions(+), 463 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c--
1.7.9.5
Quoted 6 lines
Quoted 2 lines
Working great.
tested on smdk5420, and arndale-5250Hi Chander,
Thanks for testing this series. Can I add a "Tested-by" tag for this series?
sure you can.
Quoted 26 lines
Thanks,
Thomas.Quoted 22 lines
Quoted 9 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel--
thanks and regards,
Chander M. Kashyap
Contact Number: +918123738320
------- TENSION LENE KA NAHI, DENE KE-----_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
thanks and regards, Chander M. Kashyap Contact Number: +918123738320 ------- TENSION LENE KA NAHI, DENE KE-----
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
In reply to Thomas AbrahamHi Thomas,
Quoted 8 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.
Quoted 7 lines
This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.html
I think we are at final stage of works on this series. Thanks for your cooperation.
After addressing remaining minor comments from this thread, feel free to add:
Best regards,
Tomasz
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Quoted 19 lines · Tomasz Figa
Hi Thomas,
Quoted 8 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.Quoted 7 lines
This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.html
Quoted 7 lines
I think we are at final stage of works on this series. Thanks for your cooperation.
After addressing remaining minor comments from this thread, feel free to add:
Reviewed-by Tomasz Figa <[email protected]>
Hi Tomasz,
Thanks for your review of this series. Your review comments has helped to make this series better.
Regards,
Thomas.
Quoted 7 lines
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Hi Viresh,
Quoted 20 lines · Thomas Abraham
Quoted 19 lines · Tomasz Figa
Hi Thomas,
Quoted 15 lines · Thomas Abraham
Changes since v8:
- Fixes suggested by Tomasz Figa.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 enables cpufreq support for Exynos5420 using
arm_big_littlecpufreq driver.This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
- http://www.spinics.net/lists/arm-kernel/msg351134.html
3. clk: exynos4: remove duplicatediv_core2divider clock instantiation
- http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34859.html
Quoted 7 lines
Quoted 7 lines
I think we are at final stage of works on this series. Thanks for your cooperation.
After addressing remaining minor comments from this thread, feel free to add:
Reviewed-by Tomasz Figa <[email protected]>
You had acked the cpufreq related changes in v7 of this series. But there were some changes in v8 and so I have not included your Ack for v8 and v9. Could you please have one more look at the patches 4/6 [1] and 5/6 [2] of this v9 series and let me know if it looks okay.
[1] http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34865.html
[2] http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34864.html
Thanks,
Thomas.
Quoted 16 lines
Hi Tomasz,
Thanks for your review of this series. Your review comments has helped to make this series better.
Regards,
Thomas.Quoted 7 lines
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Viresh Kumar
maintainerv9 cover cpufreq: use generic cpufreq drivers for exynos platforms
Quoted 7 lines · Thomas Abraham
You had acked the cpufreq related changes in v7 of this series. But there were some changes in v8 and so I have not included your Ack for v8 and v9. Could you please have one more look at the patches 4/6 [1] and 5/6 [2] of this v9 series and let me know if it looks okay.
[1] http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34865.html
[2] http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34864.html
Looks fine..