[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings

[Pi-Cheng Chen]

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

[RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings

[Pi-Cheng Chen]

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

[RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support

[Pi-Cheng Chen]

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

[RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support

[Pi-Cheng Chen]

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

[RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support

[Pi-Cheng Chen]

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

Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Bartlomiej Zolnierkiewicz]

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

Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Bartlomiej Zolnierkiewicz]

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

[RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Bartlomiej Zolnierkiewicz]

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

Re: [RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

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

[RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

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

[PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

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

Re: [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

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

Re: [PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

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

[PATCH v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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
>

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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
>

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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
>

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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
>

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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
>

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Viresh Kumar]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Viresh Kumar]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Viresh Kumar]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Pi-Cheng Chen]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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.

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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.

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Rafael J. Wysocki]

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.

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Daniel Kurtz]

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/

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Daniel Kurtz]

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/

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Daniel Kurtz]

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/

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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.

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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.

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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.

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Matthias Brugger]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Eddie Huang]

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

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Eddie Huang]

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

[RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

[Eddie Huang]

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