* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
@ 2014-07-30 8:07 Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
` (7 more replies)
0 siblings, 8 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.9.5
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-09-01 22:29 ` Mike Turquette
2014-07-30 8:07 ` [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
` (6 subsequent siblings)
7 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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 <thomas.ab@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
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
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..8909c93 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 0000000..009a21b
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham <thomas.ab@samsung.com>
+ *
+ * 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;
+}
diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
new file mode 100644
index 0000000..42e1905
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.h
@@ -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@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 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-09-01 22:29 ` Mike Turquette
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
` (5 subsequent siblings)
7 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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 <t.figa@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
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(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 8617f49..101f549 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -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));
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..e19e365 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -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
diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 848d602..d7ef36a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -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);
diff --git a/include/dt-bindings/clock/exynos5250.h b/include/dt-bindings/clock/exynos5250.h
index 4273891..8183d1c 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -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
diff --git a/include/dt-bindings/clock/exynos5420.h b/include/dt-bindings/clock/exynos5420.h
index 8dc0913..ec0af64 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-07-30 11:28 ` Andreas Färber
` (2 more replies)
2014-07-30 8:07 ` [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
` (4 subsequent siblings)
7 siblings, 3 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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 <kgene.kim@samsung.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
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(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
index f767c42..887dded 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -334,3 +334,7 @@
};
};
};
+
+&cpu0 {
+ cpu0-supply = <&buck1_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..66119dd 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -446,3 +446,7 @@
};
};
};
+
+&cpu0 {
+ cpu0-supply = <&varm_breg>;
+};
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..bf0a39c 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -492,3 +492,7 @@
&mdma1 {
reg = <0x12840000 0x1000>;
};
+
+&cpu0 {
+ cpu0-supply = <&vdd_arm_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..69bac07 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -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 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = <&usb2_phy>;
};
};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,7 @@
};
};
};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
+
#include "cros-ec-keyboard.dtsi"
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -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";
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..3154b4c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -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>;
};
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
` (2 preceding siblings ...)
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-07-31 18:32 ` Kukjin Kim
2014-07-30 8:07 ` [PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support Thomas Abraham
` (3 subsequent siblings)
7 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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 <t.figa@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
arch/arm/mach-exynos/exynos.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 493dbc2..e61bb36 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -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);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
` (3 preceding siblings ...)
2014-07-30 8:07 ` [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
` (2 subsequent siblings)
7 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
Exynos4210 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.
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
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
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7364a53..f81fc3e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -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
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..fac36ef 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -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
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c b/drivers/cpufreq/exynos4210-cpufreq.c
deleted file mode 100644
index 61a5431..0000000
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4210 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/slab.h>
-#include <linux/cpufreq.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-
-#include "exynos-cpufreq.h"
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
-
-static unsigned int exynos4210_volt_table[] = {
- 1250000, 1150000, 1050000, 975000, 950000,
-};
-
-static struct cpufreq_frequency_table exynos4210_freq_table[] = {
- {0, L0, 1200 * 1000},
- {0, L1, 1000 * 1000},
- {0, L2, 800 * 1000},
- {0, L3, 500 * 1000},
- {0, L4, 200 * 1000},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_4210[] = {
- /*
- * values:
- * freq
- * clock divider for CORE, COREM0, COREM1, PERIPH, ATB, PCLK_DBG, APLL, RESERVED
- * clock divider for COPY, HPM, RESERVED
- * PLL M, P, S
- */
- APLL_FREQ(1200, 0, 3, 7, 3, 4, 1, 7, 0, 5, 0, 0, 150, 3, 1),
- APLL_FREQ(1000, 0, 3, 7, 3, 4, 1, 7, 0, 4, 0, 0, 250, 6, 1),
- APLL_FREQ(800, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 200, 6, 1),
- APLL_FREQ(500, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 250, 6, 2),
- APLL_FREQ(200, 0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
-};
-
-static void exynos4210_set_clkdiv(unsigned int div_index)
-{
- unsigned int tmp;
-
- /* Change Divider - CPU0 */
-
- tmp = apll_freq_4210[div_index].clk_div_cpu0;
-
- __raw_writel(tmp, cpufreq->cmu_regs + EXYNOS4_CLKDIV_CPU);
-
- do {
- tmp = __raw_readl(cpufreq->cmu_regs + EXYNOS4_CLKDIV_STATCPU);
- } while (tmp & 0x1111111);
-
- /* Change Divider - CPU1 */
-
- tmp = apll_freq_4210[div_index].clk_div_cpu1;
-
- __raw_writel(tmp, cpufreq->cmu_regs + EXYNOS4_CLKDIV_CPU1);
-
- do {
- tmp = __raw_readl(cpufreq->cmu_regs + EXYNOS4_CLKDIV_STATCPU1);
- } while (tmp & 0x11);
-}
-
-static void exynos4210_set_apll(unsigned int index)
-{
- unsigned int tmp, freq = apll_freq_4210[index].freq;
-
- /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
- clk_set_parent(moutcore, mout_mpll);
-
- do {
- tmp = (__raw_readl(cpufreq->cmu_regs + EXYNOS4_CLKMUX_STATCPU)
- >> EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT);
- tmp &= 0x7;
- } while (tmp != 0x2);
-
- clk_set_rate(mout_apll, freq * 1000);
-
- /* MUX_CORE_SEL = APLL */
- clk_set_parent(moutcore, mout_apll);
-
- do {
- tmp = __raw_readl(cpufreq->cmu_regs + EXYNOS4_CLKMUX_STATCPU);
- tmp &= EXYNOS4_CLKMUX_STATCPU_MUXCORE_MASK;
- } while (tmp != (0x1 << EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
-}
-
-static void exynos4210_set_frequency(unsigned int old_index,
- unsigned int new_index)
-{
- if (old_index > new_index) {
- exynos4210_set_clkdiv(new_index);
- exynos4210_set_apll(new_index);
- } else if (old_index < new_index) {
- exynos4210_set_apll(new_index);
- exynos4210_set_clkdiv(new_index);
- }
-}
-
-int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
-{
- struct device_node *np;
- unsigned long rate;
-
- /*
- * HACK: This is a temporary workaround to get access to clock
- * controller registers directly and remove static mappings and
- * dependencies on platform headers. It is necessary to enable
- * Exynos multi-platform support and will be removed together with
- * this whole driver as soon as Exynos gets migrated to use
- * cpufreq-cpu0 driver.
- */
- np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-clock");
- if (!np) {
- pr_err("%s: failed to find clock controller DT node\n",
- __func__);
- return -ENODEV;
- }
-
- info->cmu_regs = of_iomap(np, 0);
- if (!info->cmu_regs) {
- pr_err("%s: failed to map CMU registers\n", __func__);
- return -EFAULT;
- }
-
- cpu_clk = clk_get(NULL, "armclk");
- if (IS_ERR(cpu_clk))
- return PTR_ERR(cpu_clk);
-
- moutcore = clk_get(NULL, "moutcore");
- if (IS_ERR(moutcore))
- goto err_moutcore;
-
- mout_mpll = clk_get(NULL, "mout_mpll");
- if (IS_ERR(mout_mpll))
- goto err_mout_mpll;
-
- rate = clk_get_rate(mout_mpll) / 1000;
-
- mout_apll = clk_get(NULL, "mout_apll");
- if (IS_ERR(mout_apll))
- goto err_mout_apll;
-
- info->mpll_freq_khz = rate;
- /* 800Mhz */
- info->pll_safe_idx = L2;
- info->cpu_clk = cpu_clk;
- info->volt_table = exynos4210_volt_table;
- info->freq_table = exynos4210_freq_table;
- info->set_freq = exynos4210_set_frequency;
-
- cpufreq = info;
-
- return 0;
-
-err_mout_apll:
- clk_put(mout_mpll);
-err_mout_mpll:
- clk_put(moutcore);
-err_moutcore:
- clk_put(cpu_clk);
-
- pr_debug("%s: failed initialization\n", __func__);
- return -EINVAL;
-}
diff --git a/drivers/cpufreq/exynos5250-cpufreq.c b/drivers/cpufreq/exynos5250-cpufreq.c
deleted file mode 100644
index c91ce69..0000000
--- a/drivers/cpufreq/exynos5250-cpufreq.c
+++ /dev/null
@@ -1,210 +0,0 @@
-/*
- * Copyright (c) 2010-20122Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS5250 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/slab.h>
-#include <linux/cpufreq.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-
-#include "exynos-cpufreq.h"
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
-
-static unsigned int exynos5250_volt_table[] = {
- 1300000, 1250000, 1225000, 1200000, 1150000,
- 1125000, 1100000, 1075000, 1050000, 1025000,
- 1012500, 1000000, 975000, 950000, 937500,
- 925000
-};
-
-static struct cpufreq_frequency_table exynos5250_freq_table[] = {
- {0, L0, 1700 * 1000},
- {0, L1, 1600 * 1000},
- {0, L2, 1500 * 1000},
- {0, L3, 1400 * 1000},
- {0, L4, 1300 * 1000},
- {0, L5, 1200 * 1000},
- {0, L6, 1100 * 1000},
- {0, L7, 1000 * 1000},
- {0, L8, 900 * 1000},
- {0, L9, 800 * 1000},
- {0, L10, 700 * 1000},
- {0, L11, 600 * 1000},
- {0, L12, 500 * 1000},
- {0, L13, 400 * 1000},
- {0, L14, 300 * 1000},
- {0, L15, 200 * 1000},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_5250[] = {
- /*
- * values:
- * freq
- * clock divider for ARM, CPUD, ACP, PERIPH, ATB, PCLK_DBG, APLL, ARM2
- * clock divider for COPY, HPM, RESERVED
- * PLL M, P, S
- */
- APLL_FREQ(1700, 0, 3, 7, 7, 7, 3, 5, 0, 0, 2, 0, 425, 6, 0),
- APLL_FREQ(1600, 0, 3, 7, 7, 7, 1, 4, 0, 0, 2, 0, 200, 3, 0),
- APLL_FREQ(1500, 0, 2, 7, 7, 7, 1, 4, 0, 0, 2, 0, 250, 4, 0),
- APLL_FREQ(1400, 0, 2, 7, 7, 6, 1, 4, 0, 0, 2, 0, 175, 3, 0),
- APLL_FREQ(1300, 0, 2, 7, 7, 6, 1, 3, 0, 0, 2, 0, 325, 6, 0),
- APLL_FREQ(1200, 0, 2, 7, 7, 5, 1, 3, 0, 0, 2, 0, 200, 4, 0),
- APLL_FREQ(1100, 0, 3, 7, 7, 5, 1, 3, 0, 0, 2, 0, 275, 6, 0),
- APLL_FREQ(1000, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 125, 3, 0),
- APLL_FREQ(900, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 150, 4, 0),
- APLL_FREQ(800, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 100, 3, 0),
- APLL_FREQ(700, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 175, 3, 1),
- APLL_FREQ(600, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 200, 4, 1),
- APLL_FREQ(500, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 125, 3, 1),
- APLL_FREQ(400, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 100, 3, 1),
- APLL_FREQ(300, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 200, 4, 2),
- APLL_FREQ(200, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 100, 3, 2),
-};
-
-static void set_clkdiv(unsigned int div_index)
-{
- unsigned int tmp;
-
- /* Change Divider - CPU0 */
-
- tmp = apll_freq_5250[div_index].clk_div_cpu0;
-
- __raw_writel(tmp, cpufreq->cmu_regs + EXYNOS5_CLKDIV_CPU0);
-
- while (__raw_readl(cpufreq->cmu_regs + EXYNOS5_CLKDIV_STATCPU0)
- & 0x11111111)
- cpu_relax();
-
- /* Change Divider - CPU1 */
- tmp = apll_freq_5250[div_index].clk_div_cpu1;
-
- __raw_writel(tmp, cpufreq->cmu_regs + EXYNOS5_CLKDIV_CPU1);
-
- while (__raw_readl(cpufreq->cmu_regs + EXYNOS5_CLKDIV_STATCPU1) & 0x11)
- cpu_relax();
-}
-
-static void set_apll(unsigned int index)
-{
- unsigned int tmp;
- unsigned int freq = apll_freq_5250[index].freq;
-
- /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
- clk_set_parent(moutcore, mout_mpll);
-
- do {
- cpu_relax();
- tmp = (__raw_readl(cpufreq->cmu_regs + EXYNOS5_CLKMUX_STATCPU)
- >> 16);
- tmp &= 0x7;
- } while (tmp != 0x2);
-
- clk_set_rate(mout_apll, freq * 1000);
-
- /* MUX_CORE_SEL = APLL */
- clk_set_parent(moutcore, mout_apll);
-
- do {
- cpu_relax();
- tmp = __raw_readl(cpufreq->cmu_regs + EXYNOS5_CLKMUX_STATCPU);
- tmp &= (0x7 << 16);
- } while (tmp != (0x1 << 16));
-}
-
-static void exynos5250_set_frequency(unsigned int old_index,
- unsigned int new_index)
-{
- if (old_index > new_index) {
- set_clkdiv(new_index);
- set_apll(new_index);
- } else if (old_index < new_index) {
- set_apll(new_index);
- set_clkdiv(new_index);
- }
-}
-
-int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
-{
- struct device_node *np;
- unsigned long rate;
-
- /*
- * HACK: This is a temporary workaround to get access to clock
- * controller registers directly and remove static mappings and
- * dependencies on platform headers. It is necessary to enable
- * Exynos multi-platform support and will be removed together with
- * this whole driver as soon as Exynos gets migrated to use
- * cpufreq-cpu0 driver.
- */
- np = of_find_compatible_node(NULL, NULL, "samsung,exynos5250-clock");
- if (!np) {
- pr_err("%s: failed to find clock controller DT node\n",
- __func__);
- return -ENODEV;
- }
-
- info->cmu_regs = of_iomap(np, 0);
- if (!info->cmu_regs) {
- pr_err("%s: failed to map CMU registers\n", __func__);
- return -EFAULT;
- }
-
- cpu_clk = clk_get(NULL, "armclk");
- if (IS_ERR(cpu_clk))
- return PTR_ERR(cpu_clk);
-
- moutcore = clk_get(NULL, "mout_cpu");
- if (IS_ERR(moutcore))
- goto err_moutcore;
-
- mout_mpll = clk_get(NULL, "mout_mpll");
- if (IS_ERR(mout_mpll))
- goto err_mout_mpll;
-
- rate = clk_get_rate(mout_mpll) / 1000;
-
- mout_apll = clk_get(NULL, "mout_apll");
- if (IS_ERR(mout_apll))
- goto err_mout_apll;
-
- info->mpll_freq_khz = rate;
- /* 800Mhz */
- info->pll_safe_idx = L9;
- info->cpu_clk = cpu_clk;
- info->volt_table = exynos5250_volt_table;
- info->freq_table = exynos5250_freq_table;
- info->set_freq = exynos5250_set_frequency;
-
- cpufreq = info;
-
- return 0;
-
-err_mout_apll:
- clk_put(mout_mpll);
-err_mout_mpll:
- clk_put(moutcore);
-err_moutcore:
- clk_put(cpu_clk);
-
- pr_err("%s: failed initialization\n", __func__);
- return -EINVAL;
-}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
` (4 preceding siblings ...)
2014-07-30 8:07 ` [PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support Thomas Abraham
@ 2014-07-30 8:07 ` Thomas Abraham
2014-07-31 14:13 ` Tomasz Figa
2014-09-01 22:31 ` Mike Turquette
2014-07-31 6:20 ` [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Chander M. Kashyap
2014-07-31 14:15 ` Tomasz Figa
7 siblings, 2 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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 <t.figa@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
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(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 101f549..04619a1 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -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"));
}
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index e19e365..1d958f1 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -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);
diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index d7ef36a..fcf365d 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -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),
--
1.7.9.5
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
@ 2014-07-30 11:28 ` Andreas Färber
2014-07-31 2:55 ` Thomas Abraham
2014-07-31 0:37 ` Doug Anderson
2014-08-02 3:49 ` Javier Martinez Canillas
2 siblings, 1 reply; 61+ messages in thread
From: Andreas Färber @ 2014-07-30 11:28 UTC (permalink / raw)
To: linux-arm-kernel
Am 30.07.2014 10:07, schrieb 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 <kgene.kim@samsung.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Sachin Kamat <sachin.kamat@linaro.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> 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(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index f767c42..887dded 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -334,3 +334,7 @@
> };
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&buck1_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
> index f516da9..66119dd 100644
> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> @@ -446,3 +446,7 @@
> };
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&varm_breg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> index d50eb3a..bf0a39c 100644
> --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
> +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> @@ -492,3 +492,7 @@
> &mdma1 {
> reg = <0x12840000 0x1000>;
> };
> +
> +&cpu0 {
> + cpu0-supply = <&vdd_arm_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index bcc9e63..69bac07 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -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
Nit: Here you left-align the columns ...
> + >;
> };
>
> cpu at 901 {
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..3b12a97 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -575,3 +575,7 @@
> usb-phy = <&usb2_phy>;
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index b4b35ad..f07e834 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -414,3 +414,7 @@
> };
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index f2b8c41..91acca7 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -509,4 +509,8 @@
> };
> };
>
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> +
> #include "cros-ec-keyboard.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 492e1ef..97b282c 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -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
... here you right-align both ...
> + >;
> };
> cpu at 1 {
> device_type = "cpu";
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index cb2b70e..3154b4c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -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
... but here only the left column.
> + >;
> };
>
> 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
Dito.
> + >;
> };
>
> 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>;
> };
> };
>
Since I don't really care which template you choose and can't judge most
numbers, FWIW
Reviewed-by: Andreas F?rber <afaerber@suse.de>
Thanks for resolving the conflict,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
2014-07-30 11:28 ` Andreas Färber
@ 2014-07-31 0:37 ` Doug Anderson
2014-07-31 3:21 ` Thomas Abraham
2014-08-02 3:49 ` Javier Martinez Canillas
2 siblings, 1 reply; 61+ messages in thread
From: Doug Anderson @ 2014-07-31 0:37 UTC (permalink / raw)
To: linux-arm-kernel
Thomas,
On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..3b12a97 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -575,3 +575,7 @@
> usb-phy = <&usb2_phy>;
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index b4b35ad..f07e834 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -414,3 +414,7 @@
> };
> };
> };
> +
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index f2b8c41..91acca7 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -509,4 +509,8 @@
> };
> };
>
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> +
> #include "cros-ec-keyboard.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 492e1ef..97b282c 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -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>;
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.
> + 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";
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index cb2b70e..3154b4c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -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>;
It does't start out at its maximum?
> 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>;
> };
> };
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-30 11:28 ` Andreas Färber
@ 2014-07-31 2:55 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 2:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 30, 2014 at 4:58 PM, Andreas F?rber <afaerber@suse.de> wrote:
> Am 30.07.2014 10:07, schrieb 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 <kgene.kim@samsung.com>
>> Cc: Doug Anderson <dianders@chromium.org>
>> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Cc: Andreas Faerber <afaerber@suse.de>
>> Cc: Sachin Kamat <sachin.kamat@linaro.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>> 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(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
>> index f767c42..887dded 100644
>> --- a/arch/arm/boot/dts/exynos4210-origen.dts
>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>> @@ -334,3 +334,7 @@
>> };
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&buck1_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
>> index f516da9..66119dd 100644
>> --- a/arch/arm/boot/dts/exynos4210-trats.dts
>> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
>> @@ -446,3 +446,7 @@
>> };
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&varm_breg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
>> index d50eb3a..bf0a39c 100644
>> --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
>> +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
>> @@ -492,3 +492,7 @@
>> &mdma1 {
>> reg = <0x12840000 0x1000>;
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&vdd_arm_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
>> index bcc9e63..69bac07 100644
>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> @@ -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
>
> Nit: Here you left-align the columns ...
>
>> + >;
>> };
>>
>> cpu at 901 {
>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>> index d0de1f5..3b12a97 100644
>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>> @@ -575,3 +575,7 @@
>> usb-phy = <&usb2_phy>;
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index b4b35ad..f07e834 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -414,3 +414,7 @@
>> };
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>> index f2b8c41..91acca7 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -509,4 +509,8 @@
>> };
>> };
>>
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> +
>> #include "cros-ec-keyboard.dtsi"
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index 492e1ef..97b282c 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -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
>
> ... here you right-align both ...
>
>> + >;
>> };
>> cpu at 1 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index cb2b70e..3154b4c 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -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
>
> ... but here only the left column.
>
>> + >;
>> };
>>
>> 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
>
> Dito.
>
>> + >;
>> };
>>
>> 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>;
>> };
>> };
>>
>
> Since I don't really care which template you choose and can't judge most
> numbers, FWIW
>
> Reviewed-by: Andreas F?rber <afaerber@suse.de>
>
> 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.
>
> --
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-31 0:37 ` Doug Anderson
@ 2014-07-31 3:21 ` Thomas Abraham
2014-07-31 3:53 ` Doug Anderson
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 3:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Doug,
On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson <dianders@chromium.org> wrote:
> Thomas,
>
> On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>> index d0de1f5..3b12a97 100644
>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>> @@ -575,3 +575,7 @@
>> usb-phy = <&usb2_phy>;
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index b4b35ad..f07e834 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -414,3 +414,7 @@
>> };
>> };
>> };
>> +
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>> index f2b8c41..91acca7 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -509,4 +509,8 @@
>> };
>> };
>>
>> +&cpu0 {
>> + cpu0-supply = <&buck2_reg>;
>> +};
>> +
>> #include "cros-ec-keyboard.dtsi"
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index 492e1ef..97b282c 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -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>;
>
> 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.
>
>
>> + 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";
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index cb2b70e..3154b4c 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -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>;
>
> 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.
>
>
>> 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>;
>> };
>> };
>
> 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.
>
> 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.
>
>
> -Doug
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-31 3:21 ` Thomas Abraham
@ 2014-07-31 3:53 ` Doug Anderson
2014-07-31 4:06 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Doug Anderson @ 2014-07-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
Thomas,
On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> Hi Doug,
>
> On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson <dianders@chromium.org> wrote:
>> Thomas,
>>
>> On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> index d0de1f5..3b12a97 100644
>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> @@ -575,3 +575,7 @@
>>> usb-phy = <&usb2_phy>;
>>> };
>>> };
>>> +
>>> +&cpu0 {
>>> + cpu0-supply = <&buck2_reg>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index b4b35ad..f07e834 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -414,3 +414,7 @@
>>> };
>>> };
>>> };
>>> +
>>> +&cpu0 {
>>> + cpu0-supply = <&buck2_reg>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>>> index f2b8c41..91acca7 100644
>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>> @@ -509,4 +509,8 @@
>>> };
>>> };
>>>
>>> +&cpu0 {
>>> + cpu0-supply = <&buck2_reg>;
>>> +};
>>> +
>>> #include "cros-ec-keyboard.dtsi"
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 492e1ef..97b282c 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -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>;
>>
>> 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.
Interesting. I wonder why the difference between my earlier
calculations. It seems just about double. :-/
>>> + 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";
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>> index cb2b70e..3154b4c 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -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>;
>>
>> 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.
Does it need to match the firmware? On exynos5420-peach-pit and
peach-pi I think the firmware starts the kernel at 1.7GHz.
>>> 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>;
>>> };
>>> };
>>
>> 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.
>
>>
>> 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.
Oh, right! The 5800 includes the 5420 dtsi...
-Doug
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-31 3:53 ` Doug Anderson
@ 2014-07-31 4:06 ` Thomas Abraham
2014-07-31 4:08 ` Doug Anderson
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 4:06 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson <dianders@chromium.org> wrote:
> Thomas,
>
> On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> Hi Doug,
>>
>> On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson <dianders@chromium.org> wrote:
>>> Thomas,
>>>
>>> On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>> index d0de1f5..3b12a97 100644
>>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>> @@ -575,3 +575,7 @@
>>>> usb-phy = <&usb2_phy>;
>>>> };
>>>> };
>>>> +
>>>> +&cpu0 {
>>>> + cpu0-supply = <&buck2_reg>;
>>>> +};
>>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>> index b4b35ad..f07e834 100644
>>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>> @@ -414,3 +414,7 @@
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&cpu0 {
>>>> + cpu0-supply = <&buck2_reg>;
>>>> +};
>>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>>>> index f2b8c41..91acca7 100644
>>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>>> @@ -509,4 +509,8 @@
>>>> };
>>>> };
>>>>
>>>> +&cpu0 {
>>>> + cpu0-supply = <&buck2_reg>;
>>>> +};
>>>> +
>>>> #include "cros-ec-keyboard.dtsi"
>>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>>>> index 492e1ef..97b282c 100644
>>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>>> @@ -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>;
>>>
>>> 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.
>
> 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.
>
>
>>>> + 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";
>>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>>> index cb2b70e..3154b4c 100644
>>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>>> @@ -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>;
>>>
>>> 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.
>
> 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.
>
>
>>>> 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>;
>>>> };
>>>> };
>>>
>>> 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.
>>
>>>
>>> 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.
>
> Oh, right! The 5800 includes the 5420 dtsi...
>
> -Doug
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-31 4:06 ` Thomas Abraham
@ 2014-07-31 4:08 ` Doug Anderson
2014-07-31 4:18 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Doug Anderson @ 2014-07-31 4:08 UTC (permalink / raw)
To: linux-arm-kernel
Thomas,
On Wed, Jul 30, 2014 at 9:06 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson <dianders@chromium.org> wrote:
>> Thomas,
>>
>> On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>> Hi Doug,
>>>
>>> On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson <dianders@chromium.org> wrote:
>>>> Thomas,
>>>>
>>>> On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>> index d0de1f5..3b12a97 100644
>>>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>> @@ -575,3 +575,7 @@
>>>>> usb-phy = <&usb2_phy>;
>>>>> };
>>>>> };
>>>>> +
>>>>> +&cpu0 {
>>>>> + cpu0-supply = <&buck2_reg>;
>>>>> +};
>>>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>> index b4b35ad..f07e834 100644
>>>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>> @@ -414,3 +414,7 @@
>>>>> };
>>>>> };
>>>>> };
>>>>> +
>>>>> +&cpu0 {
>>>>> + cpu0-supply = <&buck2_reg>;
>>>>> +};
>>>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>>>>> index f2b8c41..91acca7 100644
>>>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>>>> @@ -509,4 +509,8 @@
>>>>> };
>>>>> };
>>>>>
>>>>> +&cpu0 {
>>>>> + cpu0-supply = <&buck2_reg>;
>>>>> +};
>>>>> +
>>>>> #include "cros-ec-keyboard.dtsi"
>>>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>>>>> index 492e1ef..97b282c 100644
>>>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>>>> @@ -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>;
>>>>
>>>> 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.
>>
>> 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.
>
>>
>>
>>>>> + 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";
>>>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>>>> index cb2b70e..3154b4c 100644
>>>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>>>> @@ -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>;
>>>>
>>>> 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.
>>
>> 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
>
> Thanks,
> Thomas.
>
>>
>>
>>>>> 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>;
>>>>> };
>>>>> };
>>>>
>>>> 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.
>>>
>>>>
>>>> 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.
>>
>> Oh, right! The 5800 includes the 5420 dtsi...
>>
>> -Doug
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-31 4:08 ` Doug Anderson
@ 2014-07-31 4:18 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 4:18 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 31, 2014 at 9:38 AM, Doug Anderson <dianders@chromium.org> wrote:
> Thomas,
>
> On Wed, Jul 30, 2014 at 9:06 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson <dianders@chromium.org> wrote:
>>> Thomas,
>>>
>>> On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>>> Hi Doug,
>>>>
>>>> On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson <dianders@chromium.org> wrote:
>>>>> Thomas,
>>>>>
>>>>> On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>>>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>>> index d0de1f5..3b12a97 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>>>>> @@ -575,3 +575,7 @@
>>>>>> usb-phy = <&usb2_phy>;
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> +&cpu0 {
>>>>>> + cpu0-supply = <&buck2_reg>;
>>>>>> +};
>>>>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>>> index b4b35ad..f07e834 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>>>>> @@ -414,3 +414,7 @@
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> +&cpu0 {
>>>>>> + cpu0-supply = <&buck2_reg>;
>>>>>> +};
>>>>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>>>>>> index f2b8c41..91acca7 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>>>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>>>>> @@ -509,4 +509,8 @@
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> +&cpu0 {
>>>>>> + cpu0-supply = <&buck2_reg>;
>>>>>> +};
>>>>>> +
>>>>>> #include "cros-ec-keyboard.dtsi"
>>>>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>>>>>> index 492e1ef..97b282c 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>>>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>>>>> @@ -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>;
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>>>
>>>
>>>>>> + 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";
>>>>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>>>>> index cb2b70e..3154b4c 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>>>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>>>>> @@ -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>;
>>>>>
>>>>> 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.
>>>
>>> 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
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.
>
>>
>> Thanks,
>> Thomas.
>>
>>>
>>>
>>>>>> 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>;
>>>>>> };
>>>>>> };
>>>>>
>>>>> 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.
>>>>
>>>>>
>>>>> 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.
>>>
>>> Oh, right! The 5800 includes the 5420 dtsi...
>>>
>>> -Doug
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
` (5 preceding siblings ...)
2014-07-30 8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
@ 2014-07-31 6:20 ` Chander M. Kashyap
2014-07-31 10:59 ` Thomas Abraham
2014-07-31 14:15 ` Tomasz Figa
7 siblings, 1 reply; 61+ messages in thread
From: Chander M. Kashyap @ 2014-07-31 6:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 30, 2014 at 1:37 PM, Thomas Abraham <thomas.ab@samsung.com> wrote:
> 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
>
> --
> 1.7.9.5
Working great.
tested on smdk5420, and arndale-5250
>
>
>
>
> _______________________________________________
> 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-----
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-31 6:20 ` [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Chander M. Kashyap
@ 2014-07-31 10:59 ` Thomas Abraham
2014-07-31 12:24 ` Chander M. Kashyap
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 31, 2014 at 11:50 AM, Chander M. Kashyap
<chander.kashyap@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 1:37 PM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>> 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
>>
>> --
>> 1.7.9.5
>
> Working 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.
>
>>
>>
>>
>>
>> _______________________________________________
>> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-31 10:59 ` Thomas Abraham
@ 2014-07-31 12:24 ` Chander M. Kashyap
0 siblings, 0 replies; 61+ messages in thread
From: Chander M. Kashyap @ 2014-07-31 12:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 31, 2014 at 4:29 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> On Thu, Jul 31, 2014 at 11:50 AM, Chander M. Kashyap
> <chander.kashyap@gmail.com> wrote:
>> On Wed, Jul 30, 2014 at 1:37 PM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>> 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
>>>
>>> --
>>> 1.7.9.5
>>
>> Working great.
>> tested on smdk5420, and arndale-5250
>
> Hi Chander,
>
> Thanks for testing this series. Can I add a "Tested-by" tag for this series?
sure you can.
>
> Thanks,
> Thomas.
>
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
--
thanks and regards,
Chander M. Kashyap
Contact Number: +918123738320
------- TENSION LENE KA NAHI, DENE KE-----
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-30 8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
@ 2014-07-31 14:13 ` Tomasz Figa
2014-07-31 18:24 ` Thomas Abraham
2014-09-01 22:31 ` Mike Turquette
1 sibling, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 14:13 UTC (permalink / raw)
To: linux-arm-kernel
On 30.07.2014 10:07, Thomas Abraham wrote:
> 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]
> @@ -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.
> }
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index e19e365..1d958f1 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
[snip]
> @@ -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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
` (6 preceding siblings ...)
2014-07-31 6:20 ` [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Chander M. Kashyap
@ 2014-07-31 14:15 ` Tomasz Figa
2014-07-31 18:25 ` Thomas Abraham
7 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 14:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On 30.07.2014 10:07, Thomas Abraham wrote:
> 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
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 <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-31 14:13 ` Tomasz Figa
@ 2014-07-31 18:24 ` Thomas Abraham
2014-07-31 18:35 ` Tomasz Figa
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 18:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On Thu, Jul 31, 2014 at 7:43 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 30.07.2014 10:07, Thomas Abraham wrote:
>> 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]
>
>> @@ -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.
>
>> }
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
>> index e19e365..1d958f1 100644
>> --- a/drivers/clk/samsung/clk-exynos5250.c
>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>
> [snip]
>
>> @@ -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.
>
> Best regards,
> Tomasz
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-31 14:15 ` Tomasz Figa
@ 2014-07-31 18:25 ` Thomas Abraham
2014-07-31 18:34 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 18:25 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 31, 2014 at 7:45 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Thomas,
>
> On 30.07.2014 10:07, Thomas Abraham wrote:
>> 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
>
> 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 <t.figa@samsung.com>
Hi Tomasz,
Thanks for your review of this series. Your review comments has helped
to make this series better.
Regards,
Thomas.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-30 8:07 ` [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
@ 2014-07-31 18:32 ` Kukjin Kim
2014-07-31 18:40 ` Tomasz Figa
0 siblings, 1 reply; 61+ messages in thread
From: Kukjin Kim @ 2014-07-31 18:32 UTC (permalink / raw)
To: linux-arm-kernel
On 07/30/14 17:07, Thomas Abraham wrote:
> The new CPU clock type allows the use of generic CPUfreq drivers. So for
> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
> which did not have CPUfreq driver support, enable the use of generic
> CPUfreq driver.
>
> Suggested-by: Tomasz Figa<t.figa@samsung.com>
> Cc: Kukjin Kim<kgene.kim@samsung.com>
Looks good to me,
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
BTW, who will handle this series? I hope see this series in 3.17.
- Kukjin
> Signed-off-by: Thomas Abraham<thomas.ab@samsung.com>
> Reviewed-by: Tomasz Figa<t.figa@samsung.com>
> ---
> arch/arm/mach-exynos/exynos.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 493dbc2..e61bb36 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -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);
> }
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-31 18:25 ` Thomas Abraham
@ 2014-07-31 18:34 ` Thomas Abraham
2014-08-01 9:42 ` Viresh Kumar
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Viresh,
On Thu, Jul 31, 2014 at 11:55 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> On Thu, Jul 31, 2014 at 7:45 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Thomas,
>>
>> On 30.07.2014 10:07, Thomas Abraham wrote:
>>> 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
>>
>> 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 <t.figa@samsung.com>
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.
>
> Hi Tomasz,
>
> Thanks for your review of this series. Your review comments has helped
> to make this series better.
>
> Regards,
> Thomas.
>
>>
>> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-31 18:24 ` Thomas Abraham
@ 2014-07-31 18:35 ` Tomasz Figa
2014-07-31 18:41 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 18:35 UTC (permalink / raw)
To: linux-arm-kernel
On 31.07.2014 20:24, Thomas Abraham wrote:
> Hi Tomasz,
>
> On Thu, Jul 31, 2014 at 7:43 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> On 30.07.2014 10:07, Thomas Abraham wrote:
>>> 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]
>>
>>> @@ -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.
>
>>
>>> }
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
>>> index e19e365..1d958f1 100644
>>> --- a/drivers/clk/samsung/clk-exynos5250.c
>>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>>
>> [snip]
>>
>>> @@ -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?
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 18:32 ` Kukjin Kim
@ 2014-07-31 18:40 ` Tomasz Figa
2014-07-31 18:54 ` Tomasz Figa
2014-08-22 23:54 ` Kevin Hilman
0 siblings, 2 replies; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 18:40 UTC (permalink / raw)
To: linux-arm-kernel
Kukjin,
On 31.07.2014 20:32, Kukjin Kim wrote:
> On 07/30/14 17:07, Thomas Abraham wrote:
>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>> which did not have CPUfreq driver support, enable the use of generic
>> CPUfreq driver.
>>
>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>
> Looks good to me,
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-31 18:35 ` Tomasz Figa
@ 2014-07-31 18:41 ` Thomas Abraham
2014-07-31 18:46 ` Tomasz Figa
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 18:41 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 1, 2014 at 12:05 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 31.07.2014 20:24, Thomas Abraham wrote:
>> Hi Tomasz,
>>
>> On Thu, Jul 31, 2014 at 7:43 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>> On 30.07.2014 10:07, Thomas Abraham wrote:
>>>> 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]
>>>
>>>> @@ -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.
>>
>>>
>>>> }
>>>>
>>>> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
>>>> index e19e365..1d958f1 100644
>>>> --- a/drivers/clk/samsung/clk-exynos5250.c
>>>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>>>
>>> [snip]
>>>
>>>> @@ -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?
>
> 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.
>
> 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.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-31 18:41 ` Thomas Abraham
@ 2014-07-31 18:46 ` Tomasz Figa
2014-07-31 18:49 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 18:46 UTC (permalink / raw)
To: linux-arm-kernel
On 31.07.2014 20:41, Thomas Abraham wrote:
> On Fri, Aug 1, 2014 at 12:05 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> On 31.07.2014 20:24, Thomas Abraham wrote:
>>> Hi Tomasz,
>>>
>>> On Thu, Jul 31, 2014 at 7:43 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>>> On 30.07.2014 10:07, Thomas Abraham wrote:
>>>>> 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]
>>>>
>>>>> @@ -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.
>>>
>>>>
>>>>> }
>>>>>
>>>>> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
>>>>> index e19e365..1d958f1 100644
>>>>> --- a/drivers/clk/samsung/clk-exynos5250.c
>>>>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>>>>
>>>> [snip]
>>>>
>>>>> @@ -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?
>>
>> 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.
>
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-31 18:46 ` Tomasz Figa
@ 2014-07-31 18:49 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 18:49 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 1, 2014 at 12:16 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 31.07.2014 20:41, Thomas Abraham wrote:
>> On Fri, Aug 1, 2014 at 12:05 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>> On 31.07.2014 20:24, Thomas Abraham wrote:
>>>> Hi Tomasz,
>>>>
>>>> On Thu, Jul 31, 2014 at 7:43 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>>>> On 30.07.2014 10:07, Thomas Abraham wrote:
>>>>>> 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]
>>>>>
>>>>>> @@ -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.
>>>>
>>>>>
>>>>>> }
>>>>>>
>>>>>> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
>>>>>> index e19e365..1d958f1 100644
>>>>>> --- a/drivers/clk/samsung/clk-exynos5250.c
>>>>>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>>>>>
>>>>> [snip]
>>>>>
>>>>>> @@ -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?
>>>
>>> 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.
>>
>
> 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.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 18:40 ` Tomasz Figa
@ 2014-07-31 18:54 ` Tomasz Figa
2014-07-31 19:25 ` Thomas Abraham
2014-08-22 23:54 ` Kevin Hilman
1 sibling, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 18:54 UTC (permalink / raw)
To: linux-arm-kernel
On 31.07.2014 20:40, Tomasz Figa wrote:
> Kukjin,
>
> On 31.07.2014 20:32, Kukjin Kim wrote:
>> On 07/30/14 17:07, Thomas Abraham wrote:
>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>> which did not have CPUfreq driver support, enable the use of generic
>>> CPUfreq driver.
>>>
>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>
>> Looks good to me,
>>
>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>
>> 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
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 18:54 ` Tomasz Figa
@ 2014-07-31 19:25 ` Thomas Abraham
2014-07-31 19:30 ` Tomasz Figa
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-07-31 19:25 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>
>
> On 31.07.2014 20:40, Tomasz Figa wrote:
>> Kukjin,
>>
>> On 31.07.2014 20:32, Kukjin Kim wrote:
>>> On 07/30/14 17:07, Thomas Abraham wrote:
>>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>>> which did not have CPUfreq driver support, enable the use of generic
>>>> CPUfreq driver.
>>>>
>>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>
>>> Looks good to me,
>>>
>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>
>>> 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
>
> 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.
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.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 19:25 ` Thomas Abraham
@ 2014-07-31 19:30 ` Tomasz Figa
2014-08-04 3:24 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-07-31 19:30 UTC (permalink / raw)
To: linux-arm-kernel
On 31.07.2014 21:25, Thomas Abraham wrote:
> On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>
>>
>> On 31.07.2014 20:40, Tomasz Figa wrote:
>>> Kukjin,
>>>
>>> On 31.07.2014 20:32, Kukjin Kim wrote:
>>>> On 07/30/14 17:07, Thomas Abraham wrote:
>>>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>>>> which did not have CPUfreq driver support, enable the use of generic
>>>>> CPUfreq driver.
>>>>>
>>>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>>
>>>> Looks good to me,
>>>>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>>
>>>> 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
>>
>> 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.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
2014-07-31 18:34 ` Thomas Abraham
@ 2014-08-01 9:42 ` Viresh Kumar
0 siblings, 0 replies; 61+ messages in thread
From: Viresh Kumar @ 2014-08-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
On 1 August 2014 00:04, Thomas Abraham <ta.omasab@gmail.com> wrote:
> 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..
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
2014-07-30 11:28 ` Andreas Färber
2014-07-31 0:37 ` Doug Anderson
@ 2014-08-02 3:49 ` Javier Martinez Canillas
2014-08-04 3:00 ` Thomas Abraham
2 siblings, 1 reply; 61+ messages in thread
From: Javier Martinez Canillas @ 2014-08-02 3:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello Thomas,
On 07/30/2014 10:07 AM, Thomas Abraham wrote:
> 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 <kgene.kim@samsung.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Sachin Kamat <sachin.kamat@linaro.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> 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:
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Best regards,
Javier
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
2014-08-02 3:49 ` Javier Martinez Canillas
@ 2014-08-04 3:00 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-08-04 3:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Javier,
On Sat, Aug 2, 2014 at 9:19 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Thomas,
>
> On 07/30/2014 10:07 AM, Thomas Abraham wrote:
>> 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 <kgene.kim@samsung.com>
>> Cc: Doug Anderson <dianders@chromium.org>
>> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Cc: Andreas Faerber <afaerber@suse.de>
>> Cc: Sachin Kamat <sachin.kamat@linaro.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>> 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:
>
> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Thank you for using this series and the details of what has worked.
This is very helpful.
Regards,
Thomas.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 19:30 ` Tomasz Figa
@ 2014-08-04 3:24 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-08-04 3:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On Fri, Aug 1, 2014 at 1:00 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 31.07.2014 21:25, Thomas Abraham wrote:
>> On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>>
>>>
>>> On 31.07.2014 20:40, Tomasz Figa wrote:
>>>> Kukjin,
>>>>
>>>> On 31.07.2014 20:32, Kukjin Kim wrote:
>>>>> On 07/30/14 17:07, Thomas Abraham wrote:
>>>>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>>>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>>>>> which did not have CPUfreq driver support, enable the use of generic
>>>>>> CPUfreq driver.
>>>>>>
>>>>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>>>
>>>>> Looks good to me,
>>>>>
>>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>>>
>>>>> 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
>>>
>>> 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.
>>
>> 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
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.
> 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.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-07-31 18:40 ` Tomasz Figa
2014-07-31 18:54 ` Tomasz Figa
@ 2014-08-22 23:54 ` Kevin Hilman
2014-08-23 0:02 ` Tomasz Figa
2014-08-25 8:11 ` Sjoerd Simons
1 sibling, 2 replies; 61+ messages in thread
From: Kevin Hilman @ 2014-08-22 23:54 UTC (permalink / raw)
To: linux-arm-kernel
Tomasz Figa <tomasz.figa@gmail.com> writes:
> Kukjin,
>
> On 31.07.2014 20:32, Kukjin Kim wrote:
>> On 07/30/14 17:07, Thomas Abraham wrote:
>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>> which did not have CPUfreq driver support, enable the use of generic
>>> CPUfreq driver.
>>>
>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>
>> Looks good to me,
>>
>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>
>> 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]
>From 72ee00246c0fbdcf5dbb0bf910b8a427da4ac002 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
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.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8923d37c3e85..debe50bf736a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -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" },
--
1.9.2
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-22 23:54 ` Kevin Hilman
@ 2014-08-23 0:02 ` Tomasz Figa
2014-08-25 6:53 ` Lukasz Majewski
2014-08-25 12:15 ` Chander Kashyap
2014-08-25 8:11 ` Sjoerd Simons
1 sibling, 2 replies; 61+ messages in thread
From: Tomasz Figa @ 2014-08-23 0:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
Thanks for taking a look at this.
On 23.08.2014 01:54, Kevin Hilman wrote:
> Tomasz Figa <tomasz.figa@gmail.com> writes:
>
>> Kukjin,
>>
>> On 31.07.2014 20:32, Kukjin Kim wrote:
>>> On 07/30/14 17:07, Thomas Abraham wrote:
>>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>>> which did not have CPUfreq driver support, enable the use of generic
>>>> CPUfreq driver.
>>>>
>>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>
>>> Looks good to me,
>>>
>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>
>>> 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...
>
> 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).
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-23 0:02 ` Tomasz Figa
@ 2014-08-25 6:53 ` Lukasz Majewski
2014-08-25 12:15 ` Chander Kashyap
1 sibling, 0 replies; 61+ messages in thread
From: Lukasz Majewski @ 2014-08-25 6:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
> Hi Kevin,
>
> Thanks for taking a look at this.
>
> On 23.08.2014 01:54, Kevin Hilman wrote:
> > Tomasz Figa <tomasz.figa@gmail.com> writes:
> >
> >> Kukjin,
> >>
> >> On 31.07.2014 20:32, Kukjin Kim wrote:
> >>> On 07/30/14 17:07, Thomas Abraham wrote:
> >>>> The new CPU clock type allows the use of generic CPUfreq
> >>>> drivers. So for Exynos4210/5250, switch to using generic cpufreq
> >>>> driver. For Exynos5420, which did not have CPUfreq driver
> >>>> support, enable the use of generic CPUfreq driver.
> >>>>
> >>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
> >>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
> >>>
> >>> Looks good to me,
> >>>
> >>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >>>
> >>> 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...
>
> >
> > 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.
It is a huge step forward - to be honest it is a serious rework of
cpufreq subsystem for Exynos 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).
>
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.
> >
> > 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
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-22 23:54 ` Kevin Hilman
2014-08-23 0:02 ` Tomasz Figa
@ 2014-08-25 8:11 ` Sjoerd Simons
1 sibling, 0 replies; 61+ messages in thread
From: Sjoerd Simons @ 2014-08-25 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Hey,
On Fri, 2014-08-22 at 16:54 -0700, Kevin Hilman wrote:
> Tomasz Figa <tomasz.figa@gmail.com> writes:
>
> > Kukjin,
> >
> > On 31.07.2014 20:32, Kukjin Kim wrote:
> >> On 07/30/14 17:07, Thomas Abraham wrote:
> >>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
> >>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
> >>> which did not have CPUfreq driver support, enable the use of generic
> >>> CPUfreq driver.
> >>>
> >>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
> >>> Cc: Kukjin Kim<kgene.kim@samsung.com>
> >>
> >> Looks good to me,
> >>
> >> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >>
> >> 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.
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.
--
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-23 0:02 ` Tomasz Figa
2014-08-25 6:53 ` Lukasz Majewski
@ 2014-08-25 12:15 ` Chander Kashyap
2014-08-25 15:32 ` Kevin Hilman
1 sibling, 1 reply; 61+ messages in thread
From: Chander Kashyap @ 2014-08-25 12:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin, Tomasz,
On Sat, Aug 23, 2014 at 5:32 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Kevin,
>
> Thanks for taking a look at this.
>
> On 23.08.2014 01:54, Kevin Hilman wrote:
>> Tomasz Figa <tomasz.figa@gmail.com> writes:
>>
>>> Kukjin,
>>>
>>> On 31.07.2014 20:32, Kukjin Kim wrote:
>>>> On 07/30/14 17:07, Thomas Abraham wrote:
>>>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>>>> which did not have CPUfreq driver support, enable the use of generic
>>>>> CPUfreq driver.
>>>>>
>>>>> Suggested-by: Tomasz Figa<t.figa@samsung.com>
>>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>>
>>>> Looks good to me,
>>>>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>>
>>>> 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...
>
>>
>> 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.
>
> 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).
>
>>
>> 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
regards,
Chander
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-25 12:15 ` Chander Kashyap
@ 2014-08-25 15:32 ` Kevin Hilman
2014-08-25 15:56 ` Tomasz Figa
2014-08-26 5:25 ` Chander Kashyap
0 siblings, 2 replies; 61+ messages in thread
From: Kevin Hilman @ 2014-08-25 15:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Chander,
Chander Kashyap <k.chander@samsung.com> writes:
[...]
>>> 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.
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-25 15:32 ` Kevin Hilman
@ 2014-08-25 15:56 ` Tomasz Figa
2014-08-26 4:54 ` Viresh Kumar
2014-08-26 5:25 ` Chander Kashyap
1 sibling, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2014-08-25 15:56 UTC (permalink / raw)
To: linux-arm-kernel
On 25.08.2014 17:32, Kevin Hilman wrote:
> Hi Chander,
>
> Chander Kashyap <k.chander@samsung.com> writes:
>
> [...]
>
>>>> 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.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-25 15:56 ` Tomasz Figa
@ 2014-08-26 4:54 ` Viresh Kumar
0 siblings, 0 replies; 61+ messages in thread
From: Viresh Kumar @ 2014-08-26 4:54 UTC (permalink / raw)
To: linux-arm-kernel
On 25 August 2014 21:26, Tomasz Figa <t.figa@samsung.com> wrote:
> 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..
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-25 15:32 ` Kevin Hilman
2014-08-25 15:56 ` Tomasz Figa
@ 2014-08-26 5:25 ` Chander Kashyap
2014-08-26 15:15 ` Kevin Hilman
1 sibling, 1 reply; 61+ messages in thread
From: Chander Kashyap @ 2014-08-26 5:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On Mon, Aug 25, 2014 at 9:02 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Hi Chander,
>
> Chander Kashyap <k.chander@samsung.com> writes:
>
> [...]
>
>>>> 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.
>
> Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -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;
>
> 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
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
regards,
Chander
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-26 5:25 ` Chander Kashyap
@ 2014-08-26 15:15 ` Kevin Hilman
2014-08-26 22:25 ` Kevin Hilman
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-08-26 15:15 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
> Hi Kevin,
>
> On Mon, Aug 25, 2014 at 9:02 PM, Kevin Hilman <khilman@linaro.org> wrote:
>> Hi Chander,
>>
>> Chander Kashyap <k.chander@samsung.com> writes:
>>
>> [...]
>>
>>>>> 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.
>>
>> 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 at
git://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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-26 15:15 ` Kevin Hilman
@ 2014-08-26 22:25 ` Kevin Hilman
2014-08-29 12:52 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-08-26 22:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
[...]
>>>
>>> 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 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
[1]https://github.com/exynos-reference/kernel.git
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-26 22:25 ` Kevin Hilman
@ 2014-08-29 12:52 ` Thomas Abraham
2014-08-29 15:03 ` Kevin Hilman
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-08-29 12:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>
> [...]
>
>>>>
>>>> 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 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?
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.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-29 12:52 ` Thomas Abraham
@ 2014-08-29 15:03 ` Kevin Hilman
2014-09-01 8:47 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-08-29 15:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> Hi Kevin,
>
> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>>
>> [...]
>>
>>>>>
>>>>> 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 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?
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-08-29 15:03 ` Kevin Hilman
@ 2014-09-01 8:47 ` Thomas Abraham
2014-09-02 19:32 ` Kevin Hilman
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-09-01 8:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Hi Thomas,
>
> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> Hi Kevin,
>>
>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>>>
>>> [...]
>>>
>>>>>>
>>>>>> 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 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?
>>
>> 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.
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.
>
> Thanks for looking into this,
>
> Kevin
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
2014-07-30 8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
@ 2014-09-01 22:29 ` Mike Turquette
2014-09-02 13:53 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Mike Turquette @ 2014-09-01 22:29 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Thomas Abraham (2014-07-30 01:07:38)
> 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 <thomas.ab@samsung.com>
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
> ---
> 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
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 6fb4bc6..8909c93 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -2,7 +2,7 @@
> # Samsung Clock specific Makefile
> #
>
> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
> new file mode 100644
> index 0000000..009a21b
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-cpu.c
> @@ -0,0 +1,335 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Thomas Abraham <thomas.ab@samsung.com>
> + *
> + * 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;
> +}
> diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
> new file mode 100644
> index 0000000..42e1905
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-cpu.h
> @@ -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 */
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
2014-07-30 8:07 ` [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
@ 2014-09-01 22:29 ` Mike Turquette
0 siblings, 0 replies; 61+ messages in thread
From: Mike Turquette @ 2014-09-01 22:29 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Thomas Abraham (2014-07-30 01:07:39)
> 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 <t.figa@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
> ---
> 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(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 8617f49..101f549 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -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));
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index 70ec3d2..e19e365 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -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
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 848d602..d7ef36a 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -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);
> diff --git a/include/dt-bindings/clock/exynos5250.h b/include/dt-bindings/clock/exynos5250.h
> index 4273891..8183d1c 100644
> --- a/include/dt-bindings/clock/exynos5250.h
> +++ b/include/dt-bindings/clock/exynos5250.h
> @@ -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
> diff --git a/include/dt-bindings/clock/exynos5420.h b/include/dt-bindings/clock/exynos5420.h
> index 8dc0913..ec0af64 100644
> --- a/include/dt-bindings/clock/exynos5420.h
> +++ b/include/dt-bindings/clock/exynos5420.h
> @@ -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
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
2014-07-30 8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
2014-07-31 14:13 ` Tomasz Figa
@ 2014-09-01 22:31 ` Mike Turquette
1 sibling, 0 replies; 61+ messages in thread
From: Mike Turquette @ 2014-09-01 22:31 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Thomas Abraham (2014-07-30 01:07:43)
> 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 <t.figa@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
> ---
> 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(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 101f549..04619a1 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -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"));
> }
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index e19e365..1d958f1 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -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);
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index d7ef36a..fcf365d 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -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),
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
2014-09-01 22:29 ` Mike Turquette
@ 2014-09-02 13:53 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-09-02 13:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 2, 2014 at 3:59 AM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Thomas Abraham (2014-07-30 01:07:38)
>> 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 <thomas.ab@samsung.com>
>> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
>
> Acked-by: Mike Turquette <mturquette@linaro.org>
Thank you Mike.
Regards,
Thomas.
>
>> ---
>> 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
>>
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index 6fb4bc6..8909c93 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -2,7 +2,7 @@
>> # Samsung Clock specific Makefile
>> #
>>
>> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
>> new file mode 100644
>> index 0000000..009a21b
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-cpu.c
>> @@ -0,0 +1,335 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * Author: Thomas Abraham <thomas.ab@samsung.com>
>> + *
>> + * 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;
>> +}
>> diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
>> new file mode 100644
>> index 0000000..42e1905
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-cpu.h
>> @@ -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 */
>> --
>> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-01 8:47 ` Thomas Abraham
@ 2014-09-02 19:32 ` Kevin Hilman
2014-09-03 4:26 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-09-02 19:32 UTC (permalink / raw)
To: linux-arm-kernel
HI Thomas,
Thomas Abraham <ta.omasab@gmail.com> writes:
> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> Hi Thomas,
>>
>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>> Hi Kevin,
>>>
>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>>>>
>>>>>>> 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 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?
>>>
>>> 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.
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-02 19:32 ` Kevin Hilman
@ 2014-09-03 4:26 ` Thomas Abraham
2014-09-03 13:18 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-09-03 4:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman <khilman@kernel.org> wrote:
> HI Thomas,
>
> Thomas Abraham <ta.omasab@gmail.com> writes:
>
>> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Hi Thomas,
>>>
>>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>>> Hi Kevin,
>>>>
>>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>
>>>>>>>> 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 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?
>>>>
>>>> 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.
>>
>> 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
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.
>
> 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.
>
> 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.
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.
>
> 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.
>
> 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.
>
> Kevin
>
> [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-03 4:26 ` Thomas Abraham
@ 2014-09-03 13:18 ` Thomas Abraham
2014-09-03 23:15 ` Kevin Hilman
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-09-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 3, 2014 at 9:56 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> Hi Kevin,
>
> On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> HI Thomas,
>>
>> Thomas Abraham <ta.omasab@gmail.com> writes:
>>
>>> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> Hi Thomas,
>>>>
>>>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>>>> Hi Kevin,
>>>>>
>>>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@samsung.com> wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>>>
>>>>>>>>> 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 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?
>>>>>
>>>>> 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.
>>>
>>> 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
>
> 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.
>
>>
>> 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.
>
>>
>> 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.
>
> 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.
>
>>
>> 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.
>
>>
>> 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.
>
> Thanks,
> Thomas.
>
>>
>> Kevin
>>
>> [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-03 13:18 ` Thomas Abraham
@ 2014-09-03 23:15 ` Kevin Hilman
2014-09-04 10:22 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-09-03 23:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
Thomas Abraham <ta.omasab@gmail.com> writes:
[...]
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-03 23:15 ` Kevin Hilman
@ 2014-09-04 10:22 ` Thomas Abraham
2014-09-04 13:30 ` Kevin Hilman
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Abraham @ 2014-09-04 10:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman <khilman@kernel.org> wrote:
> Hi Thomas,
>
> Thomas Abraham <ta.omasab@gmail.com> writes:
>
> [...]
>
>> 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?
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.
>
> 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
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-04 10:22 ` Thomas Abraham
@ 2014-09-04 13:30 ` Kevin Hilman
2014-09-05 13:41 ` Thomas Abraham
0 siblings, 1 reply; 61+ messages in thread
From: Kevin Hilman @ 2014-09-04 13:30 UTC (permalink / raw)
To: linux-arm-kernel
Thomas Abraham <ta.omasab@gmail.com> writes:
> On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> Hi Thomas,
>>
>> Thomas Abraham <ta.omasab@gmail.com> writes:
>>
>> [...]
>>
>>> 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?
>
> 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
2014-09-04 13:30 ` Kevin Hilman
@ 2014-09-05 13:41 ` Thomas Abraham
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Abraham @ 2014-09-05 13:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 4, 2014 at 7:00 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Thomas Abraham <ta.omasab@gmail.com> writes:
>
>> On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Hi Thomas,
>>>
>>> Thomas Abraham <ta.omasab@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> 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?
>>
>> 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.
Ok, I haven't tried to recreate this issue. I will try and do that.
>
> 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.
>From b0c4057d428134fe12446431ede1d9a579fd1d05 Mon Sep 17 00:00:00 2001
From: Thomas Abraham <thomas.ab@samsung.com>
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.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
arch/arm/include/asm/bL_switcher.h | 15 ++++++++++++++-
drivers/cpufreq/arm_big_little.c | 9 ++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/bL_switcher.h
b/arch/arm/include/asm/bL_switcher.h
index 1714800..d609b86 100644
--- a/arch/arm/include/asm/bL_switcher.h
+++ b/arch/arm/include/asm/bL_switcher.h
@@ -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;
}
/*
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index a46c223..baeff47 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -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]);
--
1.6.6.rc2
>
> 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
end of thread, other threads:[~2014-09-05 13:41 UTC | newest]
Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
2014-09-01 22:29 ` Mike Turquette
2014-09-02 13:53 ` Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
2014-09-01 22:29 ` Mike Turquette
2014-07-30 8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
2014-07-30 11:28 ` Andreas Färber
2014-07-31 2:55 ` Thomas Abraham
2014-07-31 0:37 ` Doug Anderson
2014-07-31 3:21 ` Thomas Abraham
2014-07-31 3:53 ` Doug Anderson
2014-07-31 4:06 ` Thomas Abraham
2014-07-31 4:08 ` Doug Anderson
2014-07-31 4:18 ` Thomas Abraham
2014-08-02 3:49 ` Javier Martinez Canillas
2014-08-04 3:00 ` Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
2014-07-31 18:32 ` Kukjin Kim
2014-07-31 18:40 ` Tomasz Figa
2014-07-31 18:54 ` Tomasz Figa
2014-07-31 19:25 ` Thomas Abraham
2014-07-31 19:30 ` Tomasz Figa
2014-08-04 3:24 ` Thomas Abraham
2014-08-22 23:54 ` Kevin Hilman
2014-08-23 0:02 ` Tomasz Figa
2014-08-25 6:53 ` Lukasz Majewski
2014-08-25 12:15 ` Chander Kashyap
2014-08-25 15:32 ` Kevin Hilman
2014-08-25 15:56 ` Tomasz Figa
2014-08-26 4:54 ` Viresh Kumar
2014-08-26 5:25 ` Chander Kashyap
2014-08-26 15:15 ` Kevin Hilman
2014-08-26 22:25 ` Kevin Hilman
2014-08-29 12:52 ` Thomas Abraham
2014-08-29 15:03 ` Kevin Hilman
2014-09-01 8:47 ` Thomas Abraham
2014-09-02 19:32 ` Kevin Hilman
2014-09-03 4:26 ` Thomas Abraham
2014-09-03 13:18 ` Thomas Abraham
2014-09-03 23:15 ` Kevin Hilman
2014-09-04 10:22 ` Thomas Abraham
2014-09-04 13:30 ` Kevin Hilman
2014-09-05 13:41 ` Thomas Abraham
2014-08-25 8:11 ` Sjoerd Simons
2014-07-30 8:07 ` [PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support Thomas Abraham
2014-07-30 8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
2014-07-31 14:13 ` Tomasz Figa
2014-07-31 18:24 ` Thomas Abraham
2014-07-31 18:35 ` Tomasz Figa
2014-07-31 18:41 ` Thomas Abraham
2014-07-31 18:46 ` Tomasz Figa
2014-07-31 18:49 ` Thomas Abraham
2014-09-01 22:31 ` Mike Turquette
2014-07-31 6:20 ` [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Chander M. Kashyap
2014-07-31 10:59 ` Thomas Abraham
2014-07-31 12:24 ` Chander M. Kashyap
2014-07-31 14:15 ` Tomasz Figa
2014-07-31 18:25 ` Thomas Abraham
2014-07-31 18:34 ` Thomas Abraham
2014-08-01 9:42 ` Viresh Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).