MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster share the same power and clock domain. This series tries to add cpufreq support for MT8173 SoC. The v6 of this series is resent with Acks added.
changes in v6: - Move clock and regulator consumer properties document to the device tree bindings documents of MT8173 CPU DVFS clock driver - Add change log to describe what is implemented in the MT8173 cpufreq driver - Add missed rcu_read_unlock() in the error path - Move of_init_opp_table() call to make sure all required hardware resources are already there before it is called - Add comments to describe why both platform driver and deivce registration codes are put in the initcall function - Use the term "voltage tracking" instead of "voltage trace" according to an internal SoC document
changes in v5: - Move resource allocation code from init() into probe() and remove some unused functions due to this change - Fix descriptions for device tree binding document - Address review comments for last version - Register CPU cooling device
Changes in v4: - Add bindings for MT8173 cpufreq driver - Move OPP table back into device tree - Address comments for last version
Changes in v3: - Implement MT8173 specific standalone cpufreq driver instead of using cpufreq-dt driver - Define OPP table in the driver source code until new OPP binding is ready
Changes in v2: - Add intermediate frequency support in cpufreq-dt driver - Use voltage scaling code of cpufreq-dt for little cluster instead of implementaion in notifier of mtk-cpufreq driver - Code refinement for mtk-cpufreq driver
Pi-Cheng Chen (3): dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings cpufreq: mediatek: Add MT8173 cpufreq driver arm64: dts: mt8173: Add mt8173 cpufreq driver support
.../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 ++++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 64 +++ drivers/cpufreq/Kconfig.arm | 7 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mt8173-cpufreq.c | 524 +++++++++++++++++++++ 6 files changed, 697 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
This patch adds the clock and regulator consumer properties part of document for CPU DVFS clocks on Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Michael Turquette mturquette@baylibre.com Acked-by: Viresh Kumar viresh.kumar@linaro.org --- .../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 ++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
diff --git a/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt new file mode 100644 index 0000000..52b457c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt @@ -0,0 +1,83 @@ +Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC + +Required properties: +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names. +- clock-names: Should contain the following: + "cpu" - The multiplexer for clock input of CPU cluster. + "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock + source (usually MAINPLL) when the original CPU PLL is under + transition and not stable yet. + Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for + generic clock consumer properties. +- proc-supply: Regulator for Vproc of CPU cluster. + +Optional properties: +- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver + needs to do "voltage tracking" to step by step scale up/down Vproc and + Vsram to fit SoC specific needs. When absent, the voltage scaling + flow is handled by hardware, hence no software "voltage tracking" is + needed. + +Example: +-------- + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x000>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA53SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x001>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA53SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + }; + + cpu2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA57SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + }; + + cpu3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA57SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + }; + + &cpu0 { + proc-supply = <&mt6397_vpca15_reg>; + }; + + &cpu1 { + proc-supply = <&mt6397_vpca15_reg>; + }; + + &cpu2 { + proc-supply = <&da9211_vcpu_reg>; + sram-supply = <&mt6397_vsramca7_reg>; + }; + + &cpu3 { + proc-supply = <&da9211_vcpu_reg>; + sram-supply = <&mt6397_vsramca7_reg>; + };
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation:
100mV < Vsram - Vproc < 200mV
which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Viresh Kumar viresh.kumar@linaro.org --- drivers/cpufreq/Kconfig.arm | 7 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mt8173-cpufreq.c | 524 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 532 insertions(+) create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index cc8a71c..2bacf24 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -130,6 +130,13 @@ config ARM_KIRKWOOD_CPUFREQ This adds the CPUFreq driver for Marvell Kirkwood SoCs.
+config ARM_MT8173_CPUFREQ + bool "Mediatek MT8173 CPUFreq support" + depends on ARCH_MEDIATEK && REGULATOR + select PM_OPP + help + This adds the CPUFreq driver support for Mediatek MT8173 SoC. + config ARM_OMAP2PLUS_CPUFREQ bool "TI OMAP2+" depends on ARCH_OMAP2PLUS diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 2169bf7..9c75faf 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ) += hisi-acpu-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o +obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c new file mode 100644 index 0000000..763f1e3 --- /dev/null +++ b/drivers/cpufreq/mt8173-cpufreq.c @@ -0,0 +1,524 @@ +/* + * Copyright (c) 2015 Linaro Ltd. + * Author: Pi-Cheng Chen pi-cheng.chen@linaro.org + * + * 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 program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/cpu.h> +#include <linux/cpu_cooling.h> +#include <linux/cpufreq.h> +#include <linux/cpumask.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_opp.h> +#include <linux/regulator/consumer.h> +#include <linux/slab.h> +#include <linux/thermal.h> + +#define MIN_VOLT_SHIFT (100000) +#define MAX_VOLT_SHIFT (200000) +#define MAX_VOLT_LIMIT (1150000) +#define VOLT_TOL (10000) + +/* + * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU DVFS + * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in + * Mediatek SoCs has two voltage inputs, Vproc and Vsram. In some cases the two + * voltage inputs need to be controlled under a hardware limitation: + * 100mV < Vsram - Vproc < 200mV + * + * When scaling the clock frequency of a CPU clock domain, the clock source + * needs to be switched to another stable PLL clock temporarily until + * the original PLL becomes stable at target frequency. + */ +struct mtk_cpu_dvfs_info { + struct device *cpu_dev; + struct regulator *proc_reg; + struct regulator *sram_reg; + struct clk *cpu_clk; + struct clk *inter_clk; + struct thermal_cooling_device *cdev; + int intermediate_voltage; + bool need_voltage_tracking; +}; + +static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info, + int new_vproc) +{ + struct regulator *proc_reg = info->proc_reg; + struct regulator *sram_reg = info->sram_reg; + int old_vproc, old_vsram, new_vsram, vsram, vproc, ret; + + old_vproc = regulator_get_voltage(proc_reg); + old_vsram = regulator_get_voltage(sram_reg); + /* Vsram should not exceed the maximum allowed voltage of SoC. */ + new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT); + + if (old_vproc < new_vproc) { + /* + * When scaling up voltages, Vsram and Vproc scale up step + * by step. At each step, set Vsram to (Vproc + 200mV) first, + * then set Vproc to (Vsram - 100mV). + * Keep doing it until Vsram and Vproc hit target voltages. + */ + do { + old_vsram = regulator_get_voltage(sram_reg); + old_vproc = regulator_get_voltage(proc_reg); + + vsram = min(new_vsram, old_vproc + MAX_VOLT_SHIFT); + + if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) { + vsram = MAX_VOLT_LIMIT; + + /* + * If the target Vsram hits the maximum voltage, + * try to set the exact voltage value first. + */ + ret = regulator_set_voltage(sram_reg, vsram, + vsram); + if (ret) + ret = regulator_set_voltage(sram_reg, + vsram - VOLT_TOL, + vsram); + + vproc = new_vproc; + } else { + ret = regulator_set_voltage(sram_reg, vsram, + vsram + VOLT_TOL); + + vproc = vsram - MIN_VOLT_SHIFT; + } + if (ret) + return ret; + + ret = regulator_set_voltage(proc_reg, vproc, + vproc + VOLT_TOL); + if (ret) { + regulator_set_voltage(sram_reg, old_vsram, + old_vsram); + return ret; + } + } while (vproc < new_vproc || vsram < new_vsram); + } else if (old_vproc > new_vproc) { + /* + * When scaling down voltages, Vsram and Vproc scale down step + * by step. At each step, set Vproc to (Vsram - 200mV) first, + * then set Vproc to (Vproc + 100mV). + * Keep doing it until Vsram and Vproc hit target voltages. + */ + do { + old_vproc = regulator_get_voltage(proc_reg); + old_vsram = regulator_get_voltage(sram_reg); + + vproc = max(new_vproc, old_vsram - MAX_VOLT_SHIFT); + ret = regulator_set_voltage(proc_reg, vproc, + vproc + VOLT_TOL); + if (ret) + return ret; + + if (vproc == new_vproc) + vsram = new_vsram; + else + vsram = max(new_vsram, vproc + MIN_VOLT_SHIFT); + + if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) { + vsram = MAX_VOLT_LIMIT; + + /* + * If the target Vsram hits the maximum voltage, + * try to set the exact voltage value first. + */ + ret = regulator_set_voltage(sram_reg, vsram, + vsram); + if (ret) + ret = regulator_set_voltage(sram_reg, + vsram - VOLT_TOL, + vsram); + } else { + ret = regulator_set_voltage(sram_reg, vsram, + vsram + VOLT_TOL); + } + + if (ret) { + regulator_set_voltage(proc_reg, old_vproc, + old_vproc); + return ret; + } + } while (vproc > new_vproc + VOLT_TOL || + vsram > new_vsram + VOLT_TOL); + } + + return 0; +} + +static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc) +{ + if (info->need_voltage_tracking) + return mtk_cpufreq_voltage_tracking(info, vproc); + else + return regulator_set_voltage(info->proc_reg, vproc, + vproc + VOLT_TOL); +} + +static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, + unsigned int index) +{ + struct cpufreq_frequency_table *freq_table = policy->freq_table; + struct clk *cpu_clk = policy->clk; + struct clk *armpll = clk_get_parent(cpu_clk); + struct mtk_cpu_dvfs_info *info = policy->driver_data; + struct device *cpu_dev = info->cpu_dev; + struct dev_pm_opp *opp; + long freq_hz, old_freq_hz; + int vproc, old_vproc, inter_vproc, target_vproc, ret; + + inter_vproc = info->intermediate_voltage; + + old_freq_hz = clk_get_rate(cpu_clk); + old_vproc = regulator_get_voltage(info->proc_reg); + + freq_hz = freq_table[index].frequency * 1000; + + rcu_read_lock(); + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_hz); + if (IS_ERR(opp)) { + rcu_read_unlock(); + pr_err("cpu%d: failed to find OPP for %ld\n", + policy->cpu, freq_hz); + return PTR_ERR(opp); + } + vproc = dev_pm_opp_get_voltage(opp); + rcu_read_unlock(); + + /* + * If the new voltage or the intermediate voltage is higher than the + * current voltage, scale up voltage first. + */ + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc; + if (old_vproc < target_vproc) { + ret = mtk_cpufreq_set_voltage(info, target_vproc); + if (ret) { + pr_err("cpu%d: failed to scale up voltage!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, old_vproc); + return ret; + } + } + + /* Reparent the CPU clock to intermediate clock. */ + ret = clk_set_parent(cpu_clk, info->inter_clk); + if (ret) { + pr_err("cpu%d: failed to re-parent cpu clock!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, old_vproc); + WARN_ON(1); + return ret; + } + + /* Set the original PLL to target rate. */ + ret = clk_set_rate(armpll, freq_hz); + if (ret) { + pr_err("cpu%d: failed to scale cpu clock rate!\n", + policy->cpu); + clk_set_parent(cpu_clk, armpll); + mtk_cpufreq_set_voltage(info, old_vproc); + return ret; + } + + /* Set parent of CPU clock back to the original PLL. */ + ret = clk_set_parent(cpu_clk, armpll); + if (ret) { + pr_err("cpu%d: failed to re-parent cpu clock!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, inter_vproc); + WARN_ON(1); + return ret; + } + + /* + * If the new voltage is lower than the intermediate voltage or the + * original voltage, scale down to the new voltage. + */ + if (vproc < inter_vproc || vproc < old_vproc) { + ret = mtk_cpufreq_set_voltage(info, vproc); + if (ret) { + pr_err("cpu%d: failed to scale down voltage!\n", + policy->cpu); + clk_set_parent(cpu_clk, info->inter_clk); + clk_set_rate(armpll, old_freq_hz); + clk_set_parent(cpu_clk, armpll); + return ret; + } + } + + return 0; +} + +static void mtk_cpufreq_ready(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info = policy->driver_data; + struct device_node *np = of_node_get(info->cpu_dev->of_node); + + if (WARN_ON(!np)) + return; + + if (of_find_property(np, "#cooling-cells", NULL)) { + info->cdev = of_cpufreq_cooling_register(np, + policy->related_cpus); + + if (IS_ERR(info->cdev)) { + dev_err(info->cpu_dev, + "running cpufreq without cooling device: %ld\n", + PTR_ERR(info->cdev)); + + info->cdev = NULL; + } + } + + of_node_put(np); +} + +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) +{ + struct device *cpu_dev; + struct regulator *proc_reg = ERR_PTR(-ENODEV); + struct regulator *sram_reg = ERR_PTR(-ENODEV); + struct clk *cpu_clk = ERR_PTR(-ENODEV); + struct clk *inter_clk = ERR_PTR(-ENODEV); + struct dev_pm_opp *opp; + unsigned long rate; + int ret; + + cpu_dev = get_cpu_device(cpu); + if (!cpu_dev) { + pr_err("failed to get cpu%d device\n", cpu); + return -ENODEV; + } + + cpu_clk = clk_get(cpu_dev, "cpu"); + if (IS_ERR(cpu_clk)) { + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER) + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu); + else + pr_err("failed to get cpu clk for cpu%d\n", cpu); + + ret = PTR_ERR(cpu_clk); + return ret; + } + + inter_clk = clk_get(cpu_dev, "intermediate"); + if (IS_ERR(inter_clk)) { + if (PTR_ERR(inter_clk) == -EPROBE_DEFER) + pr_warn("intermediate clk for cpu%d not ready, retry.\n", + cpu); + else + pr_err("failed to get intermediate clk for cpu%d\n", + cpu); + + ret = PTR_ERR(inter_clk); + goto out_free_resources; + } + + proc_reg = regulator_get_exclusive(cpu_dev, "proc"); + if (IS_ERR(proc_reg)) { + if (PTR_ERR(proc_reg) == -EPROBE_DEFER) + pr_warn("proc regulator for cpu%d not ready, retry.\n", + cpu); + else + pr_err("failed to get proc regulator for cpu%d\n", + cpu); + + ret = PTR_ERR(proc_reg); + goto out_free_resources; + } + + /* Both presence and absence of sram regulator are valid cases. */ + sram_reg = regulator_get_exclusive(cpu_dev, "sram"); + + ret = of_init_opp_table(cpu_dev); + if (ret) { + pr_warn("no OPP table for cpu%d\n", cpu); + goto out_free_resources; + } + + /* Search a safe voltage for intermediate frequency. */ + rate = clk_get_rate(inter_clk); + rcu_read_lock(); + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate); + if (IS_ERR(opp)) { + rcu_read_unlock(); + pr_err("failed to get intermediate opp for cpu%d\n", cpu); + ret = PTR_ERR(opp); + goto out_free_opp_table; + } + info->intermediate_voltage = dev_pm_opp_get_voltage(opp); + rcu_read_unlock(); + + info->cpu_dev = cpu_dev; + info->proc_reg = proc_reg; + info->sram_reg = IS_ERR(sram_reg) ? NULL : sram_reg; + info->cpu_clk = cpu_clk; + info->inter_clk = inter_clk; + + /* + * If SRAM regulator is present, software "voltage tracking" is needed + * for this CPU power domain. + */ + info->need_voltage_tracking = !IS_ERR(sram_reg); + + return 0; + +out_free_opp_table: + of_free_opp_table(cpu_dev); + +out_free_resources: + if (!IS_ERR(proc_reg)) + regulator_put(proc_reg); + if (!IS_ERR(sram_reg)) + regulator_put(sram_reg); + if (!IS_ERR(cpu_clk)) + clk_put(cpu_clk); + if (!IS_ERR(inter_clk)) + clk_put(inter_clk); + + return ret; +} + +static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info) +{ + if (!IS_ERR(info->proc_reg)) + regulator_put(info->proc_reg); + if (!IS_ERR(info->sram_reg)) + regulator_put(info->sram_reg); + if (!IS_ERR(info->cpu_clk)) + clk_put(info->cpu_clk); + if (!IS_ERR(info->inter_clk)) + clk_put(info->inter_clk); + + of_free_opp_table(info->cpu_dev); +} + +static int mtk_cpufreq_init(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info; + struct cpufreq_frequency_table *freq_table; + int ret; + + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) + return -ENOMEM; + + ret = mtk_cpu_dvfs_info_init(info, policy->cpu); + if (ret) { + pr_err("%s failed to initialize dvfs info for cpu%d\n", + __func__, policy->cpu); + goto out_free_dvfs_info; + } + + ret = dev_pm_opp_init_cpufreq_table(info->cpu_dev, &freq_table); + if (ret) { + pr_err("failed to init cpufreq table for cpu%d: %d\n", + policy->cpu, ret); + goto out_release_dvfs_info; + } + + ret = cpufreq_table_validate_and_show(policy, freq_table); + if (ret) { + pr_err("%s: invalid frequency table: %d\n", __func__, ret); + goto out_free_cpufreq_table; + } + + /* CPUs in the same cluster share a clock and power domain. */ + cpumask_copy(policy->cpus, &cpu_topology[policy->cpu].core_sibling); + policy->driver_data = info; + policy->clk = info->cpu_clk; + + return 0; + +out_free_cpufreq_table: + dev_pm_opp_free_cpufreq_table(info->cpu_dev, &freq_table); + +out_release_dvfs_info: + mtk_cpu_dvfs_info_release(info); + +out_free_dvfs_info: + kfree(info); + + return ret; +} + +static int mtk_cpufreq_exit(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info = policy->driver_data; + + cpufreq_cooling_unregister(info->cdev); + dev_pm_opp_free_cpufreq_table(info->cpu_dev, &policy->freq_table); + mtk_cpu_dvfs_info_release(info); + kfree(info); + + return 0; +} + +static struct cpufreq_driver mt8173_cpufreq_driver = { + .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK, + .verify = cpufreq_generic_frequency_table_verify, + .target_index = mtk_cpufreq_set_target, + .get = cpufreq_generic_get, + .init = mtk_cpufreq_init, + .exit = mtk_cpufreq_exit, + .ready = mtk_cpufreq_ready, + .name = "mtk-cpufreq", + .attr = cpufreq_generic_attr, +}; + +static int mt8173_cpufreq_probe(struct platform_device *pdev) +{ + int ret; + + ret = cpufreq_register_driver(&mt8173_cpufreq_driver); + if (ret) + pr_err("failed to register mtk cpufreq driver\n"); + + return ret; +} + +static struct platform_driver mt8173_cpufreq_platdrv = { + .driver = { + .name = "mt8173-cpufreq", + }, + .probe = mt8173_cpufreq_probe, +}; + +static int mt8173_cpufreq_driver_init(void) +{ + struct platform_device *pdev; + int err; + + err = platform_driver_register(&mt8173_cpufreq_platdrv); + if (err) + return err; + + /* + * Since there's no place to hold device registration code and no + * device tree based way to match cpufreq driver yet, both the driver + * and the device registration codes are put here to handle defer + * probing. + */ + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0); + if (IS_ERR(pdev)) { + pr_err("failed to register mtk-cpufreq platform device\n"); + return PTR_ERR(pdev); + } + + return 0; +} +device_initcall(mt8173_cpufreq_driver_init);
This patch adds the required properties in device tree to enable MT8173 cpufreq driver.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Viresh Kumar viresh.kumar@linaro.org --- It is based on the top of MT8173 SoC maintainer's tree: https://github.com/mbgg/linux-mediatek.git v4.2-next/arm64 commit id: e26945245e414eff42ee1ffeaedf198911bf1d77 --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++++++++ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 64 +++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index dc4a3e2..ddb1dc1 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -261,6 +261,24 @@ }; };
+&cpu0 { + proc-supply = <&mt6397_vpca15_reg>; +}; + +&cpu1 { + proc-supply = <&mt6397_vpca15_reg>; +}; + +&cpu2 { + proc-supply = <&da9211_vcpu_reg>; + sram-supply = <&mt6397_vsramca7_reg>; +}; + +&cpu3 { + proc-supply = <&da9211_vcpu_reg>; + sram-supply = <&mt6397_vsramca7_reg>; +}; + &uart0 { status = "okay"; }; diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index 359b8b6..47a443d 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi @@ -53,6 +53,22 @@ reg = <0x000>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA53SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + operating-points = < + 507000 859000 + 702000 908000 + 1001000 983000 + 1105000 1009000 + 1183000 1028000 + 1404000 1083000 + 1508000 1109000 + 1573000 1125000 + >; + #cooling-cells = <2>; + #cooling-min-level = <0>; + #cooling-max-level = <7>; };
cpu1: cpu@1 { @@ -61,6 +77,22 @@ reg = <0x001>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA53SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + operating-points = < + 507000 859000 + 702000 908000 + 1001000 983000 + 1105000 1009000 + 1183000 1028000 + 1404000 1083000 + 1508000 1109000 + 1573000 1125000 + >; + #cooling-cells = <2>; + #cooling-min-level = <0>; + #cooling-max-level = <7>; };
cpu2: cpu@100 { @@ -69,6 +101,22 @@ reg = <0x100>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA57SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + operating-points = < + 507000 828000 + 702000 867000 + 1001000 927000 + 1209000 968000 + 1404000 1007000 + 1612000 1049000 + 1807000 1089000 + 1989000 1125000 + >; + #cooling-cells = <2>; + #cooling-min-level = <0>; + #cooling-max-level = <7>; };
cpu3: cpu@101 { @@ -77,6 +125,22 @@ reg = <0x101>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; + clocks = <&infracfg CLK_INFRA_CA57SEL>, + <&apmixedsys CLK_APMIXED_MAINPLL>; + clock-names = "cpu", "intermediate"; + operating-points = < + 507000 828000 + 702000 867000 + 1001000 927000 + 1209000 968000 + 1404000 1007000 + 1612000 1049000 + 1807000 1089000 + 1989000 1125000 + >; + #cooling-cells = <2>; + #cooling-min-level = <0>; + #cooling-max-level = <7>; };
idle-states {
Hi,
On Monday, August 17, 2015 05:24:24 PM Pi-Cheng Chen wrote:
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation:
100mV < Vsram - Vproc < 200mV
which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Viresh Kumar viresh.kumar@linaro.org
drivers/cpufreq/Kconfig.arm | 7 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mt8173-cpufreq.c | 524 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 532 insertions(+) create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
[...]
+static struct platform_driver mt8173_cpufreq_platdrv = {
- .driver = {
.name = "mt8173-cpufreq",- },
- .probe = mt8173_cpufreq_probe,
+};
+static int mt8173_cpufreq_driver_init(void) +{
- struct platform_device *pdev;
- int err;
- err = platform_driver_register(&mt8173_cpufreq_platdrv);
- if (err)
return err;- /*
* Since there's no place to hold device registration code and no* device tree based way to match cpufreq driver yet, both the driver* and the device registration codes are put here to handle defer* probing.*/- pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
This is not very friendly for multiplatform support (mt8173_cpufreq_driver_init() can be called on other platforms, i.e. Samsung Exynos7 one if ARCH_EXYNOS7 is also enabled in the kernel config).
Why can't it be fixed with checking Device Tree with of_machine_is_compatible("mediatek,mt8173") (assuming that it can be used on arm64 like on arm32)?
- if (IS_ERR(pdev)) {
pr_err("failed to register mtk-cpufreq platform device\n");return PTR_ERR(pdev);- }
- return 0;
+} +device_initcall(mt8173_cpufreq_driver_init);
Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
On 18-08-15, 12:09, Bartlomiej Zolnierkiewicz wrote:
- pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
This is not very friendly for multiplatform support (mt8173_cpufreq_driver_init() can be called on other platforms, i.e. Samsung Exynos7 one if ARCH_EXYNOS7 is also enabled in the kernel config).
Why can't it be fixed with checking Device Tree with of_machine_is_compatible("mediatek,mt8173") (assuming that it can be used on arm64 like on arm32)?
Because I asked him to remove that in v5 :( as I somehow had in mind that this wouldn't even compile for other platforms.
@Pi-cheng: Please send v7 only for this patch and add the DT platform check you were doing earlier. Sorry.
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation:
100mV < Vsram - Vproc < 200mV
which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Viresh Kumar viresh.kumar@linaro.org ---
Changes in v7: - add of_machine_is_compatible() check to be multiplatform friendly
--- drivers/cpufreq/Kconfig.arm | 7 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mt8173-cpufreq.c | 527 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 535 insertions(+) create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index cc8a71c..2bacf24 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -130,6 +130,13 @@ config ARM_KIRKWOOD_CPUFREQ This adds the CPUFreq driver for Marvell Kirkwood SoCs.
+config ARM_MT8173_CPUFREQ + bool "Mediatek MT8173 CPUFreq support" + depends on ARCH_MEDIATEK && REGULATOR + select PM_OPP + help + This adds the CPUFreq driver support for Mediatek MT8173 SoC. + config ARM_OMAP2PLUS_CPUFREQ bool "TI OMAP2+" depends on ARCH_OMAP2PLUS diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 2169bf7..9c75faf 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ) += hisi-acpu-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o +obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c new file mode 100644 index 0000000..49caed2 --- /dev/null +++ b/drivers/cpufreq/mt8173-cpufreq.c @@ -0,0 +1,527 @@ +/* + * Copyright (c) 2015 Linaro Ltd. + * Author: Pi-Cheng Chen pi-cheng.chen@linaro.org + * + * 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 program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/cpu.h> +#include <linux/cpu_cooling.h> +#include <linux/cpufreq.h> +#include <linux/cpumask.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_opp.h> +#include <linux/regulator/consumer.h> +#include <linux/slab.h> +#include <linux/thermal.h> + +#define MIN_VOLT_SHIFT (100000) +#define MAX_VOLT_SHIFT (200000) +#define MAX_VOLT_LIMIT (1150000) +#define VOLT_TOL (10000) + +/* + * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU DVFS + * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in + * Mediatek SoCs has two voltage inputs, Vproc and Vsram. In some cases the two + * voltage inputs need to be controlled under a hardware limitation: + * 100mV < Vsram - Vproc < 200mV + * + * When scaling the clock frequency of a CPU clock domain, the clock source + * needs to be switched to another stable PLL clock temporarily until + * the original PLL becomes stable at target frequency. + */ +struct mtk_cpu_dvfs_info { + struct device *cpu_dev; + struct regulator *proc_reg; + struct regulator *sram_reg; + struct clk *cpu_clk; + struct clk *inter_clk; + struct thermal_cooling_device *cdev; + int intermediate_voltage; + bool need_voltage_tracking; +}; + +static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info, + int new_vproc) +{ + struct regulator *proc_reg = info->proc_reg; + struct regulator *sram_reg = info->sram_reg; + int old_vproc, old_vsram, new_vsram, vsram, vproc, ret; + + old_vproc = regulator_get_voltage(proc_reg); + old_vsram = regulator_get_voltage(sram_reg); + /* Vsram should not exceed the maximum allowed voltage of SoC. */ + new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT); + + if (old_vproc < new_vproc) { + /* + * When scaling up voltages, Vsram and Vproc scale up step + * by step. At each step, set Vsram to (Vproc + 200mV) first, + * then set Vproc to (Vsram - 100mV). + * Keep doing it until Vsram and Vproc hit target voltages. + */ + do { + old_vsram = regulator_get_voltage(sram_reg); + old_vproc = regulator_get_voltage(proc_reg); + + vsram = min(new_vsram, old_vproc + MAX_VOLT_SHIFT); + + if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) { + vsram = MAX_VOLT_LIMIT; + + /* + * If the target Vsram hits the maximum voltage, + * try to set the exact voltage value first. + */ + ret = regulator_set_voltage(sram_reg, vsram, + vsram); + if (ret) + ret = regulator_set_voltage(sram_reg, + vsram - VOLT_TOL, + vsram); + + vproc = new_vproc; + } else { + ret = regulator_set_voltage(sram_reg, vsram, + vsram + VOLT_TOL); + + vproc = vsram - MIN_VOLT_SHIFT; + } + if (ret) + return ret; + + ret = regulator_set_voltage(proc_reg, vproc, + vproc + VOLT_TOL); + if (ret) { + regulator_set_voltage(sram_reg, old_vsram, + old_vsram); + return ret; + } + } while (vproc < new_vproc || vsram < new_vsram); + } else if (old_vproc > new_vproc) { + /* + * When scaling down voltages, Vsram and Vproc scale down step + * by step. At each step, set Vproc to (Vsram - 200mV) first, + * then set Vproc to (Vproc + 100mV). + * Keep doing it until Vsram and Vproc hit target voltages. + */ + do { + old_vproc = regulator_get_voltage(proc_reg); + old_vsram = regulator_get_voltage(sram_reg); + + vproc = max(new_vproc, old_vsram - MAX_VOLT_SHIFT); + ret = regulator_set_voltage(proc_reg, vproc, + vproc + VOLT_TOL); + if (ret) + return ret; + + if (vproc == new_vproc) + vsram = new_vsram; + else + vsram = max(new_vsram, vproc + MIN_VOLT_SHIFT); + + if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) { + vsram = MAX_VOLT_LIMIT; + + /* + * If the target Vsram hits the maximum voltage, + * try to set the exact voltage value first. + */ + ret = regulator_set_voltage(sram_reg, vsram, + vsram); + if (ret) + ret = regulator_set_voltage(sram_reg, + vsram - VOLT_TOL, + vsram); + } else { + ret = regulator_set_voltage(sram_reg, vsram, + vsram + VOLT_TOL); + } + + if (ret) { + regulator_set_voltage(proc_reg, old_vproc, + old_vproc); + return ret; + } + } while (vproc > new_vproc + VOLT_TOL || + vsram > new_vsram + VOLT_TOL); + } + + return 0; +} + +static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc) +{ + if (info->need_voltage_tracking) + return mtk_cpufreq_voltage_tracking(info, vproc); + else + return regulator_set_voltage(info->proc_reg, vproc, + vproc + VOLT_TOL); +} + +static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, + unsigned int index) +{ + struct cpufreq_frequency_table *freq_table = policy->freq_table; + struct clk *cpu_clk = policy->clk; + struct clk *armpll = clk_get_parent(cpu_clk); + struct mtk_cpu_dvfs_info *info = policy->driver_data; + struct device *cpu_dev = info->cpu_dev; + struct dev_pm_opp *opp; + long freq_hz, old_freq_hz; + int vproc, old_vproc, inter_vproc, target_vproc, ret; + + inter_vproc = info->intermediate_voltage; + + old_freq_hz = clk_get_rate(cpu_clk); + old_vproc = regulator_get_voltage(info->proc_reg); + + freq_hz = freq_table[index].frequency * 1000; + + rcu_read_lock(); + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_hz); + if (IS_ERR(opp)) { + rcu_read_unlock(); + pr_err("cpu%d: failed to find OPP for %ld\n", + policy->cpu, freq_hz); + return PTR_ERR(opp); + } + vproc = dev_pm_opp_get_voltage(opp); + rcu_read_unlock(); + + /* + * If the new voltage or the intermediate voltage is higher than the + * current voltage, scale up voltage first. + */ + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc; + if (old_vproc < target_vproc) { + ret = mtk_cpufreq_set_voltage(info, target_vproc); + if (ret) { + pr_err("cpu%d: failed to scale up voltage!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, old_vproc); + return ret; + } + } + + /* Reparent the CPU clock to intermediate clock. */ + ret = clk_set_parent(cpu_clk, info->inter_clk); + if (ret) { + pr_err("cpu%d: failed to re-parent cpu clock!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, old_vproc); + WARN_ON(1); + return ret; + } + + /* Set the original PLL to target rate. */ + ret = clk_set_rate(armpll, freq_hz); + if (ret) { + pr_err("cpu%d: failed to scale cpu clock rate!\n", + policy->cpu); + clk_set_parent(cpu_clk, armpll); + mtk_cpufreq_set_voltage(info, old_vproc); + return ret; + } + + /* Set parent of CPU clock back to the original PLL. */ + ret = clk_set_parent(cpu_clk, armpll); + if (ret) { + pr_err("cpu%d: failed to re-parent cpu clock!\n", + policy->cpu); + mtk_cpufreq_set_voltage(info, inter_vproc); + WARN_ON(1); + return ret; + } + + /* + * If the new voltage is lower than the intermediate voltage or the + * original voltage, scale down to the new voltage. + */ + if (vproc < inter_vproc || vproc < old_vproc) { + ret = mtk_cpufreq_set_voltage(info, vproc); + if (ret) { + pr_err("cpu%d: failed to scale down voltage!\n", + policy->cpu); + clk_set_parent(cpu_clk, info->inter_clk); + clk_set_rate(armpll, old_freq_hz); + clk_set_parent(cpu_clk, armpll); + return ret; + } + } + + return 0; +} + +static void mtk_cpufreq_ready(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info = policy->driver_data; + struct device_node *np = of_node_get(info->cpu_dev->of_node); + + if (WARN_ON(!np)) + return; + + if (of_find_property(np, "#cooling-cells", NULL)) { + info->cdev = of_cpufreq_cooling_register(np, + policy->related_cpus); + + if (IS_ERR(info->cdev)) { + dev_err(info->cpu_dev, + "running cpufreq without cooling device: %ld\n", + PTR_ERR(info->cdev)); + + info->cdev = NULL; + } + } + + of_node_put(np); +} + +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) +{ + struct device *cpu_dev; + struct regulator *proc_reg = ERR_PTR(-ENODEV); + struct regulator *sram_reg = ERR_PTR(-ENODEV); + struct clk *cpu_clk = ERR_PTR(-ENODEV); + struct clk *inter_clk = ERR_PTR(-ENODEV); + struct dev_pm_opp *opp; + unsigned long rate; + int ret; + + cpu_dev = get_cpu_device(cpu); + if (!cpu_dev) { + pr_err("failed to get cpu%d device\n", cpu); + return -ENODEV; + } + + cpu_clk = clk_get(cpu_dev, "cpu"); + if (IS_ERR(cpu_clk)) { + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER) + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu); + else + pr_err("failed to get cpu clk for cpu%d\n", cpu); + + ret = PTR_ERR(cpu_clk); + return ret; + } + + inter_clk = clk_get(cpu_dev, "intermediate"); + if (IS_ERR(inter_clk)) { + if (PTR_ERR(inter_clk) == -EPROBE_DEFER) + pr_warn("intermediate clk for cpu%d not ready, retry.\n", + cpu); + else + pr_err("failed to get intermediate clk for cpu%d\n", + cpu); + + ret = PTR_ERR(inter_clk); + goto out_free_resources; + } + + proc_reg = regulator_get_exclusive(cpu_dev, "proc"); + if (IS_ERR(proc_reg)) { + if (PTR_ERR(proc_reg) == -EPROBE_DEFER) + pr_warn("proc regulator for cpu%d not ready, retry.\n", + cpu); + else + pr_err("failed to get proc regulator for cpu%d\n", + cpu); + + ret = PTR_ERR(proc_reg); + goto out_free_resources; + } + + /* Both presence and absence of sram regulator are valid cases. */ + sram_reg = regulator_get_exclusive(cpu_dev, "sram"); + + ret = of_init_opp_table(cpu_dev); + if (ret) { + pr_warn("no OPP table for cpu%d\n", cpu); + goto out_free_resources; + } + + /* Search a safe voltage for intermediate frequency. */ + rate = clk_get_rate(inter_clk); + rcu_read_lock(); + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate); + if (IS_ERR(opp)) { + rcu_read_unlock(); + pr_err("failed to get intermediate opp for cpu%d\n", cpu); + ret = PTR_ERR(opp); + goto out_free_opp_table; + } + info->intermediate_voltage = dev_pm_opp_get_voltage(opp); + rcu_read_unlock(); + + info->cpu_dev = cpu_dev; + info->proc_reg = proc_reg; + info->sram_reg = IS_ERR(sram_reg) ? NULL : sram_reg; + info->cpu_clk = cpu_clk; + info->inter_clk = inter_clk; + + /* + * If SRAM regulator is present, software "voltage tracking" is needed + * for this CPU power domain. + */ + info->need_voltage_tracking = !IS_ERR(sram_reg); + + return 0; + +out_free_opp_table: + of_free_opp_table(cpu_dev); + +out_free_resources: + if (!IS_ERR(proc_reg)) + regulator_put(proc_reg); + if (!IS_ERR(sram_reg)) + regulator_put(sram_reg); + if (!IS_ERR(cpu_clk)) + clk_put(cpu_clk); + if (!IS_ERR(inter_clk)) + clk_put(inter_clk); + + return ret; +} + +static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info) +{ + if (!IS_ERR(info->proc_reg)) + regulator_put(info->proc_reg); + if (!IS_ERR(info->sram_reg)) + regulator_put(info->sram_reg); + if (!IS_ERR(info->cpu_clk)) + clk_put(info->cpu_clk); + if (!IS_ERR(info->inter_clk)) + clk_put(info->inter_clk); + + of_free_opp_table(info->cpu_dev); +} + +static int mtk_cpufreq_init(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info; + struct cpufreq_frequency_table *freq_table; + int ret; + + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) + return -ENOMEM; + + ret = mtk_cpu_dvfs_info_init(info, policy->cpu); + if (ret) { + pr_err("%s failed to initialize dvfs info for cpu%d\n", + __func__, policy->cpu); + goto out_free_dvfs_info; + } + + ret = dev_pm_opp_init_cpufreq_table(info->cpu_dev, &freq_table); + if (ret) { + pr_err("failed to init cpufreq table for cpu%d: %d\n", + policy->cpu, ret); + goto out_release_dvfs_info; + } + + ret = cpufreq_table_validate_and_show(policy, freq_table); + if (ret) { + pr_err("%s: invalid frequency table: %d\n", __func__, ret); + goto out_free_cpufreq_table; + } + + /* CPUs in the same cluster share a clock and power domain. */ + cpumask_copy(policy->cpus, &cpu_topology[policy->cpu].core_sibling); + policy->driver_data = info; + policy->clk = info->cpu_clk; + + return 0; + +out_free_cpufreq_table: + dev_pm_opp_free_cpufreq_table(info->cpu_dev, &freq_table); + +out_release_dvfs_info: + mtk_cpu_dvfs_info_release(info); + +out_free_dvfs_info: + kfree(info); + + return ret; +} + +static int mtk_cpufreq_exit(struct cpufreq_policy *policy) +{ + struct mtk_cpu_dvfs_info *info = policy->driver_data; + + cpufreq_cooling_unregister(info->cdev); + dev_pm_opp_free_cpufreq_table(info->cpu_dev, &policy->freq_table); + mtk_cpu_dvfs_info_release(info); + kfree(info); + + return 0; +} + +static struct cpufreq_driver mt8173_cpufreq_driver = { + .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK, + .verify = cpufreq_generic_frequency_table_verify, + .target_index = mtk_cpufreq_set_target, + .get = cpufreq_generic_get, + .init = mtk_cpufreq_init, + .exit = mtk_cpufreq_exit, + .ready = mtk_cpufreq_ready, + .name = "mtk-cpufreq", + .attr = cpufreq_generic_attr, +}; + +static int mt8173_cpufreq_probe(struct platform_device *pdev) +{ + int ret; + + ret = cpufreq_register_driver(&mt8173_cpufreq_driver); + if (ret) + pr_err("failed to register mtk cpufreq driver\n"); + + return ret; +} + +static struct platform_driver mt8173_cpufreq_platdrv = { + .driver = { + .name = "mt8173-cpufreq", + }, + .probe = mt8173_cpufreq_probe, +}; + +static int mt8173_cpufreq_driver_init(void) +{ + struct platform_device *pdev; + int err; + + if (!of_machine_is_compatible("mediatek,mt8173")) + return -ENODEV; + + err = platform_driver_register(&mt8173_cpufreq_platdrv); + if (err) + return err; + + /* + * Since there's no place to hold device registration code and no + * device tree based way to match cpufreq driver yet, both the driver + * and the device registration codes are put here to handle defer + * probing. + */ + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0); + if (IS_ERR(pdev)) { + pr_err("failed to register mtk-cpufreq platform device\n"); + return PTR_ERR(pdev); + } + + return 0; +} +device_initcall(mt8173_cpufreq_driver_init);
On 19-08-15, 10:05, Pi-Cheng Chen wrote:
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation:
100mV < Vsram - Vproc < 200mV
which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.chen@linaro.org Acked-by: Viresh Kumar viresh.kumar@linaro.org
Changes in v7:
- add of_machine_is_compatible() check to be multiplatform friendly
Looks fine, thanks.
On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen pi-cheng.chen@linaro.org wrote:
MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster share the same power and clock domain. This series tries to add cpufreq support for MT8173 SoC. The v6 of this series is resent with Acks added.
Hi Rafael,
Not sure if I has missed the merge window. Do I have chance to have this series merged for 4.3? Would you please take [1,2] of this series? Thanks.
Best Regards, Pi-Cheng
changes in v6:
- Move clock and regulator consumer properties document to the device tree bindings documents of MT8173 CPU DVFS clock driver
- Add change log to describe what is implemented in the MT8173 cpufreq driver
- Add missed rcu_read_unlock() in the error path
- Move of_init_opp_table() call to make sure all required hardware resources are already there before it is called
- Add comments to describe why both platform driver and deivce registration codes are put in the initcall function
- Use the term "voltage tracking" instead of "voltage trace" according to an internal SoC document
changes in v5:
- Move resource allocation code from init() into probe() and remove some unused functions due to this change
- Fix descriptions for device tree binding document
- Address review comments for last version
- Register CPU cooling device
Changes in v4:
- Add bindings for MT8173 cpufreq driver
- Move OPP table back into device tree
- Address comments for last version
Changes in v3:
- Implement MT8173 specific standalone cpufreq driver instead of using cpufreq-dt driver
- Define OPP table in the driver source code until new OPP binding is ready
Changes in v2:
- Add intermediate frequency support in cpufreq-dt driver
- Use voltage scaling code of cpufreq-dt for little cluster instead of implementaion in notifier of mtk-cpufreq driver
- Code refinement for mtk-cpufreq driver
Pi-Cheng Chen (3): dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings cpufreq: mediatek: Add MT8173 cpufreq driver arm64: dts: mt8173: Add mt8173 cpufreq driver support
.../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 ++++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 64 +++ drivers/cpufreq/Kconfig.arm | 7 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mt8173-cpufreq.c | 524 +++++++++++++++++++++ 6 files changed, 697 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
-- 1.9.1
On Tuesday, August 25, 2015 10:10:44 AM Pi-Cheng Chen wrote:
On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen pi-cheng.chen@linaro.org wrote:
MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster share the same power and clock domain. This series tries to add cpufreq support for MT8173 SoC. The v6 of this series is resent with Acks added.
Hi Rafael,
Not sure if I has missed the merge window. Do I have chance to have this series merged for 4.3?
Yes, it should make it.
Would you please take [1,2] of this series?
I'm not sure what you mean. Are you withdrawing the [3/3]?
Thanks, Rafael
Hi Rafael,
On Wed, Aug 26, 2015 at 7:01 AM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Tuesday, August 25, 2015 10:10:44 AM Pi-Cheng Chen wrote:
On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen pi-cheng.chen@linaro.org wrote:
MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster share the same power and clock domain. This series tries to add cpufreq support for MT8173 SoC. The v6 of this series is resent with Acks added.
Hi Rafael,
Not sure if I has missed the merge window. Do I have chance to have this series merged for 4.3?
Yes, it should make it.
Would you please take [1,2] of this series?
Thanks.
I'm not sure what you mean. Are you withdrawing the [3/3]?
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
@Matthias?
Thanks
Best Regards, Pi-Cheng
[1] https://github.com/mbgg/linux-mediatek.git v4.2-next/arm64 [2] http://article.gmane.org/gmane.linux.kernel/2021379
Thanks, Rafael
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
@Matthias, Would you please apply [3/3] of this series?
Thanks.
Best Regards, Pi-Cheng
-- viresh
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Matthias,
On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Can you please apply [3] from this set to your dts tree?
-- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 02/09/15 08:45, Daniel Kurtz wrote:
Matthias,
On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Can you please apply [3] from this set to your dts tree?
I will as soon as v4.3-rc1 shows up.
On 02/09/15 19:23, Matthias Brugger wrote:
On 02/09/15 08:45, Daniel Kurtz wrote:
Matthias,
On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will cause some conflicts if it goes through your tree. I am not sure how this should be handled, but should it be merged through Mediatek SoC maintainer tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Can you please apply [3] from this set to your dts tree?
I will as soon as v4.3-rc1 shows up.
I somehow forgot this patch. Sorry for that. Applied for v4.6-next/dts64 right now.
Regards, Matthias
On 21/04/16 12:26, Matthias Brugger wrote:
On 02/09/15 19:23, Matthias Brugger wrote:
On 02/09/15 08:45, Daniel Kurtz wrote:
Matthias,
On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-08-15, 09:25, Pi-Cheng Chen wrote: > The [3/3] is based on Mediatek SoC maintainer tree[1] and the > patch which > introduce a new clock type[2] consumed by MT8173 cpufreq driver. > So it will > cause some conflicts if it goes through your tree. I am not sure > how this > should be handled, but should it be merged through Mediatek SoC > maintainer > tree?
Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Can you please apply [3] from this set to your dts tree?
I will as soon as v4.3-rc1 shows up.
I somehow forgot this patch. Sorry for that. Applied for v4.6-next/dts64 right now.
I just realized that CLK_INFRA_CA53SEL and CLK_APMIXED_MAINPLL are not part of the clk driver.
Pi-Cheng, can you check if they got renamed in the meanwhile? Or do we need some clock driver patches that enable this clocks for the series?
Regards, Matthias
Hi Matthias,
On Thu, 2016-04-21 at 12:58 +0200, Matthias Brugger wrote:
On 21/04/16 12:26, Matthias Brugger wrote:
On 02/09/15 19:23, Matthias Brugger wrote:
On 02/09/15 08:45, Daniel Kurtz wrote:
Matthias,
On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote:
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.kumar@linaro.org wrote: > On 26-08-15, 09:25, Pi-Cheng Chen wrote: >> The [3/3] is based on Mediatek SoC maintainer tree[1] and the >> patch which >> introduce a new clock type[2] consumed by MT8173 cpufreq driver. >> So it will >> cause some conflicts if it goes through your tree. I am not sure >> how this >> should be handled, but should it be merged through Mediatek SoC >> maintainer >> tree? > > Just get that applied to MTK tree, it doesn't have any dependency on > rest of the patches for build/boot. The only thing is that cpufreq > wouldn't work and it will work as soon as Rafael's and MTK's trees > are > merged by Linus.
Thanks for your explanation.
@Rafael, Would you please apply [1,2] to your tree?
Applied, thanks!
Can you please apply [3] from this set to your dts tree?
I will as soon as v4.3-rc1 shows up.
I somehow forgot this patch. Sorry for that. Applied for v4.6-next/dts64 right now.
I just realized that CLK_INFRA_CA53SEL and CLK_APMIXED_MAINPLL are not part of the clk driver.
Pi-Cheng, can you check if they got renamed in the meanwhile? Or do we need some clock driver patches that enable this clocks for the series?
Thanks your notice. Unfortunately, we still have no chance let patch with these two clock merged. The last version is [1]. This clock patch will block cpufreq dts [2] and dynamic power dts [3]. Clock maintainer is working on new architecture [4], hopefully we can send new clock patch soon. After that, we will send new cpufreq and dynamic power dts. So please ignore [2] [3] at this moment.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/369737.... [2] https://lkml.org/lkml/2015/7/9/206 [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/423899.html [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418796.html
Eddie Thanks
linaro-kernel@lists.linaro.org
-
Bartlomiej Zolnierkiewicz -
Daniel Kurtz -
Eddie Huang -
Matthias Brugger -
Pi-Cheng Chen -
Rafael J. Wysocki -
Viresh Kumar