* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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 -- 1.9.1 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: linux-arm-kernel 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 -- 1.9.1 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Michael Turquette, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings 2015-08-17 9:24 ` Pi-Cheng Chen @ 2015-08-17 9:24 ` Pi-Cheng Chen -1 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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>; + }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 at 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 at 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 at 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>; + }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver 2015-08-17 9:24 ` Pi-Cheng Chen @ 2015-08-17 9:24 ` Pi-Cheng Chen -1 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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); -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: linux-arm-kernel 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@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); -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 53+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2015-08-18 10:09 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 53+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2015-08-18 10:09 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 53+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2015-08-18 10:09 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz @ 2015-08-18 10:24 ` Viresh Kumar -1 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-18 10:24 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Pi-Cheng Chen, Rafael J. Wysocki, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-18 10:24 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-18 10:24 UTC (permalink / raw) To: linux-arm-kernel 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver 2015-08-18 10:24 ` Viresh Kumar @ 2015-08-19 2:05 ` Pi-Cheng Chen -1 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-19 2:05 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Bartlomiej Zolnierkiewicz, Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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); -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-19 2:05 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-19 2:05 UTC (permalink / raw) To: linux-arm-kernel 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@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); -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-19 5:41 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-19 5:41 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Matthias Brugger, Mark Rutland, Bartlomiej Zolnierkiewicz, Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-19 5:41 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-19 5:41 UTC (permalink / raw) To: linux-arm-kernel 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver @ 2015-08-19 5:41 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-19 5:41 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Matthias Brugger, Mark Rutland, Bartlomiej Zolnierkiewicz, Michael Turquette, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > --- > > Changes in v7: > - add of_machine_is_compatible() check to be multiplatform friendly Looks fine, thanks. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: Michael Turquette, devicetree, linux-arm-kernel, linux-kernel, linux-pm, linaro-kernel, linux-mediatek 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 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 at 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 at 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 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* [RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support @ 2015-08-17 9:24 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-17 9:24 UTC (permalink / raw) To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger, Mark Rutland Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Michael Turquette, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r This patch adds the required properties in device tree to enable MT8173 cpufreq driver. Signed-off-by: Pi-Cheng Chen <pi-cheng.chen-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-25 2:10 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-25 2:10 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 > ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-25 2:10 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-25 2:10 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-25 2:10 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-25 2:10 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux Kernel Mailing List, linux-pm-u79uwXL29TY76Z2rM5mHXA, Linaro Kernel Mailman List, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen <pi-cheng.chen-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-25 2:10 ` Pi-Cheng Chen (?) @ 2015-08-25 23:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-25 23:01 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-25 23:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-25 23:01 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-25 23:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-25 23:01 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-25 23:01 ` Rafael J. Wysocki (?) @ 2015-08-26 1:25 ` Pi-Cheng Chen -1 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 1:25 UTC (permalink / raw) To: Rafael J. Wysocki, Matthias Brugger Cc: Viresh Kumar, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 > ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 1:25 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 1:25 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 1:25 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 1:25 UTC (permalink / raw) To: Rafael J. Wysocki, Matthias Brugger Cc: Viresh Kumar, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-26 1:25 ` Pi-Cheng Chen (?) @ 2015-08-26 2:16 ` Viresh Kumar -1 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-26 2:16 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 2:16 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-26 2:16 UTC (permalink / raw) To: linux-arm-kernel 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 2:16 ` Viresh Kumar 0 siblings, 0 replies; 53+ messages in thread From: Viresh Kumar @ 2015-08-26 2:16 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Rafael J. Wysocki, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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. -- viresh ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-26 2:16 ` Viresh Kumar (?) @ 2015-08-26 6:53 ` Pi-Cheng Chen -1 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 6:53 UTC (permalink / raw) To: Viresh Kumar, Rafael J. Wysocki, Matthias Brugger Cc: Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 6:53 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 6:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-26 6:53 ` Pi-Cheng Chen 0 siblings, 0 replies; 53+ messages in thread From: Pi-Cheng Chen @ 2015-08-26 6:53 UTC (permalink / raw) To: Viresh Kumar, Rafael J. Wysocki, Matthias Brugger Cc: Mark Rutland, Michael Turquette, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux Kernel Mailing List, linux-pm-u79uwXL29TY76Z2rM5mHXA, Linaro Kernel Mailman List, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-26 6:53 ` Pi-Cheng Chen (?) @ 2015-08-28 14:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-28 14:06 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-28 14:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-28 14:06 UTC (permalink / raw) To: linux-arm-kernel 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! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-08-28 14:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 53+ messages in thread From: Rafael J. Wysocki @ 2015-08-28 14:06 UTC (permalink / raw) To: Pi-Cheng Chen Cc: Viresh Kumar, Matthias Brugger, Mark Rutland, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-08-28 14:06 ` Rafael J. Wysocki (?) @ 2015-09-02 6:45 ` Daniel Kurtz -1 siblings, 0 replies; 53+ messages in thread From: Daniel Kurtz @ 2015-09-02 6:45 UTC (permalink / raw) To: Matthias Brugger Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-09-02 6:45 ` Daniel Kurtz 0 siblings, 0 replies; 53+ messages in thread From: Daniel Kurtz @ 2015-09-02 6:45 UTC (permalink / raw) To: linux-arm-kernel 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 at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-09-02 6:45 ` Daniel Kurtz 0 siblings, 0 replies; 53+ messages in thread From: Daniel Kurtz @ 2015-09-02 6:45 UTC (permalink / raw) To: Matthias Brugger Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-09-02 6:45 ` Daniel Kurtz (?) @ 2015-09-02 17:23 ` Matthias Brugger -1 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2015-09-02 17:23 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-09-02 17:23 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2015-09-02 17:23 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2015-09-02 17:23 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2015-09-02 17:23 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2015-09-02 17:23 ` Matthias Brugger (?) @ 2016-04-21 10:26 ` Matthias Brugger -1 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:26 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 10:26 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:26 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 10:26 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:26 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2016-04-21 10:26 ` Matthias Brugger (?) @ 2016-04-21 10:58 ` Matthias Brugger -1 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:58 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 10:58 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:58 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 10:58 ` Matthias Brugger 0 siblings, 0 replies; 53+ messages in thread From: Matthias Brugger @ 2016-04-21 10:58 UTC (permalink / raw) To: Daniel Kurtz Cc: Pi-Cheng Chen, Viresh Kumar, Mark Rutland, Rafael J. Wysocki, Michael Turquette, devicetree, linux-arm-kernel, Linux Kernel Mailing List, linux-pm, Linaro Kernel Mailman List, linux-mediatek 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver 2016-04-21 10:58 ` Matthias Brugger (?) @ 2016-04-21 11:37 ` Eddie Huang -1 siblings, 0 replies; 53+ messages in thread From: Eddie Huang @ 2016-04-21 11:37 UTC (permalink / raw) To: Matthias Brugger Cc: Daniel Kurtz, Mark Rutland, devicetree, Linaro Kernel Mailman List, linux-pm, Viresh Kumar, Michael Turquette, Rafael J. Wysocki, Linux Kernel Mailing List, linux-mediatek, Pi-Cheng Chen, linux-arm-kernel 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.html [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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 11:37 ` Eddie Huang 0 siblings, 0 replies; 53+ messages in thread From: Eddie Huang @ 2016-04-21 11:37 UTC (permalink / raw) To: linux-arm-kernel 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.html [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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver @ 2016-04-21 11:37 ` Eddie Huang 0 siblings, 0 replies; 53+ messages in thread From: Eddie Huang @ 2016-04-21 11:37 UTC (permalink / raw) To: Matthias Brugger Cc: Daniel Kurtz, Mark Rutland, devicetree, Linaro Kernel Mailman List, linux-pm, Viresh Kumar, Michael Turquette, Rafael J. Wysocki, Linux Kernel Mailing List, linux-mediatek, Pi-Cheng Chen, linux-arm-kernel 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.html [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 ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2016-04-21 11:38 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-17 9:24 [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-17 9:24 ` [RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-17 9:24 ` [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 2015-08-18 10:09 ` Bartlomiej Zolnierkiewicz 2015-08-18 10:24 ` Viresh Kumar 2015-08-18 10:24 ` Viresh Kumar 2015-08-19 2:05 ` [PATCH v7 2/3] " Pi-Cheng Chen 2015-08-19 2:05 ` Pi-Cheng Chen 2015-08-19 5:41 ` Viresh Kumar 2015-08-19 5:41 ` Viresh Kumar 2015-08-19 5:41 ` Viresh Kumar 2015-08-17 9:24 ` [RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-17 9:24 ` Pi-Cheng Chen 2015-08-25 2:10 ` [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver Pi-Cheng Chen 2015-08-25 2:10 ` Pi-Cheng Chen 2015-08-25 2:10 ` Pi-Cheng Chen 2015-08-25 23:01 ` Rafael J. Wysocki 2015-08-25 23:01 ` Rafael J. Wysocki 2015-08-25 23:01 ` Rafael J. Wysocki 2015-08-26 1:25 ` Pi-Cheng Chen 2015-08-26 1:25 ` Pi-Cheng Chen 2015-08-26 1:25 ` Pi-Cheng Chen 2015-08-26 2:16 ` Viresh Kumar 2015-08-26 2:16 ` Viresh Kumar 2015-08-26 2:16 ` Viresh Kumar 2015-08-26 6:53 ` Pi-Cheng Chen 2015-08-26 6:53 ` Pi-Cheng Chen 2015-08-26 6:53 ` Pi-Cheng Chen 2015-08-28 14:06 ` Rafael J. Wysocki 2015-08-28 14:06 ` Rafael J. Wysocki 2015-08-28 14:06 ` Rafael J. Wysocki 2015-09-02 6:45 ` Daniel Kurtz 2015-09-02 6:45 ` Daniel Kurtz 2015-09-02 6:45 ` Daniel Kurtz 2015-09-02 17:23 ` Matthias Brugger 2015-09-02 17:23 ` Matthias Brugger 2015-09-02 17:23 ` Matthias Brugger 2016-04-21 10:26 ` Matthias Brugger 2016-04-21 10:26 ` Matthias Brugger 2016-04-21 10:26 ` Matthias Brugger 2016-04-21 10:58 ` Matthias Brugger 2016-04-21 10:58 ` Matthias Brugger 2016-04-21 10:58 ` Matthias Brugger 2016-04-21 11:37 ` Eddie Huang 2016-04-21 11:37 ` Eddie Huang 2016-04-21 11:37 ` Eddie Huang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.