* [PATCH v2 1/2] slimbus: ngd: dt-bindings: Add slim ngd dt bindings
From: Srinivas Kandagatla @ 2018-05-25 11:15 UTC (permalink / raw)
To: gregkh, robh+dt
Cc: kramasub, sdharia, girishm, linux-kernel, mark.rutland, bgoswami,
devicetree, broonie, linux-arm-msm, alsa-devel,
srinivas.kandagatla
In-Reply-To: <20180525111547.18556-1-srinivas.kandagatla@linaro.org>
This patch adds bindings for Qualcomm SLIMBus NGD controller.
SLIMBus NGD controller is a light-weight driver responsible for
communicating with SLIMBus slaves directly over the bus using messaging
interface and communicating with master component residing on ADSP for
bandwidth and data-channel management
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
.../bindings/slimbus/slim-ngd-qcom-ctrl.txt | 84 ++++++++++++++++++++++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
diff --git a/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
new file mode 100644
index 000000000000..e94a2ad3a710
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
@@ -0,0 +1,84 @@
+Qualcomm SLIMBus Non Generic Device (NGD) Controller binding
+
+SLIMBus NGD controller is a light-weight driver responsible for communicating
+with SLIMBus slaves directly over the bus using messaging interface and
+communicating with master component residing on ADSP for bandwidth and
+data-channel management
+
+Please refer to slimbus/bus.txt for details of the common SLIMBus bindings.
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "qcom,slim-ngd-v<MAJOR>.<MINOR>.<STEP>"
+ must be one of the following.
+ "qcom,slim-ngd-v1.5.0" for MSM8996
+ "qcom,slim-ngd-v2.1.0" for SDM845
+
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: must specify the base address and size of the controller
+ register space.
+- dmas
+ Usage: required
+ Value type: <array of phandles>
+ Definition: List of rx and tx dma channels
+
+- dma-names
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "rx" and "tx".
+
+- interrupts:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: must list controller IRQ.
+
+#address-cells
+ Usage: required
+ Value type: <u32>
+ Definition: Should be 1, reflecting the instance id of ngd.
+
+#size-cells
+ Usage: required
+ Value type: <u32>
+ Definition: Should be 0
+
+= NGD Devices
+Each subnode represents an instance of NGD, must contain the following
+properties:
+
+- reg:
+ Usage: required
+ Value type: <u32>
+ Definition: Should be instance id of ngd.
+
+#address-cells
+ Usage: required
+ Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
+
+#size-cells
+ Usage: required
+ Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
+
+= EXAMPLE
+
+slim@91c0000 {
+ compatible = "qcom,slim-ngd-v1.5.0";
+ reg = <0x91c0000 0x2c000>;
+ interrupts = <0 163 0>;
+ dmas = <&slimbam 3>, <&slimbam 4>;
+ dma-names = "rx", "tx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ngd@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ codec@1 {
+ compatible = "slim217,1a0";
+ reg = <1 0>;
+ };
+ };
+};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 0/2] slimbus: Add QCOM SLIMBus NGD driver
From: Srinivas Kandagatla @ 2018-05-25 11:15 UTC (permalink / raw)
To: gregkh, robh+dt
Cc: mark.rutland, devicetree, alsa-devel, girishm, linux-arm-msm,
broonie, linux-kernel, bgoswami, kramasub, srinivas.kandagatla,
sdharia
This patchset adds support to basic version of Qualcomm NGD SLIMBus
controller driver found SoCs from B family.
This controller is light-weight SLIMBus controller driver responsible for
communicating with slave HW directly over the bus using messaging
interface, and communicating with master component residing on ADSP
for bandwidth and data-channel management.
Tested this patchset on DB820c with WCD9335 codec.
I have pushed my working branch to [1] incase someone want to try.
This patch has dependency on https://lkml.org/lkml/2018/5/17/251
Changes sinc v1 (https://lwn.net/Articles/754679):
- Fixed DT binding making NGD slave of the slim controller.
- Fixed few typos spotted by Vinod.
- Removed unnessary dmaengine_slave_config suggested by Vinod
- Removed few unnessary initializations.
- fixed commit log to remove reference to B family suggested by Trilok
Thanks,
srini
[1] https://git.linaro.org/people/srinivas.kandagatla/linux.git/log/?h=slimbus-ngd
Srinivas Kandagatla (2):
slimbus: ngd: dt-bindings: Add slim ngd dt bindings
slimbus: ngd: Add qcom SLIMBus NGD driver
.../bindings/slimbus/slim-ngd-qcom-ctrl.txt | 84 ++
drivers/slimbus/Kconfig | 11 +
drivers/slimbus/Makefile | 3 +
drivers/slimbus/qcom-ngd-ctrl.c | 1342 ++++++++++++++++++++
drivers/slimbus/slimbus.h | 8 +
5 files changed, 1448 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
create mode 100644 drivers/slimbus/qcom-ngd-ctrl.c
--
2.16.2
^ permalink raw reply
* Re: [PATCH v13 1/2] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-25 10:48 UTC (permalink / raw)
To: Viresh Kumar, Ilia Lin
Cc: Sudeep Holla, vireshk, nm, sboyd, robh, mark.rutland, rjw,
linux-pm, devicetree, linux-kernel
In-Reply-To: <20180525040536.njrdqjn376oehw2b@vireshk-i7>
On 25/05/18 05:05, Viresh Kumar wrote:
> On 25-05-18, 07:00, Ilia Lin wrote:
>>
>>
>> On May 25, 2018 6:54:12 AM GMT+03:00, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>> On 24-05-18, 18:03, Ilia Lin wrote:
>>>> +static int __init qcom_cpufreq_kryo_init(void)
>>>> +{
>>>> + struct device_node *np;
>>>> + struct device *cpu_dev;
>>>> + int ret;
>>>> +
>>>> + cpu_dev = get_cpu_device(0);
>>>> + if (NULL == cpu_dev)
>>>> + ret = -ENODEV;
>>>> +
>>>> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
>>>> + if (IS_ERR(np))
>>>> + return PTR_ERR(np);
>>>> +
>>>> + ret = of_device_is_compatible(np, "operating-points-v2-kryo-cpu");
>>>> + of_node_put(np);
>>>> + if (!ret)
>>>> + return -ENOENT;
>>>> +
>>>
>>> I hate the fact that it is taking so long to get done with this. But
>>> can't you
>>> just check machine compatibility instead of this complicated setup to
>>> check OPP
>>> node ? Like:
>>>
>>> if (!of_device_is_compatible("qcom,apq8096") &&
>>> !of_device_is_compatible("qcom,msm8996"))
>>> return;
>>
>> I have to check the "operating-points-v2-kryo-cpu" anyway, so I moved it from probe to the init.
>
> Okay, leave it as is then. Don't send anything yet and wait for Sudeep to
> respond.
>
I have already mentioned that I can't suggest since I don't have much
knowledge on QCOM PM. I see lots of patches flying around these days
with multiple people doing same things in different ways. That's why I
suggested Ilia to check with Taniya or Saravana or SBoyd to see what's
the best thing to do in this context. I don't prefer using OPP
compatible and would go with machine compatibility as you suggested.
But I am fine with OPP, just wanted to make sure it won't clash with
anything else.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:32 UTC (permalink / raw)
To: arm, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (like clocks, supply, clock latency) as
well to make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/imx6dl.dtsi | 23 ++++++++++
arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 87 ++++++++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx7d.dtsi | 5 +++
4 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index b384913c34dd..cc8ffc42d128 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -50,6 +50,29 @@
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 792000 1175000
+ 396000 1150000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1175000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
};
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 65ef4cacbc71..18ae4f3be6e3 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -187,6 +187,72 @@
>;
};
+&cpu1 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
+&cpu2 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
+&cpu3 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
&ecspi1 {
cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 70483ce72ba6..78b89bb1bfed 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -50,25 +50,106 @@
soc-supply = <®_soc>;
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
- cpu@2 {
+ cpu2: cpu@2 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <2>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
- cpu@3 {
+ cpu3: cpu@3 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <3>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
};
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 4c9877ec29f2..5434a8aa5602 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -21,6 +21,11 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ operating-points = <
+ /* KHz uV */
+ 996000 1075000
+ 792000 975000
+ >;
clock-frequency = <996000000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 14/15] arm: dts: qcom: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:32 UTC (permalink / raw)
To: arm, Andy Gross, David Brown, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-msm, linux-soc, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing property (clock latency) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index b25daf368012..8c202b359270 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -75,6 +75,14 @@
reg = <0x1>;
clocks = <&gcc GCC_APPS_CLK_SRC>;
clock-frequency = <0>;
+ operating-points = <
+ /* kHz uV (fixed) */
+ 48000 1100000
+ 200000 1100000
+ 500000 1100000
+ 666000 1100000
+ >;
+ clock-latency = <256000>;
};
cpu@2 {
@@ -86,6 +94,14 @@
reg = <0x2>;
clocks = <&gcc GCC_APPS_CLK_SRC>;
clock-frequency = <0>;
+ operating-points = <
+ /* kHz uV (fixed) */
+ 48000 1100000
+ 200000 1100000
+ 500000 1100000
+ 666000 1100000
+ >;
+ clock-latency = <256000>;
};
cpu@3 {
@@ -97,6 +113,14 @@
reg = <0x3>;
clocks = <&gcc GCC_APPS_CLK_SRC>;
clock-frequency = <0>;
+ operating-points = <
+ /* kHz uV (fixed) */
+ 48000 1100000
+ 200000 1100000
+ 500000 1100000
+ 666000 1100000
+ >;
+ clock-latency = <256000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Simon Horman, Magnus Damm, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing property (clock latency) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/r8a7743.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 142949d7066f..e4fb31c4f0ee 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -98,8 +98,17 @@
reg = <1>;
clock-frequency = <1500000000>;
clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ clock-latency = <300000>; /* 300 us */
power-domains = <&sysc R8A7743_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
};
L2_CA15: cache-controller-0 {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing property (clock latency) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index ed14aeac0566..50278715de76 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -56,6 +56,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
cpu@902 {
@@ -65,6 +75,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
cpu@903 {
@@ -74,6 +94,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 11/15] arm: dts: berlin: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Jisheng Zhang, Sebastian Hesselbarth, Rob Herring,
Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (clocks, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/berlin2.dtsi | 10 ++++++++++
arch/arm/boot/dts/berlin2q.dtsi | 33 +++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index d575823c5750..487e9de53244 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -81,6 +81,16 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index bf3a6c9a1d34..9cd00ab53f2d 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -76,6 +76,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu@2 {
@@ -83,6 +94,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <2>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu@3 {
@@ -90,6 +112,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <3>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 10/15] arm: dts: rk3288: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Heiko Stuebner, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-kernel, linux-rockchip, devicetree,
linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/rk3288.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d7e49d29ace5..752a892847dd 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -122,18 +122,72 @@
compatible = "arm,cortex-a12";
reg = <0x501>;
resets = <&cru SRST_CORE1>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
cpu2: cpu@502 {
device_type = "cpu";
compatible = "arm,cortex-a12";
reg = <0x502>;
resets = <&cru SRST_CORE2>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
cpu3: cpu@503 {
device_type = "cpu";
compatible = "arm,cortex-a12";
reg = <0x503>;
resets = <&cru SRST_CORE3>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 09/15] arm: dts: omap: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Benoît Cousson, Tony Lindgren, Rob Herring,
Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-omap, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, supply, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/omap5.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 732b61a0e990..574ac11c0489 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -61,6 +61,20 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+
+ operating-points = <
+ /* kHz uV */
+ 1000000 1060000
+ 1500000 1250000
+ >;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+
+ /* cooling options */
+ #cooling-cells = <2>; /* min followed by max */
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 08/15] arm: dts: dra74x: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Benoît Cousson, Tony Lindgren, Rob Herring,
Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-omap, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, supply, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/dra74x.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 91e93ab588ca..8f9df09155d8 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -18,6 +18,16 @@
compatible = "arm,cortex-a15";
reg = <1>;
operating-points-v2 = <&cpu0_opp_table>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+
+ /* cooling options */
+ #cooling-cells = <2>; /* min followed by max */
+
+ vbb-supply = <&abb_mpu>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland, Kukjin Kim, Krzysztof Kozlowski
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/exynos4210.dtsi | 13 +++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++++++++++++++++++
4 files changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 962af97c1883..aff5d66ae058 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -78,6 +78,22 @@
compatible = "arm,cortex-a7";
reg = <1>;
clock-frequency = <1000000000>;
+ clocks = <&cmu CLK_ARM_CLK>;
+ clock-names = "cpu";
+ #cooling-cells = <2>;
+
+ operating-points = <
+ 1000000 1150000
+ 900000 1112500
+ 800000 1075000
+ 700000 1037500
+ 600000 1000000
+ 500000 962500
+ 400000 925000
+ 300000 887500
+ 200000 850000
+ 100000 850000
+ >;
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 88fb47cef9a8..b6091c27f155 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -55,6 +55,19 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0x901>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+ clock-latency = <160000>;
+
+ operating-points = <
+ 1200000 1250000
+ 1000000 1150000
+ 800000 1075000
+ 500000 975000
+ 400000 975000
+ 200000 950000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 7b43c10c510b..51f72f0327e5 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -49,21 +49,30 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA01>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@a02 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA02>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@a03 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA03>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505b3d08..69648f83b8b4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -84,6 +84,29 @@
compatible = "arm,cortex-a15";
reg = <1>;
clock-frequency = <1700000000>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+ clock-latency = <140000>;
+
+ operating-points = <
+ 1700000 1300000
+ 1600000 1250000
+ 1500000 1225000
+ 1400000 1200000
+ 1300000 1150000
+ 1200000 1125000
+ 1100000 1100000
+ 1000000 1075000
+ 900000 1050000
+ 800000 1025000
+ 700000 1012500
+ 600000 1000000
+ 500000 975000
+ 400000 950000
+ 300000 937500
+ 200000 925000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 30 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
arch/arm/boot/dts/sun8i-a33.dtsi | 9 +++++++++
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++++++++
4 files changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c72992556a86..debc0bf22ea3 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -119,18 +119,48 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..35372a0cfc8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -122,6 +122,19 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 960000 1400000
+ 912000 1400000
+ 864000 1300000
+ 720000 1200000
+ 528000 1100000
+ 312000 1000000
+ 144000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..4e92741b24a7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -132,21 +132,30 @@
};
cpu@1 {
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland, Masahiro Yamada
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index debcbd15c24b..40ed15465095 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -36,6 +36,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -46,6 +47,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -56,6 +58,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 04/15] arm: dts: rk322x: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Heiko Stuebner, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-arm-kernel, linux-rockchip, devicetree,
linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/rk322x.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index be80e9a2c9af..ef414e39bf3a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -80,6 +80,7 @@
reg = <0xf01>;
resets = <&cru SRST_CORE1>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
@@ -89,6 +90,7 @@
reg = <0xf02>;
resets = <&cru SRST_CORE2>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
@@ -98,6 +100,7 @@
reg = <0xf03>;
resets = <&cru SRST_CORE3>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 03/15] arm: dts: mediatek: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A, Matthias Brugger, Rob Herring,
Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot, Viresh Kumar,
Daniel Lezcano, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chris.redpath-5wv7dgnIgG8, ionela.voinescu-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cover.1527244200.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/mt7623.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index d1eb123bc73b..1cdc346a05e8 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -92,6 +92,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
@@ -103,6 +104,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
@@ -114,6 +116,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 02/15] arm: dts: ls1021a: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, devicetree, linux-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c55d479971cc..f18490548c78 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -84,6 +84,7 @@
device_type = "cpu";
reg = <0xf01>;
clocks = <&clockgen 1 0>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 01/15] arm: dts: armada: Fix "#cooling-cells" property's name
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland
Cc: devicetree, Vincent Guittot, Viresh Kumar, Daniel Lezcano,
linux-kernel, chris.redpath, ionela.voinescu, linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
It should be "#cooling-cells" instead of "cooling-cells". Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-synology-ds116.dts b/arch/arm/boot/dts/armada-385-synology-ds116.dts
index 6782ce481ac9..d8769956cbfc 100644
--- a/arch/arm/boot/dts/armada-385-synology-ds116.dts
+++ b/arch/arm/boot/dts/armada-385-synology-ds116.dts
@@ -139,7 +139,7 @@
3700 5
3900 6
4000 7>;
- cooling-cells = <2>;
+ #cooling-cells = <2>;
};
gpio-leds {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 00/15] arm: dts: Fix OPP and cooling device properties
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: arm, Andrew Lunn, Andy Gross, Benoît Cousson, Chen-Yu Tsai,
David Brown, Fabio Estevam, Gregory Clement, Heiko Stuebner,
Jason Cooper, Jisheng Zhang, Krzysztof Kozlowski, Kukjin Kim,
Magnus Damm, Mark Rutland, Masahiro Yamada, Matthias Brugger,
Maxime Ripard, Pengutronix Kernel Team
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, devicetree, linux-arm-kernel, linux-arm-msm,
linux-kernel, linux-mediatek, linux-omap, linux-renesas-soc,
linux-rockchip, linux-samsung-soc, linux-soc
This fixes missing OPP and cooling device properties for CPUs for the
ARM 32 bit platforms. This is build tested by the zero day testing
infrastructure as well.
Individual maintainers can pick the patches to their SoC trees or I will
ask ARM SoC maintainers to pick them up later.
--
viresh
Viresh Kumar (15):
arm: dts: armada: Fix "#cooling-cells" property's name
arm: dts: ls1021a: Add missing cooling device properties for CPUs
arm: dts: mediatek: Add missing cooling device properties for CPUs
arm: dts: rk322x: Add missing cooling device properties for CPUs
arm: dts: uniphier: Add missing cooling device properties for CPUs
arm: dts: sun: Add missing cooling device properties for CPUs
arm: dts: exynos: Add missing cooling device properties for CPUs
arm: dts: dra74x: Add missing cooling device properties for CPUs
arm: dts: omap: Add missing cooling device properties for CPUs
arm: dts: rk3288: Add missing cooling device properties for CPUs
arm: dts: berlin: Add missing OPP properties for CPUs
arm: dts: highbank: Add missing OPP properties for CPUs
arm: dts: r8a7743: Add missing OPP properties for CPUs
arm: dts: qcom: Add missing OPP properties for CPUs
arm: dts: imx: Add missing OPP properties for CPUs
arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
arch/arm/boot/dts/berlin2.dtsi | 10 +++
arch/arm/boot/dts/berlin2q.dtsi | 33 ++++++++++
arch/arm/boot/dts/dra74x.dtsi | 10 +++
arch/arm/boot/dts/exynos3250.dtsi | 16 +++++
arch/arm/boot/dts/exynos4210.dtsi | 13 ++++
arch/arm/boot/dts/exynos4412.dtsi | 9 +++
arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++
arch/arm/boot/dts/highbank.dts | 30 +++++++++
arch/arm/boot/dts/imx6dl.dtsi | 23 +++++++
arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 87 ++++++++++++++++++++++++-
arch/arm/boot/dts/imx7d.dtsi | 5 ++
arch/arm/boot/dts/ls1021a.dtsi | 1 +
arch/arm/boot/dts/mt7623.dtsi | 3 +
arch/arm/boot/dts/omap5.dtsi | 14 ++++
arch/arm/boot/dts/qcom-ipq4019.dtsi | 24 +++++++
arch/arm/boot/dts/r8a7743.dtsi | 9 +++
arch/arm/boot/dts/rk322x.dtsi | 3 +
arch/arm/boot/dts/rk3288.dtsi | 54 +++++++++++++++
arch/arm/boot/dts/sun6i-a31.dtsi | 30 +++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 ++++
arch/arm/boot/dts/sun8i-a33.dtsi | 9 +++
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +
25 files changed, 495 insertions(+), 4 deletions(-)
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file
From: Geert Uytterhoeven @ 2018-05-25 10:31 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Geert Uytterhoeven, linux-clk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List
In-Reply-To: <1527154169-32380-2-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This adds the constants necessary to use the renesas,r9a06g032-sysctrl node.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> --- /dev/null
> +++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h
You can still call this file r9a06g032-clocks.h, if you want, as it
contains clock definitions only.
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * R9A06G032 sysctrl IDs
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from zx-reboot.c
> + */
> +
> +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> +
> +#define R9A06G032_CLKOUT 0
> +#define R9A06G032_CLK_PLL_USB 1
> +#define R9A06G032_CLK_48 1 /* AKA CLK_PLL_USB */
> +#define R9A06G032_CLKOUT_D10 2
> +#define R9A06G032_CLKOUT_D16 3
> +#define R9A06G032_MSEBIS_CLK 3 /* AKA CLKOUT_D16 */
> +#define R9A06G032_MSEBIM_CLK 3 /* AKA CLKOUT_D16 */
> +#define R9A06G032_CLKOUT_D160 4
> +#define R9A06G032_CLKOUT_D1OR2 5
> +#define R9A06G032_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 */
[...]
I have 3 comments:
1. I had expected this list to match (both name- and order-wise) Appendix
C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
Introduction, Multiplexing, Electrical and Mechanical Information.
That would make it easier to review.
2. These definitions seems to be a mix of:
1. Internal core clocks,
2. Other core clocks,
3. Module clocks.
The internal clocks do not need to be referenced from DT, so I would
not make them part of the DT bindings.
3. It looks like the module clocks can be referred to by register offset
and bit position, which is similar to how this is handled on R-Car
SoCs.
Perhaps you can just drop the definitions for these from the header
file, and refer to them by (combined) register offset and bit position
instead?
Or am I missing something?
I believe this can also be done for the module resets (later).
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing
From: Mark Brown @ 2018-05-25 10:26 UTC (permalink / raw)
To: Marco Felsch
Cc: Mark Rutland, Rob Herring, Linux-ALSA, Lars-Peter Clausen, kernel,
devicetree, Sascha Hauer, Liam Girdwood, Philipp Zabel
In-Reply-To: <20180525094724.3f4edofopk52i3v6@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 408 bytes --]
On Fri, May 25, 2018 at 11:47:24AM +0200, Marco Felsch wrote:
> I found the: "ti,charge-period (sound/ti,tas5086.txt)" binding which
> represents nearly the same but it is not common. One opportunity would be to
> introduce a common "charge-period-us" binding and change the ti binding the
> common binding later.
Are you sure what you have is a charge period and not some stabalization
time or something?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators
From: Mark Brown @ 2018-05-25 10:24 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Vaittinen, Matti, mturquette@baylibre.com, sboyd@kernel.org,
robh+dt@kernel.org, mark.rutland@arm.com, lee.jones@linaro.org,
lgirdwood@gmail.com, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Mutanen, Mikko, Haikola, Heikki
In-Reply-To: <20180525055430.GB16888@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On Fri, May 25, 2018 at 08:54:30AM +0300, Matti Vaittinen wrote:
> On Thu, May 24, 2018 at 06:57:21PM +0100, Mark Brown wrote:
> > You can look at the regulators node within the parent device, you know
> > that in Linux the parent device will be the MFD.
> So I should parse the device-tree in MFD my driver in order to locate
> the regulators node? Isn't that somewhat like code dublication? If we
> rely on compatibles we can avoid device-tree parsing in MFD driver,
No, there's no need to do this - the child can just look at the of_node
of the parent since it can never be instantiated otherwise.
> right? An in-tree example of this is:
There are some bad examples (and some where the same regulators can get
used with multiple different parents) but that's no reason not to follow
good practice.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 8/9] regulator: bd71837: BD71837 PMIC regulator driver
From: Mark Brown @ 2018-05-25 10:14 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Vaittinen, Matti, mturquette@baylibre.com, sboyd@kernel.org,
robh+dt@kernel.org, mark.rutland@arm.com, lee.jones@linaro.org,
lgirdwood@gmail.com, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Mutanen, Mikko, Haikola, Heikki
In-Reply-To: <20180525072253.GC16888@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
On Fri, May 25, 2018 at 10:22:53AM +0300, Matti Vaittinen wrote:
> On Thu, May 24, 2018 at 05:51:27PM +0000, Vaittinen, Matti wrote:
> > > devm_regulator_regster()
> > Makes sense. Thanks
> I was going to do
> - pmic = kzalloc(sizeof(struct bd71837_pmic), GFP_KERNEL);
> + pmic = devm_kzalloc(&pdev->dev, sizeof(struct bd71837_pmic),
> + GFP_KERNEL);
> and
> - rdev = regulator_register(desc, &config);
> + rdev = devm_regulator_register(&pdev->dev, desc, &config);
>
> but is there now a race regarding freeing the pmic structure and
> unregistering the regulator?
Why? devm_ stuff gets unwound in the opposite order to the order in
which it was allocated.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* [PATCH v2 6/6] soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init
From: Rajendra Nayak @ 2018-05-25 10:01 UTC (permalink / raw)
To: viresh.kumar, sboyd, andy.gross, ulf.hansson
Cc: devicetree, linux-arm-msm, linux-kernel, collinsd, Rajendra Nayak
In-Reply-To: <20180525100121.28214-1-rnayak@codeaurora.org>
As we move from no clients/consumers in kernel voting on corners,
to *some* voting and some not voting, we might end up in a situation
where the clients which remove votes can adversly impact others
who still don't have a way to vote.
To avoid this situation, have a max vote on all corners at init.
This should/can be removed once we have all clients moved to
be able to vote/unvote for themselves.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/soc/qcom/rpmhpd.c | 9 +++++++++
drivers/soc/qcom/rpmpd.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index a79f094ad326..933f7b2d9249 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -323,6 +323,15 @@ static int rpmhpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmhpds[i]->pd, NULL, true);
data->domains[i] = &rpmhpds[i]->pd;
+
+ /*
+ * Until we have all consumers voting on corners
+ * just vote the max corner on all PDs
+ * This should ideally be *removed* once we have
+ * all (most) consumers being able to vote
+ */
+ rpmhpd_power_on(&rpmhpds[i]->pd);
+ rpmhpd_set_performance(&rpmhpds[i]->pd, rpmhpds[i]->level_count - 1);
}
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index ff3d910f388c..ff5da19beef3 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -308,6 +308,15 @@ static int rpmpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
data->domains[i] = &rpmpds[i]->pd;
+
+ /*
+ * Until we have all consumers voting on corners
+ * just vote the max corner on all PDs
+ * This should ideally be *removed* once we have
+ * all (most) consumers being able to vote
+ */
+ rpmpd_set_performance(&rpmpds[i]->pd, MAX_RPMPD_STATE);
+ rpmpd_power_on(&rpmpds[i]->pd);
}
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 5/6] soc: qcom: rpmh powerdomain driver
From: Rajendra Nayak @ 2018-05-25 10:01 UTC (permalink / raw)
To: viresh.kumar, sboyd, andy.gross, ulf.hansson
Cc: devicetree, linux-arm-msm, linux-kernel, collinsd, Rajendra Nayak
In-Reply-To: <20180525100121.28214-1-rnayak@codeaurora.org>
The RPMh powerdomain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.
We also add data for all powerdomains on sdm845 as part of the patch.
The driver can be extended to support other SoCs which support RPMh
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
.../devicetree/bindings/power/qcom,rpmhpd.txt | 65 ++++
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmhpd.c | 360 ++++++++++++++++++
4 files changed, 435 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
create mode 100644 drivers/soc/qcom/rpmhpd.c
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
new file mode 100644
index 000000000000..c1fa986c12ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
@@ -0,0 +1,65 @@
+Qualcomm RPMh Powerdomains
+
+* For RPMh powerdomains, we communicate a performance state to RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+ * qcom,sdm845-rpmhpd: RPMh powerdomain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in power domain specifier
+ must be 1
+ - operating-points-v2: Phandle to the OPP table for the power-domain.
+ Refer to Documentation/devicetree/bindings/power/power_domain.txt
+ and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Example:
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sdm845-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>,
+ <&rpmhpd_opp_table>;
+ };
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level", "operating-points-v2";
+
+ rpmhpd_opp1: opp@1 {
+ qcom-corner = <16>;
+ };
+
+ rpmhpd_opp2: opp@2 {
+ qcom-corner = <48>;
+ };
+
+ rpmhpd_opp3: opp@3 {
+ qcom-corner = <64>;
+ };
+
+ rpmhpd_opp4: opp@4 {
+ qcom-corner = <128>;
+ };
+
+ rpmhpd_opp5: opp@5 {
+ qcom-corner = <192>;
+ };
+
+ rpmhpd_opp6: opp@6 {
+ qcom-corner = <256>;
+ };
+
+ rpmhpd_opp7: opp@7 {
+ qcom-corner = <320>;
+ };
+
+ rpmhpd_opp8: opp@8 {
+ qcom-corner = <416>;
+ };
+ };
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a7a405178967..1faed239701d 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMHPD
+ tristate "Qualcomm RPMh Powerdomain driver"
+ depends on QCOM_RPMH && QCOM_COMMAND_DB
+ help
+ QCOM RPMh powerdomain driver to support powerdomain with
+ performance states. The driver communicates a performance state
+ value to RPMh which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_RPMPD
tristate "Qualcomm RPM Powerdomain driver"
depends on MFD_QCOM_RPM && QCOM_SMD_RPM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9550c170de93..499513f63bef 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM) += smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index 000000000000..a79f094ad326
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pm_domain.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <soc/qcom/cmd-db.h>
+#include <soc/qcom/rpmh.h>
+
+#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
+
+#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
+ static struct rpmhpd _platform##_##_active; \
+ static struct rpmhpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_name = #_name".lvl", \
+ }; \
+ static struct rpmhpd _platform##_##_active = { \
+ .pd = { .name = #_active, }, \
+ .peer = &_platform##_##_name, \
+ .active_only = true, \
+ .res_name = #_name".lvl", \
+ }
+
+#define DEFINE_RPMHPD(_platform, _name) \
+ static struct rpmhpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_name = #_name".lvl", \
+ }
+
+/*
+ * This is the number of bytes used for each command DB aux data entry of an
+ * ARC resource.
+ */
+#define RPMH_ARC_LEVEL_SIZE 2
+#define RPMH_ARC_MAX_LEVELS 16
+
+struct rpmhpd {
+ struct device *dev;
+ struct generic_pm_domain pd;
+ struct rpmhpd *peer;
+ const bool active_only;
+ unsigned long corner;
+ u32 level[RPMH_ARC_MAX_LEVELS];
+ int level_count;
+ bool enabled;
+ const char *res_name;
+ u32 addr;
+};
+
+struct rpmhpd_desc {
+ struct rpmhpd **rpmhpds;
+ size_t num_pds;
+};
+
+static DEFINE_MUTEX(rpmhpd_lock);
+
+/* sdm845 RPMh powerdomains */
+DEFINE_RPMHPD(sdm845, ebi);
+DEFINE_RPMHPD_AO(sdm845, mx, mx_ao);
+DEFINE_RPMHPD_AO(sdm845, cx, cx_ao);
+DEFINE_RPMHPD(sdm845, lmx);
+DEFINE_RPMHPD(sdm845, lcx);
+DEFINE_RPMHPD(sdm845, gfx);
+DEFINE_RPMHPD(sdm845, mss);
+
+static struct rpmhpd *sdm845_rpmhpds[] = {
+ [0] = &sdm845_ebi,
+ [1] = &sdm845_mx,
+ [2] = &sdm845_mx_ao,
+ [3] = &sdm845_cx,
+ [4] = &sdm845_cx_ao,
+ [5] = &sdm845_lmx,
+ [6] = &sdm845_lcx,
+ [7] = &sdm845_gfx,
+ [8] = &sdm845_mss,
+};
+
+static const struct rpmhpd_desc sdm845_desc = {
+ .rpmhpds = sdm845_rpmhpds,
+ .num_pds = ARRAY_SIZE(sdm845_rpmhpds),
+};
+
+static const struct of_device_id rpmhpd_match_table[] = {
+ { .compatible = "qcom,sdm845-rpmhpd", .data = &sdm845_desc },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rpmhpd_match_table);
+
+static int rpmhpd_send_corner(struct rpmhpd *pd, int state, unsigned int corner)
+{
+ struct tcs_cmd cmd = {
+ .addr = pd->addr,
+ .data = corner,
+ };
+
+ return rpmh_write(pd->dev, state, &cmd, 1);
+};
+
+static void to_active_sleep(struct rpmhpd *pd, unsigned long corner,
+ unsigned long *active, unsigned long *sleep)
+{
+ *active = corner;
+
+ if (pd->active_only)
+ *sleep = 0;
+ else
+ *sleep = *active;
+}
+
+static int rpmhpd_aggregate_corner(struct rpmhpd *pd)
+{
+ int ret;
+ struct rpmhpd *peer = pd->peer;
+ unsigned long active_corner, sleep_corner;
+ unsigned long this_corner = 0, this_sleep_corner = 0;
+ unsigned long peer_corner = 0, peer_sleep_corner = 0;
+
+ to_active_sleep(pd, pd->corner, &this_corner, &this_sleep_corner);
+
+ if (peer && peer->enabled)
+ to_active_sleep(peer, peer->corner, &peer_corner,
+ &peer_sleep_corner);
+
+ active_corner = max(this_corner, peer_corner);
+
+ ret = rpmhpd_send_corner(pd, RPMH_ACTIVE_ONLY_STATE, active_corner);
+ if (ret)
+ return ret;
+
+ sleep_corner = max(this_sleep_corner, peer_sleep_corner);
+
+ return rpmhpd_send_corner(pd, RPMH_SLEEP_STATE, sleep_corner);
+}
+
+static int rpmhpd_power_on(struct generic_pm_domain *domain)
+{
+ int ret = 0;
+ struct rpmhpd *pd = domain_to_rpmhpd(domain);
+
+ mutex_lock(&rpmhpd_lock);
+
+ pd->enabled = true;
+
+ if (pd->corner)
+ ret = rpmhpd_aggregate_corner(pd);
+
+ mutex_unlock(&rpmhpd_lock);
+
+ return ret;
+}
+
+static int rpmhpd_power_off(struct generic_pm_domain *domain)
+{
+ int ret;
+ struct rpmhpd *pd = domain_to_rpmhpd(domain);
+
+ mutex_lock(&rpmhpd_lock);
+
+ if (pd->level[0] == 0) {
+ ret = rpmhpd_send_corner(pd, RPMH_ACTIVE_ONLY_STATE, 0);
+ if (ret)
+ return ret;
+
+ ret = rpmhpd_send_corner(pd, RPMH_SLEEP_STATE, 0);
+ if (ret)
+ return ret;
+ }
+
+ pd->enabled = false;
+
+ mutex_unlock(&rpmhpd_lock);
+
+ return 0;
+}
+
+static int rpmhpd_set_performance(struct generic_pm_domain *domain,
+ unsigned int state)
+{
+ int ret = 0;
+ struct rpmhpd *pd = domain_to_rpmhpd(domain);
+
+ mutex_lock(&rpmhpd_lock);
+
+ pd->corner = state;
+
+ if (!pd->enabled)
+ goto out;
+
+ ret = rpmhpd_aggregate_corner(pd);
+out:
+ mutex_unlock(&rpmhpd_lock);
+
+ return ret;
+}
+
+static unsigned int rpmhpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+ struct device_node *np;
+ unsigned int corner = 0;
+
+ np = dev_pm_opp_get_of_node(opp);
+ if (of_property_read_u32(np, "qcom,level", &corner)) {
+ pr_err("%s: missing 'qcom,level' property\n", __func__);
+ return 0;
+ }
+
+ of_node_put(np);
+
+ return corner;
+}
+
+static int rpmhpd_update_level_mapping(struct rpmhpd *rpmhpd)
+{
+ u8 *buf;
+ int i, j, len, ret;
+
+ len = cmd_db_read_aux_data_len(rpmhpd->res_name);
+ if (len <= 0)
+ return len;
+
+ buf = kzalloc(len, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ ret = cmd_db_read_aux_data(rpmhpd->res_name, buf, len);
+ if (ret < 0)
+ return ret;
+
+ rpmhpd->level_count = len / RPMH_ARC_LEVEL_SIZE;
+
+ for (i = 0; i < rpmhpd->level_count; i++) {
+ for (j = 0; j < RPMH_ARC_LEVEL_SIZE; j++)
+ rpmhpd->level[i] |=
+ buf[i * RPMH_ARC_LEVEL_SIZE + j] << (8 * j);
+
+ /*
+ * The AUX data may be zero padded. These 0 valued entries at
+ * the end of the map must be ignored.
+ */
+ if (i > 0 && rpmhpd->level[i] == 0) {
+ rpmhpd->level_count = i;
+ break;
+ }
+ pr_dbg("%s: ARC hlvl=%2d --> vlvl=%4u\n", rpmhpd->res_name, i,
+ rpmhpd->level[i]);
+ }
+
+ kfree(buf);
+ return 0;
+}
+
+static int rpmhpd_probe(struct platform_device *pdev)
+{
+ int i, ret;
+ size_t num;
+ struct genpd_onecell_data *data;
+ struct rpmhpd **rpmhpds;
+ const struct rpmhpd_desc *desc;
+
+ desc = of_device_get_match_data(&pdev->dev);
+ if (!desc)
+ return -EINVAL;
+
+ rpmhpds = desc->rpmhpds;
+ num = desc->num_pds;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->domains = devm_kcalloc(&pdev->dev, num, sizeof(*data->domains),
+ GFP_KERNEL);
+ data->num_domains = num;
+
+ ret = cmd_db_ready();
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Command DB unavailable, ret=%d\n",
+ ret);
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (!rpmhpds[i])
+ continue;
+
+ rpmhpds[i]->dev = &pdev->dev;
+ rpmhpds[i]->addr = cmd_db_read_addr(rpmhpds[i]->res_name);
+ if (!rpmhpds[i]->addr) {
+ dev_err(&pdev->dev, "Could not find RPMh address for resource %s\n",
+ rpmhpds[i]->res_name);
+ return -ENODEV;
+ }
+
+ ret = cmd_db_read_slave_id(rpmhpds[i]->res_name);
+ if (ret != CMD_DB_HW_ARC) {
+ dev_err(&pdev->dev, "RPMh slave ID mismatch\n");
+ return -EINVAL;
+ }
+
+ ret = rpmhpd_update_level_mapping(rpmhpds[i]);
+ if (ret)
+ return ret;
+
+ rpmhpds[i]->pd.power_off = rpmhpd_power_off;
+ rpmhpds[i]->pd.power_on = rpmhpd_power_on;
+ rpmhpds[i]->pd.set_performance_state = rpmhpd_set_performance;
+ rpmhpds[i]->pd.opp_to_performance_state = rpmhpd_get_performance;
+ pm_genpd_init(&rpmhpds[i]->pd, NULL, true);
+
+ data->domains[i] = &rpmhpds[i]->pd;
+ }
+
+ return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
+}
+
+static int rpmhpd_remove(struct platform_device *pdev)
+{
+ of_genpd_del_provider(pdev->dev.of_node);
+ return 0;
+}
+
+static struct platform_driver rpmhpd_driver = {
+ .driver = {
+ .name = "qcom-rpmhpd",
+ .of_match_table = rpmhpd_match_table,
+ },
+ .probe = rpmhpd_probe,
+ .remove = rpmhpd_remove,
+};
+
+static int __init rpmhpd_init(void)
+{
+ return platform_driver_register(&rpmhpd_driver);
+}
+core_initcall(rpmhpd_init);
+
+static void __exit rpmhpd_exit(void)
+{
+ platform_driver_unregister(&rpmhpd_driver);
+}
+module_exit(rpmhpd_exit);
+
+MODULE_DESCRIPTION("Qualcomm RPMh Power Domain Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:qcom-rpmhpd");
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox