* [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling
@ 2023-08-27 11:50 Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 01/23] dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml Dmitry Baryshkov
` (22 more replies)
0 siblings, 23 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Implement CPUFreq support for one of the oldest supported Qualcomm
platforms, APQ8064. Each core has independent power and frequency
control. Additionally the L2 cache is scaled to follow the CPU
frequencies (failure to do so results in strange semi-random crashes).
Core voltage is controlled through the SAW2 devices, one for each core.
The L2 has two regulators, vdd-mem and vdd-dig.
Dependencies: [1], [2].
[1] https://lore.kernel.org/linux-arm-msm/20230827005920.898719-1-dmitry.baryshkov@linaro.org/
[2] https://lore.kernel.org/linux-arm-msm/20230827032803.934819-1-dmitry.baryshkov@linaro.org/
Changes since v3:
- Split the opp and cpufreq patches to a separate series (Viresh)
- Added the cache's select clause (Rob, Krzysztof)
- Fixed $ref to include full path (Krzysztof)
- Renamed opp-table-l2 to just opp-table (Krzysztof)
- Unrolled loops in krait_l2_config_regulators() (Konrad)
- Dropped useless comments from krait-cc DT (Konrad)
- Fixed Votlage comment formatting (Konrad)
- Added empty lines between nvmem cells (Konrad)
- Replaced direct register masks with GENMASK (Konrad)
- Reordered headers in spm.c (Konrad)
Changes since v2:
- Merged basic cpufreq and voltage patches, to make sure that we don't
undervolt the cores (Konrad)
- Reordered patches pushing voltage constraints early (Konrad)
- Removed KRAIT_NUM_CLOCKS from the kraitcc bindings header (Konrad)
- Rebased on top of PMIC cleanup
- Added missing regulator constraints to apq8064-cm-qs600 and
apq8064-sony-xperia-lagan-yuga.
Changes since v1:
- Added separate Krait L2 cache device driver
- Moved vdd-mem and vdd-dig scaling to the L2 cache device (Christian,
Stephen Gerhold)
- Fixed the 'INTERCONNECT' in the guarding define for krait-cc bindings
(Stephen Boyd)
- Made SAW2's regulator property -> node handling clear (Krzysztof)
- Dropped the 'regulator' property from all SAW2 devices.
Dmitry Baryshkov (23):
dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml
dt-bindings: soc: qcom: qcom,saw2: define optional regulator node
dt-bindings: clock: qcom,krait-cc: Krait core clock controller
dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms
interconnect: icc-clk: add support for scaling using OPP
clk: qcom: krait-cc: rewrite driver to use clk_hw instead of clk
soc: qcom: spm: add support for voltage regulator
soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
ARM: dts: qcom: apq8064-asus-nexus7-flo: constraint cpufreq regulators
ARM: dts: qcom: apq8064-cm-qs600: constraint cpufreq regulators
ARM: dts: qcom: apq8064-ifc6410: constraint cpufreq regulators
ARM: dts: qcom: apq8064-sony-xperia-lagan-yuga: constraint cpufreq
regulators
ARM: dts: qcom: apq8064: rename SAW nodes to power-manager
ARM: dts: qcom: apq8064: declare SAW2 regulators
ARM: dts: qcom: apq8064: add Krait clock controller
ARM: dts: qcom: apq8064: add L2 cache scaling
ARM: dts: qcom: apq8064: add simple CPUFreq support
ARM: dts: qcom: apq8064: enable passive CPU cooling
ARM: dts: qcom: msm8960: declare SAW2 regulators
ARM: dts: qcom: apq8084: drop 'regulator' property from SAW2 device
ARM: dts: qcom: msm8974: drop 'regulator' property from SAW2 device
ARM: dts: qcom: ipq4019: drop 'regulator' property from SAW2 devices
ARM: dts: qcom: ipq8064: drop 'regulator' property from SAW2 devices
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 58 --
.../bindings/cache/qcom,krait-l2-cache.yaml | 86 +++
.../qcom/{qcom,spm.yaml => qcom,saw2.yaml} | 39 +-
.../dts/qcom/qcom-apq8064-asus-nexus7-flo.dts | 19 +-
.../boot/dts/qcom/qcom-apq8064-cm-qs600.dts | 23 +-
.../boot/dts/qcom/qcom-apq8064-ifc6410.dts | 23 +-
.../qcom-apq8064-sony-xperia-lagan-yuga.dts | 13 +-
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 670 +++++++++++++++++-
arch/arm/boot/dts/qcom/qcom-apq8084.dtsi | 1 -
arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi | 5 -
arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi | 2 -
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 12 +-
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 1 -
drivers/clk/qcom/krait-cc.c | 141 ++--
drivers/interconnect/icc-clk.c | 13 +-
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/krait-l2-cache.c | 160 +++++
drivers/soc/qcom/spm.c | 221 +++++-
include/dt-bindings/clock/qcom,krait-cc.h | 15 +
include/dt-bindings/soc/qcom,krait-l2-cache.h | 12 +
include/linux/interconnect-clk.h | 1 +
include/soc/qcom/spm.h | 9 +
23 files changed, 1357 insertions(+), 177 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
create mode 100644 Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
rename Documentation/devicetree/bindings/soc/qcom/{qcom,spm.yaml => qcom,saw2.yaml} (57%)
create mode 100644 drivers/soc/qcom/krait-l2-cache.c
create mode 100644 include/dt-bindings/clock/qcom,krait-cc.h
create mode 100644 include/dt-bindings/soc/qcom,krait-l2-cache.h
--
2.39.2
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 01/23] dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 02/23] dt-bindings: soc: qcom: qcom,saw2: define optional regulator node Dmitry Baryshkov
` (21 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold, Rob Herring
The Qualcomm SPM / SAW2 device is described in two bindigns files:
arm/msm/qcom,saw2.txt and soc/qcom/qcom,spm.yaml. Merge the former into
the latter, adding detailed device node description. While we are at it,
also rename qcom,spm.yaml to qcom,saw2.yaml to follow the actual
compatible used for these devices.
The regulator property is retained as is. It will be changed in the
later patches.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 58 -------------------
.../qcom/{qcom,spm.yaml => qcom,saw2.yaml} | 26 +++++++--
2 files changed, 20 insertions(+), 64 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
rename Documentation/devicetree/bindings/soc/qcom/{qcom,spm.yaml => qcom,saw2.yaml} (64%)
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
deleted file mode 100644
index c0e3c3a42bea..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-SPM AVS Wrapper 2 (SAW2)
-
-The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
-Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
-power-controller that transitions a piece of hardware (like a processor or
-subsystem) into and out of low power modes via a direct connection to
-the PMIC. It can also be wired up to interact with other processors in the
-system, notifying them when a low power state is entered or exited.
-
-Multiple revisions of the SAW hardware are supported using these Device Nodes.
-SAW2 revisions differ in the register offset and configuration data. Also, the
-same revision of the SAW in different SoCs may have different configuration
-data due the differences in hardware capabilities. Hence the SoC name, the
-version of the SAW hardware in that SoC and the distinction between cpu (big
-or Little) or cache, may be needed to uniquely identify the SAW register
-configuration and initialization data. The compatible string is used to
-indicate this parameter.
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Must have
- "qcom,saw2"
- A more specific value could be one of:
- "qcom,apq8064-saw2-v1.1-cpu"
- "qcom,msm8226-saw2-v2.1-cpu"
- "qcom,msm8974-saw2-v2.1-cpu"
- "qcom,apq8084-saw2-v2.1-cpu"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the first element specifies the base address and size of
- the register region. An optional second element specifies
- the base address and size of the alias register region.
-
-- regulator:
- Usage: optional
- Value type: boolean
- Definition: Indicates that this SPM device acts as a regulator device
- device for the core (CPU or Cache) the SPM is attached
- to.
-
-Example 1:
-
- power-controller@2099000 {
- compatible = "qcom,saw2";
- reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
- regulator;
- };
-
-Example 2:
- saw0: power-controller@f9089000 {
- compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2";
- reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
similarity index 64%
rename from Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml
rename to Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
index 20c8cd38ff0d..84b3f01d590c 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
@@ -1,18 +1,25 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml#
+$id: http://devicetree.org/schemas/soc/qcom/qcom,saw2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Subsystem Power Manager
+title: Qualcomm Subsystem Power Manager / SPM AVS Wrapper 2 (SAW2)
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
- This binding describes the Qualcomm Subsystem Power Manager, used to control
- the peripheral logic surrounding the application cores in Qualcomm platforms.
+ The Qualcomm Subsystem Power Manager is used to control the peripheral logic
+ surrounding the application cores in Qualcomm platforms.
+
+ The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
+ Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
+ power-controller that transitions a piece of hardware (like a processor or
+ subsystem) into and out of low power modes via a direct connection to
+ the PMIC. It can also be wired up to interact with other processors in the
+ system, notifying them when a low power state is entered or exited.
properties:
compatible:
@@ -34,8 +41,15 @@ properties:
- const: qcom,saw2
reg:
- description: Base address and size of the SPM register region
- maxItems: 1
+ items:
+ - description: Base address and size of the SPM register region
+ - description: Base address and size of the alias register region
+ minItems: 1
+
+ regulator:
+ type: boolean
+ description: Indicates that this SPM device acts as a regulator device
+ device for the core (CPU or Cache) the SPM is attached to.
required:
- compatible
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 02/23] dt-bindings: soc: qcom: qcom,saw2: define optional regulator node
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 01/23] dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 03/23] dt-bindings: clock: qcom,krait-cc: Krait core clock controller Dmitry Baryshkov
` (20 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold, Rob Herring
The SAW2 device can optionally provide a voltage regulator supplying the
CPU core, cluster or L2 cache. Change the boolean 'regulator' property
into a proper regulator description. This breaks schema compatibility
for the sake of properly describing the regulator.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../devicetree/bindings/soc/qcom/qcom,saw2.yaml | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
index 84b3f01d590c..a2d871ba8c45 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
@@ -47,7 +47,7 @@ properties:
minItems: 1
regulator:
- type: boolean
+ $ref: /schemas/regulator/regulator.yaml#
description: Indicates that this SPM device acts as a regulator device
device for the core (CPU or Cache) the SPM is attached to.
@@ -96,4 +96,17 @@ examples:
reg = <0x17912000 0x1000>;
};
+ - |
+ /*
+ * Example 3: SAW2 with the bundled regulator definition.
+ */
+ power-manager@2089000 {
+ compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
+ reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
+
+ regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
+ };
...
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 03/23] dt-bindings: clock: qcom,krait-cc: Krait core clock controller
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 01/23] dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 02/23] dt-bindings: soc: qcom: qcom,saw2: define optional regulator node Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms Dmitry Baryshkov
` (19 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold, Rob Herring
Define bindings for the Qualcomm Krait CPU and L2 clock controller. This
device is used on old Qualcomm SoCs (APQ8064, MSM8960) and supports up
to 4 core clocks and a separate L2 clock. Furthermore, L2 clock is
represented as the interconnect to facilitate L2 frequency scaling
together with scaling the CPU frequencies.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
include/dt-bindings/clock/qcom,krait-cc.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 include/dt-bindings/clock/qcom,krait-cc.h
diff --git a/include/dt-bindings/clock/qcom,krait-cc.h b/include/dt-bindings/clock/qcom,krait-cc.h
new file mode 100644
index 000000000000..9d181873c414
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,krait-cc.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd. All rights reserved.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_QCOM_KRAIT_CC_H
+#define __DT_BINDINGS_CLOCK_QCOM_KRAIT_CC_H
+
+#define KRAIT_CPU_0 0
+#define KRAIT_CPU_1 1
+#define KRAIT_CPU_2 2
+#define KRAIT_CPU_3 3
+#define KRAIT_L2 4
+
+#endif
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (2 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 03/23] dt-bindings: clock: qcom,krait-cc: Krait core clock controller Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 15:33 ` Rob Herring
2023-08-27 11:50 ` [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP Dmitry Baryshkov
` (18 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The L2 cache device on Qualcomm Krait platforms controls the supplying
voltages and the cache frequency. Add corresponding bindings for this
device.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../bindings/cache/qcom,krait-l2-cache.yaml | 86 +++++++++++++++++++
include/dt-bindings/soc/qcom,krait-l2-cache.h | 12 +++
2 files changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
create mode 100644 include/dt-bindings/soc/qcom,krait-l2-cache.h
diff --git a/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml b/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
new file mode 100644
index 000000000000..59ce11dd0a24
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/qcom,krait-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Krait L2 Cache
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ L2 cache on Qualcomm Krait platforms is shared between all CPU cores. L2
+ cache frequency and voltages should be scaled according to the needs of the
+ cores.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,krait-l2-cache
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: qcom,krait-l2-cache
+ - const: cache
+
+ clocks:
+ maxItems: 1
+
+ '#interconnect-cells':
+ const: 1
+
+ vdd-mem-supply:
+ description: suppling regulator for the memory cells of the cache
+
+ vdd-dig-supply:
+ description: suppling regulator for the digital logic of the cache
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - cache-level
+ - cache-unified
+ - clocks
+ - '#interconnect-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,krait-l2-cache.h>
+
+ l2-cache {
+ compatible = "qcom,krait-l2-cache", "cache";
+ cache-level = <2>;
+ cache-unified;
+ vdd-mem-supply = <&pm8921_l24>;
+ vdd-dig-supply = <&pm8921_s3>;
+ clocks = <&kraitcc 4>;
+ #interconnect-cells = <1>;
+ operating-points-v2 = <&l2_opp_table>;
+
+ l2_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <950000 950000 1150000>;
+ };
+ };
+ };
+...
+
diff --git a/include/dt-bindings/soc/qcom,krait-l2-cache.h b/include/dt-bindings/soc/qcom,krait-l2-cache.h
new file mode 100644
index 000000000000..c9a38d368111
--- /dev/null
+++ b/include/dt-bindings/soc/qcom,krait-l2-cache.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd. All rights reserved.
+ */
+
+#ifndef __DT_BINDINGS_SOC_QCOM_KRAIT_L2_CACHE_H
+#define __DT_BINDINGS_SOC_QCOM_KRAIT_L2_CACHE_H
+
+#define MASTER_KRAIT_L2 0
+#define SLAVE_KRAIT_L2 1
+
+#endif
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (3 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
[not found] ` <493aff10d698c9ca5bdbeae45250f5fe.sboyd@kernel.org>
2023-08-27 11:50 ` [PATCH v4 06/23] clk: qcom: krait-cc: rewrite driver to use clk_hw instead of clk Dmitry Baryshkov
` (17 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Sometimes it might be required to scale the clock using the OPP
framework (e.g. to scale regulators following the required clock rate).
Extend the interconnec-clk framework to handle OPP case in addition to
scaling the clock.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/interconnect/icc-clk.c | 13 +++++++++++--
include/linux/interconnect-clk.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
index d787f2ea36d9..45ffb068979d 100644
--- a/drivers/interconnect/icc-clk.c
+++ b/drivers/interconnect/icc-clk.c
@@ -7,10 +7,13 @@
#include <linux/device.h>
#include <linux/interconnect-clk.h>
#include <linux/interconnect-provider.h>
+#include <linux/pm_opp.h>
struct icc_clk_node {
+ struct device *dev;
struct clk *clk;
bool enabled;
+ bool opp;
};
struct icc_clk_provider {
@@ -25,12 +28,16 @@ struct icc_clk_provider {
static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
{
struct icc_clk_node *qn = src->data;
+ unsigned long rate = icc_units_to_bps(src->peak_bw);
int ret;
if (!qn || !qn->clk)
return 0;
- if (!src->peak_bw) {
+ if (qn->opp)
+ return dev_pm_opp_set_rate(qn->dev, rate);
+
+ if (!rate) {
if (qn->enabled)
clk_disable_unprepare(qn->clk);
qn->enabled = false;
@@ -45,7 +52,7 @@ static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
qn->enabled = true;
}
- return clk_set_rate(qn->clk, icc_units_to_bps(src->peak_bw));
+ return clk_set_rate(qn->clk, rate);
}
static int icc_clk_get_bw(struct icc_node *node, u32 *avg, u32 *peak)
@@ -106,7 +113,9 @@ struct icc_provider *icc_clk_register(struct device *dev,
icc_provider_init(provider);
for (i = 0, j = 0; i < num_clocks; i++) {
+ qp->clocks[i].dev = dev;
qp->clocks[i].clk = data[i].clk;
+ qp->clocks[i].opp = data[i].opp;
node = icc_node_create(first_id + j);
if (IS_ERR(node)) {
diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h
index 0cd80112bea5..c695e5099901 100644
--- a/include/linux/interconnect-clk.h
+++ b/include/linux/interconnect-clk.h
@@ -11,6 +11,7 @@ struct device;
struct icc_clk_data {
struct clk *clk;
const char *name;
+ bool opp;
};
struct icc_provider *icc_clk_register(struct device *dev,
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 06/23] clk: qcom: krait-cc: rewrite driver to use clk_hw instead of clk
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (4 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator Dmitry Baryshkov
` (16 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The krait-cc driver still uses struct clk internally. Rewrite it to
allocate and register struct clk_hw instead.
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/clk/qcom/krait-cc.c | 141 ++++++++++++++++--------------------
1 file changed, 63 insertions(+), 78 deletions(-)
diff --git a/drivers/clk/qcom/krait-cc.c b/drivers/clk/qcom/krait-cc.c
index 410ae8390f1c..a37abbd31f50 100644
--- a/drivers/clk/qcom/krait-cc.c
+++ b/drivers/clk/qcom/krait-cc.c
@@ -13,17 +13,9 @@
#include <linux/clk-provider.h>
#include <linux/slab.h>
-#include "clk-krait.h"
-
-enum {
- cpu0_mux = 0,
- cpu1_mux,
- cpu2_mux,
- cpu3_mux,
- l2_mux,
+#include <dt-bindings/clock/qcom,krait-cc.h>
- clks_max,
-};
+#include "clk-krait.h"
static unsigned int sec_mux_map[] = {
2,
@@ -235,7 +227,7 @@ krait_add_pri_mux(struct device *dev, struct clk_hw *hfpll_div, struct clk_hw *s
.parent_data = p_data,
.num_parents = ARRAY_SIZE(p_data),
.ops = &krait_mux_clk_ops,
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
};
struct clk_hw *clk;
char *hfpll_name;
@@ -324,19 +316,6 @@ static struct clk_hw *krait_add_clks(struct device *dev, int id, bool unique_aux
return pri_mux;
}
-static struct clk *krait_of_get(struct of_phandle_args *clkspec, void *data)
-{
- unsigned int idx = clkspec->args[0];
- struct clk **clks = data;
-
- if (idx >= clks_max) {
- pr_err("%s: invalid clock index %d\n", __func__, idx);
- return ERR_PTR(-EINVAL);
- }
-
- return clks[idx] ? : ERR_PTR(-ENODEV);
-}
-
static const struct of_device_id krait_cc_match_table[] = {
{ .compatible = "qcom,krait-cc-v1", (void *)1UL },
{ .compatible = "qcom,krait-cc-v2" },
@@ -344,60 +323,84 @@ static const struct of_device_id krait_cc_match_table[] = {
};
MODULE_DEVICE_TABLE(of, krait_cc_match_table);
+static int krait_clk_reinit(struct clk_hw *hw, int cpu)
+{
+ struct clk *clk;
+ unsigned long cur_rate, aux_rate;
+ char name[5]; /* CPUn */
+
+ if (cpu == -1)
+ strcpy(name, "L2");
+ else
+ snprintf(name, sizeof(name), "CPU%d", cpu);
+
+ clk = clk_hw_get_clk(hw, clk_hw_get_name(hw));
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ aux_rate = 384000000;
+
+ cur_rate = clk_get_rate(clk);
+ if (cur_rate < aux_rate) {
+ pr_info("%s @ Undefined rate %lu. Forcing new rate.\n",
+ name, cur_rate / 1000);
+ cur_rate = aux_rate;
+ }
+
+ clk_set_rate(clk, aux_rate);
+ clk_set_rate(clk, 2);
+ clk_set_rate(clk, cur_rate);
+ pr_info("%s @ %lu KHz\n", name, clk_get_rate(clk) / 1000);
+
+ clk_put(clk);
+
+ return 0;
+}
+
+/* Krait configurations have at most 4 CPUs and one L2 */
+#define KRAIT_NUM_CLOCKS 5
+
static int krait_cc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
const struct of_device_id *id;
- unsigned long cur_rate, aux_rate;
- int cpu;
- struct clk_hw *mux, *l2_pri_mux;
- struct clk *clk, **clks;
+ int cpu, ret;
+ struct clk_hw *clk;
+ struct clk_hw_onecell_data *clks;
id = of_match_device(krait_cc_match_table, dev);
if (!id)
return -ENODEV;
/* Rate is 1 because 0 causes problems for __clk_mux_determine_rate */
- clk = clk_register_fixed_rate(dev, "qsb", NULL, 0, 1);
+ clk = clk_hw_register_fixed_rate(dev, "qsb", NULL, 0, 1);
if (IS_ERR(clk))
return PTR_ERR(clk);
if (!id->data) {
- clk = clk_register_fixed_factor(dev, "acpu_aux",
- "gpll0_vote", 0, 1, 2);
+ clk = clk_hw_register_fixed_factor(dev, "acpu_aux", "gpll0_vote", 0, 1, 2);
if (IS_ERR(clk))
return PTR_ERR(clk);
}
- /* Krait configurations have at most 4 CPUs and one L2 */
- clks = devm_kcalloc(dev, clks_max, sizeof(*clks), GFP_KERNEL);
+ clks = devm_kzalloc(dev, struct_size(clks, hws, KRAIT_NUM_CLOCKS), GFP_KERNEL);
if (!clks)
return -ENOMEM;
+ clks->num = KRAIT_NUM_CLOCKS;
+ BUILD_BUG_ON(KRAIT_L2 >= KRAIT_NUM_CLOCKS);
+
for_each_possible_cpu(cpu) {
- mux = krait_add_clks(dev, cpu, id->data);
- if (IS_ERR(mux))
- return PTR_ERR(mux);
- clks[cpu] = mux->clk;
+ clk = krait_add_clks(dev, cpu, id->data);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+ clks->hws[cpu] = clk;
}
- l2_pri_mux = krait_add_clks(dev, -1, id->data);
- if (IS_ERR(l2_pri_mux))
- return PTR_ERR(l2_pri_mux);
- clks[l2_mux] = l2_pri_mux->clk;
-
- /*
- * We don't want the CPU or L2 clocks to be turned off at late init
- * if CPUFREQ or HOTPLUG configs are disabled. So, bump up the
- * refcount of these clocks. Any cpufreq/hotplug manager can assume
- * that the clocks have already been prepared and enabled by the time
- * they take over.
- */
- for_each_online_cpu(cpu) {
- clk_prepare_enable(clks[l2_mux]);
- WARN(clk_prepare_enable(clks[cpu]),
- "Unable to turn on CPU%d clock", cpu);
- }
+ clk = krait_add_clks(dev, -1, id->data);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+ clks->hws[KRAIT_L2] = clk;
/*
* Force reinit of HFPLLs and muxes to overwrite any potential
@@ -410,31 +413,13 @@ static int krait_cc_probe(struct platform_device *pdev)
* two different rates to force a HFPLL reinit under all
* circumstances.
*/
- cur_rate = clk_get_rate(clks[l2_mux]);
- aux_rate = 384000000;
- if (cur_rate < aux_rate) {
- pr_info("L2 @ Undefined rate. Forcing new rate.\n");
- cur_rate = aux_rate;
- }
- clk_set_rate(clks[l2_mux], aux_rate);
- clk_set_rate(clks[l2_mux], 2);
- clk_set_rate(clks[l2_mux], cur_rate);
- pr_info("L2 @ %lu KHz\n", clk_get_rate(clks[l2_mux]) / 1000);
- for_each_possible_cpu(cpu) {
- clk = clks[cpu];
- cur_rate = clk_get_rate(clk);
- if (cur_rate < aux_rate) {
- pr_info("CPU%d @ Undefined rate. Forcing new rate.\n", cpu);
- cur_rate = aux_rate;
- }
+ krait_clk_reinit(clks->hws[KRAIT_L2], -1);
+ for_each_possible_cpu(cpu)
+ krait_clk_reinit(clks->hws[cpu], cpu);
- clk_set_rate(clk, aux_rate);
- clk_set_rate(clk, 2);
- clk_set_rate(clk, cur_rate);
- pr_info("CPU%d @ %lu KHz\n", cpu, clk_get_rate(clk) / 1000);
- }
-
- of_clk_add_provider(dev->of_node, krait_of_get, clks);
+ ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clks);
+ if (ret)
+ return ret;
return 0;
}
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (5 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 06/23] clk: qcom: krait-cc: rewrite driver to use clk_hw instead of clk Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 10:49 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling Dmitry Baryshkov
` (15 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SPM / SAW2 device also provides a voltage regulator functionality
with optional AVS (Adaptive Voltage Scaling) support. The exact register
sequence and voltage ranges differs from device to device.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/soc/qcom/spm.c | 221 ++++++++++++++++++++++++++++++++++++++++-
include/soc/qcom/spm.h | 9 ++
2 files changed, 225 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
index 2f0b1bfe7658..595e2afb2141 100644
--- a/drivers/soc/qcom/spm.c
+++ b/drivers/soc/qcom/spm.c
@@ -6,20 +6,40 @@
* SAW power controller driver
*/
-#include <linux/kernel.h>
+#include <linux/bitfield.h>
+#include <linux/err.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/linear_range.h>
#include <linux/module.h>
-#include <linux/slab.h>
#include <linux/of.h>
-#include <linux/err.h>
#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/smp.h>
+
+#include <linux/regulator/driver.h>
+
#include <soc/qcom/spm.h>
+#define FIELD_SET(current, mask, val) \
+ (((current) & ~(mask)) | FIELD_PREP((mask), (val)))
+
#define SPM_CTL_INDEX 0x7f
#define SPM_CTL_INDEX_SHIFT 4
#define SPM_CTL_EN BIT(0)
+/* These registers might be specific to SPM 1.1 */
+#define SPM_VCTL_VLVL GENMASK(7, 0)
+#define SPM_PMIC_DATA_0_VLVL GENMASK(7, 0)
+#define SPM_PMIC_DATA_1_MIN_VSEL GENMASK(5, 0)
+#define SPM_PMIC_DATA_1_MAX_VSEL GENMASK(21, 16)
+
+#define SPM_1_1_AVS_CTL_AVS_ENABLED BIT(27)
+#define SPM_AVS_CTL_MAX_VLVL GENMASK(22, 17)
+#define SPM_AVS_CTL_MIN_VLVL GENMASK(15, 10)
+
enum spm_reg {
SPM_REG_CFG,
SPM_REG_SPM_CTL,
@@ -29,10 +49,12 @@ enum spm_reg {
SPM_REG_PMIC_DATA_1,
SPM_REG_VCTL,
SPM_REG_SEQ_ENTRY,
- SPM_REG_SPM_STS,
+ SPM_REG_STS0,
+ SPM_REG_STS1,
SPM_REG_PMIC_STS,
SPM_REG_AVS_CTL,
SPM_REG_AVS_LIMIT,
+ SPM_REG_RST,
SPM_REG_NR,
};
@@ -169,6 +191,10 @@ static const struct spm_reg_data spm_reg_8226_cpu = {
static const u16 spm_reg_offset_v1_1[SPM_REG_NR] = {
[SPM_REG_CFG] = 0x08,
+ [SPM_REG_STS0] = 0x0c,
+ [SPM_REG_STS1] = 0x10,
+ [SPM_REG_VCTL] = 0x14,
+ [SPM_REG_AVS_CTL] = 0x18,
[SPM_REG_SPM_CTL] = 0x20,
[SPM_REG_PMIC_DLY] = 0x24,
[SPM_REG_PMIC_DATA_0] = 0x28,
@@ -176,7 +202,12 @@ static const u16 spm_reg_offset_v1_1[SPM_REG_NR] = {
[SPM_REG_SEQ_ENTRY] = 0x80,
};
+static void smp_set_vdd_v1_1(void *data);
+
/* SPM register data for 8064 */
+static struct linear_range spm_v1_1_regulator_range =
+ REGULATOR_LINEAR_RANGE(700000, 0, 56, 12500);
+
static const struct spm_reg_data spm_reg_8064_cpu = {
.reg_offset = spm_reg_offset_v1_1,
.spm_cfg = 0x1F,
@@ -187,6 +218,10 @@ static const struct spm_reg_data spm_reg_8064_cpu = {
0x10, 0x54, 0x30, 0x0C, 0x24, 0x30, 0x0F },
.start_index[PM_SLEEP_MODE_STBY] = 0,
.start_index[PM_SLEEP_MODE_SPC] = 2,
+ .set_vdd = smp_set_vdd_v1_1,
+ .range = &spm_v1_1_regulator_range,
+ .init_uV = 1300000,
+ .ramp_delay = 1250,
};
static inline void spm_register_write(struct spm_driver_data *drv,
@@ -238,6 +273,181 @@ void spm_set_low_power_mode(struct spm_driver_data *drv,
spm_register_write_sync(drv, SPM_REG_SPM_CTL, ctl_val);
}
+static int spm_set_voltage_sel(struct regulator_dev *rdev, unsigned int selector)
+{
+ struct spm_driver_data *drv = rdev_get_drvdata(rdev);
+
+ drv->volt_sel = selector;
+
+ /* Always do the SAW register writes on the corresponding CPU */
+ return smp_call_function_single(drv->reg_cpu, drv->reg_data->set_vdd, drv, true);
+}
+
+static int spm_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct spm_driver_data *drv = rdev_get_drvdata(rdev);
+
+ return drv->volt_sel;
+}
+
+static const struct regulator_ops spm_reg_ops = {
+ .set_voltage_sel = spm_set_voltage_sel,
+ .get_voltage_sel = spm_get_voltage_sel,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+static void smp_set_vdd_v1_1(void *data)
+{
+ struct spm_driver_data *drv = data;
+ unsigned int vctl, data0, data1, avs_ctl, sts;
+ unsigned int vlevel, volt_sel;
+ bool avs_enabled;
+
+ volt_sel = drv->volt_sel;
+ vlevel = volt_sel | 0x80; /* band */
+
+ avs_ctl = spm_register_read(drv, SPM_REG_AVS_CTL);
+ vctl = spm_register_read(drv, SPM_REG_VCTL);
+ data0 = spm_register_read(drv, SPM_REG_PMIC_DATA_0);
+ data1 = spm_register_read(drv, SPM_REG_PMIC_DATA_1);
+
+ avs_enabled = avs_ctl & SPM_1_1_AVS_CTL_AVS_ENABLED;
+
+ /* If AVS is enabled, switch it off during the voltage change */
+ if (avs_enabled) {
+ avs_ctl &= ~SPM_1_1_AVS_CTL_AVS_ENABLED;
+ spm_register_write(drv, SPM_REG_AVS_CTL, avs_ctl);
+ }
+
+ /* Kick the state machine back to idle */
+ spm_register_write(drv, SPM_REG_RST, 1);
+
+ vctl = FIELD_SET(vctl, SPM_VCTL_VLVL, vlevel);
+ data0 = FIELD_SET(data0, SPM_PMIC_DATA_0_VLVL, vlevel);
+ data1 = FIELD_SET(data1, SPM_PMIC_DATA_1_MIN_VSEL, volt_sel);
+ data1 = FIELD_SET(data1, SPM_PMIC_DATA_1_MAX_VSEL, volt_sel);
+
+ spm_register_write(drv, SPM_REG_VCTL, vctl);
+ spm_register_write(drv, SPM_REG_PMIC_DATA_0, data0);
+ spm_register_write(drv, SPM_REG_PMIC_DATA_1, data1);
+
+ if (read_poll_timeout_atomic(spm_register_read,
+ sts, sts == vlevel,
+ 1, 200, false,
+ drv, SPM_REG_STS1)) {
+ dev_err_ratelimited(drv->dev, "timeout setting the voltage (%x %x)!\n", sts, vlevel);
+ goto enable_avs;
+ }
+
+ if (avs_enabled) {
+ unsigned int max_avs = volt_sel;
+ unsigned int min_avs = max(max_avs, 4U) - 4;
+
+ avs_ctl = FIELD_SET(avs_ctl, SPM_AVS_CTL_MIN_VLVL, min_avs);
+ avs_ctl = FIELD_SET(avs_ctl, SPM_AVS_CTL_MAX_VLVL, max_avs);
+ spm_register_write(drv, SPM_REG_AVS_CTL, avs_ctl);
+ }
+
+enable_avs:
+ if (avs_enabled) {
+ avs_ctl |= SPM_1_1_AVS_CTL_AVS_ENABLED;
+ spm_register_write(drv, SPM_REG_AVS_CTL, avs_ctl);
+ }
+}
+
+static int spm_get_cpu(struct device *dev)
+{
+ int cpu;
+ bool found;
+
+ for_each_possible_cpu(cpu) {
+ struct device_node *cpu_node, *saw_node;
+
+ cpu_node = of_cpu_device_node_get(cpu);
+ if (!cpu_node)
+ continue;
+
+ saw_node = of_parse_phandle(cpu_node, "qcom,saw", 0);
+ found = (saw_node == dev->of_node);
+ of_node_put(saw_node);
+ of_node_put(cpu_node);
+
+ if (found)
+ return cpu;
+ }
+
+ /* L2 SPM is not bound to any CPU, tie it to CPU0 */
+
+ return 0;
+}
+
+#ifdef CONFIG_REGULATOR
+static int spm_register_regulator(struct device *dev, struct spm_driver_data *drv)
+{
+ struct regulator_config config = {
+ .dev = dev,
+ .driver_data = drv,
+ };
+ struct regulator_desc *rdesc;
+ struct regulator_dev *rdev;
+ int ret;
+ bool found;
+
+ if (!drv->reg_data->set_vdd)
+ return 0;
+
+ rdesc = devm_kzalloc(dev, sizeof(*rdesc), GFP_KERNEL);
+ if (!rdesc)
+ return -ENOMEM;
+
+ rdesc->name = "spm";
+ rdesc->of_match = of_match_ptr("regulator");
+ rdesc->type = REGULATOR_VOLTAGE;
+ rdesc->owner = THIS_MODULE;
+ rdesc->ops = &spm_reg_ops;
+
+ rdesc->linear_ranges = drv->reg_data->range;
+ rdesc->n_linear_ranges = 1;
+ rdesc->n_voltages = rdesc->linear_ranges[rdesc->n_linear_ranges - 1].max_sel + 1;
+ rdesc->ramp_delay = drv->reg_data->ramp_delay;
+
+ drv->reg_cpu = spm_get_cpu(dev);
+ dev_dbg(dev, "SAW2 bound to CPU %d\n", drv->reg_cpu);
+
+ /*
+ * Program initial voltage, otherwise registration will also try
+ * setting the voltage, which might result in undervolting the CPU.
+ */
+ drv->volt_sel = DIV_ROUND_UP(drv->reg_data->init_uV - rdesc->min_uV,
+ rdesc->uV_step);
+ ret = linear_range_get_selector_high(drv->reg_data->range,
+ drv->reg_data->init_uV,
+ &drv->volt_sel,
+ &found);
+ if (ret) {
+ dev_err(dev, "Initial uV value out of bounds\n");
+ return ret;
+ }
+
+ /* Always do the SAW register writes on the corresponding CPU */
+ smp_call_function_single(drv->reg_cpu, drv->reg_data->set_vdd, drv, true);
+
+ rdev = devm_regulator_register(dev, rdesc, &config);
+ if (IS_ERR(rdev)) {
+ dev_err(dev, "failed to register regulator\n");
+ return PTR_ERR(rdev);
+ }
+
+ return 0;
+}
+#else
+static int spm_register_regulator(struct device *dev, struct spm_driver_data *drv)
+{
+ return 0;
+}
+#endif
+
static const struct of_device_id spm_match_table[] = {
{ .compatible = "qcom,sdm660-gold-saw2-v4.1-l2",
.data = &spm_reg_660_gold_l2 },
@@ -288,6 +498,7 @@ static int spm_dev_probe(struct platform_device *pdev)
return -ENODEV;
drv->reg_data = match_id->data;
+ drv->dev = &pdev->dev;
platform_set_drvdata(pdev, drv);
/* Write the SPM sequences first.. */
@@ -315,7 +526,7 @@ static int spm_dev_probe(struct platform_device *pdev)
if (drv->reg_data->reg_offset[SPM_REG_SPM_CTL])
spm_set_low_power_mode(drv, PM_SLEEP_MODE_STBY);
- return 0;
+ return spm_register_regulator(&pdev->dev, drv);
}
static struct platform_driver spm_driver = {
diff --git a/include/soc/qcom/spm.h b/include/soc/qcom/spm.h
index 4951f9d8b0bd..9859ebe42003 100644
--- a/include/soc/qcom/spm.h
+++ b/include/soc/qcom/spm.h
@@ -30,11 +30,20 @@ struct spm_reg_data {
u32 avs_limit;
u8 seq[MAX_SEQ_DATA];
u8 start_index[PM_SLEEP_MODE_NR];
+
+ smp_call_func_t set_vdd;
+ /* for now we support only a single range */
+ struct linear_range *range;
+ unsigned int ramp_delay;
+ unsigned int init_uV;
};
struct spm_driver_data {
void __iomem *reg_base;
const struct spm_reg_data *reg_data;
+ struct device *dev;
+ unsigned int volt_sel;
+ int reg_cpu;
};
void spm_set_low_power_mode(struct spm_driver_data *drv,
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (6 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 10:49 ` Konrad Dybcio
2023-10-11 15:49 ` Rob Herring
2023-08-27 11:50 ` [PATCH v4 09/23] ARM: dts: qcom: apq8064-asus-nexus7-flo: constraint cpufreq regulators Dmitry Baryshkov
` (14 subsequent siblings)
22 siblings, 2 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add a simple driver that handles scaling of L2 frequency and voltages.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/soc/qcom/Kconfig | 9 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/krait-l2-cache.c | 160 ++++++++++++++++++++++++++++++
3 files changed, 170 insertions(+)
create mode 100644 drivers/soc/qcom/krait-l2-cache.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 715348869d04..1f3040ef551d 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -70,6 +70,15 @@ config QCOM_LLCC
SDM845. This provides interfaces to clients that use the LLCC.
Say yes here to enable LLCC slice driver.
+config QCOM_KRAIT_L2_CACHE
+ tristate "Qualcomm Krait L2 cache scaling"
+ depends on ARCH_QCOM && ARM || COMPILE_TEST
+ select INTERCONNECT
+ select INTERCONNECT_CLK
+ default ARM_QCOM_CPUFREQ_NVMEM
+ help
+ The driver for scaling the L2 cache frequency on Qualcomm Krait platforms.
+
config QCOM_KRYO_L2_ACCESSORS
bool
depends on (ARCH_QCOM || COMPILE_TEST) && ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index bbca2e1e55bb..4d16e5cdd334 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_QCOM_STATS) += qcom_stats.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
+obj-$(CONFIG_QCOM_KRAIT_L2_CACHE) += krait-l2-cache.o
obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) += kryo-l2-accessors.o
obj-$(CONFIG_QCOM_ICC_BWMON) += icc-bwmon.o
qcom_ice-objs += ice.o
diff --git a/drivers/soc/qcom/krait-l2-cache.c b/drivers/soc/qcom/krait-l2-cache.c
new file mode 100644
index 000000000000..fb0ca9f4797c
--- /dev/null
+++ b/drivers/soc/qcom/krait-l2-cache.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/interconnect-clk.h>
+#include <linux/interconnect-provider.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/regulator/consumer.h>
+
+#include <dt-bindings/soc/qcom,krait-l2-cache.h>
+
+/* Random ID that doesn't clash with main qnoc and OSM */
+#define L2_MASTER_NODE 2000
+
+static int krait_l2_set_one_supply(struct device *dev,
+ struct regulator *reg,
+ struct dev_pm_opp_supply *supply)
+{
+ int ret;
+
+ dev_dbg(dev, "%s: voltages (mV): %lu %lu %lu\n", __func__,
+ supply->u_volt_min, supply->u_volt, supply->u_volt_max);
+
+ ret = regulator_set_voltage_triplet(reg,
+ supply->u_volt_min,
+ supply->u_volt,
+ supply->u_volt_max);
+ if (ret) {
+ dev_err(dev, "%s: failed to set voltage (%lu %lu %lu mV): %d\n",
+ __func__, supply->u_volt_min, supply->u_volt,
+ supply->u_volt_max, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/* vdd-mem and vdd-dig */
+#define NUM_SUPPLIES 2
+static int krait_l2_config_regulators(struct device *dev,
+ struct dev_pm_opp *old_opp,
+ struct dev_pm_opp *new_opp,
+ struct regulator **regulators,
+ unsigned int count)
+{
+ struct dev_pm_opp_supply supplies[NUM_SUPPLIES];
+ unsigned long old_freq, freq;
+ int ret;
+
+ if (WARN_ON_ONCE(count != NUM_SUPPLIES))
+ return -EINVAL;
+
+ ret = dev_pm_opp_get_supplies(new_opp, supplies);
+ if (WARN_ON(ret))
+ return ret;
+
+ old_freq = dev_pm_opp_get_freq(old_opp);
+ freq = dev_pm_opp_get_freq(new_opp);
+
+ WARN_ON(!old_freq || !freq);
+ if (freq > old_freq) {
+ ret = krait_l2_set_one_supply(dev, regulators[0], &supplies[0]);
+ if (ret)
+ return ret;
+
+ ret = krait_l2_set_one_supply(dev, regulators[1], &supplies[1]);
+ if (ret) {
+ dev_pm_opp_get_supplies(old_opp, supplies);
+ krait_l2_set_one_supply(dev, regulators[0], &supplies[0]);
+
+ return ret;
+ }
+ } else {
+ ret = krait_l2_set_one_supply(dev, regulators[1], &supplies[1]);
+ if (ret)
+ return ret;
+
+ ret = krait_l2_set_one_supply(dev, regulators[0], &supplies[0]);
+ if (ret) {
+ dev_pm_opp_get_supplies(old_opp, supplies);
+ krait_l2_set_one_supply(dev, regulators[1], &supplies[1]);
+
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int krait_l2_probe(struct platform_device *pdev)
+{
+ struct dev_pm_opp_config krait_l2_cfg = {
+ .clk_names = (const char * const[]) { NULL, NULL },
+ .config_regulators = krait_l2_config_regulators,
+ .regulator_names = (const char * const[]) { "vdd-mem", "vdd-dig", NULL },
+ };
+ struct icc_clk_data data[] = {
+ { .name = "l2", .opp = true },
+ };
+
+ struct device *dev = &pdev->dev;
+ struct icc_provider *provider;
+ struct clk *clk;
+ int ret;
+
+ clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ ret = devm_pm_opp_set_config(dev, &krait_l2_cfg);
+ if (ret)
+ return ret;
+
+ ret = devm_pm_opp_of_add_table(dev);
+ if (ret)
+ return ret;
+
+ data[0].clk = clk;
+ provider = icc_clk_register(dev, L2_MASTER_NODE, ARRAY_SIZE(data), data);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ platform_set_drvdata(pdev, provider);
+
+ return 0;
+}
+
+static int krait_l2_remove(struct platform_device *pdev)
+{
+ struct icc_provider *provider = platform_get_drvdata(pdev);
+
+ icc_clk_unregister(provider);
+
+ return 0;
+}
+
+static const struct of_device_id krait_l2_match_table[] = {
+ { .compatible = "qcom,krait-l2-cache" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, krait_l2_match_table);
+
+static struct platform_driver krait_l2_driver = {
+ .probe = krait_l2_probe,
+ .remove = krait_l2_remove,
+ .driver = {
+ .name = "qcom-krait-l2",
+ .of_match_table = krait_l2_match_table,
+ .sync_state = icc_sync_state,
+ },
+};
+
+module_platform_driver(krait_l2_driver);
+
+MODULE_DESCRIPTION("Qualcomm Krait L2 scaling driver");
+MODULE_LICENSE("GPL v2");
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 09/23] ARM: dts: qcom: apq8064-asus-nexus7-flo: constraint cpufreq regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (7 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 10/23] ARM: dts: qcom: apq8064-cm-qs600: " Dmitry Baryshkov
` (13 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add additional constraints to the CPUfreq-related regulators, it is
better be safe than sorry there.
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
index 329c2546aa0a..b60761290156 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
@@ -224,9 +224,9 @@ pm8921_s1: s1 {
bias-pull-down;
};
- /* msm otg HSUSB_VDDCX */
+ /* msm otg HSUSB_VDDCX and VDD_DIG */
pm8921_s3: s3 {
- regulator-min-microvolt = <500000>;
+ regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
};
@@ -310,6 +310,12 @@ pm8921_l23: l23 {
bias-pull-down;
};
+ /* VDD_MEM */
+ pm8921_l24: l24 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1150000>;
+ };
+
/*
* tabla2x-slim-CDC_VDDA_A_1P2V
* tabla2x-slim-VDDD_CDC_D
@@ -338,8 +344,12 @@ pm8921_lvs6: lvs6 {
/*
* mipi_dsi.1-dsi1_vddio
* pil_riva-pll_vdd
+ * HFPLL regulator
*/
pm8921_lvs7: lvs7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
bias-pull-down;
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 10/23] ARM: dts: qcom: apq8064-cm-qs600: constraint cpufreq regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (8 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 09/23] ARM: dts: qcom: apq8064-asus-nexus7-flo: constraint cpufreq regulators Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 11/23] ARM: dts: qcom: apq8064-ifc6410: " Dmitry Baryshkov
` (12 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add additional constraints to the CPUfreq-related regulators, it is
better be safe than sorry there.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../boot/dts/qcom/qcom-apq8064-cm-qs600.dts | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
index 671d58cc2741..ee071aed9b8d 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
@@ -116,8 +116,8 @@ pm8921_s1: s1 {
};
pm8921_s3: s3 {
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1400000>;
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
};
@@ -157,9 +157,23 @@ pm8921_l23: l23 {
bias-pull-down;
};
+ pm8921_l24: l24 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1150000>;
+ bias-pull-down;
+ };
+
pm8921_lvs6: lvs6 {
bias-pull-down;
};
+
+ /* HFPLL regulator */
+ pm8921_lvs7: lvs7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 11/23] ARM: dts: qcom: apq8064-ifc6410: constraint cpufreq regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (9 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 10/23] ARM: dts: qcom: apq8064-cm-qs600: " Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 12/23] ARM: dts: qcom: apq8064-sony-xperia-lagan-yuga: " Dmitry Baryshkov
` (11 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add additional constraints to the CPUfreq-related regulators, it is
better be safe than sorry there.
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
index 3078afda37c6..062c9cf4ec77 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
@@ -227,8 +227,8 @@ pm8921_s1: s1 {
};
pm8921_s3: s3 {
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1400000>;
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
};
@@ -274,6 +274,12 @@ pm8921_l23: l23 {
bias-pull-down;
};
+ pm8921_l24: l24 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1150000>;
+ bias-pull-down;
+ };
+
pm8921_lvs1: lvs1 {
bias-pull-down;
};
@@ -282,6 +288,14 @@ pm8921_lvs6: lvs6 {
bias-pull-down;
};
+ /* HFPLL regulator */
+ pm8921_lvs7: lvs7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
pm8921_hdmi_switch: hdmi-switch {
bias-pull-down;
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 12/23] ARM: dts: qcom: apq8064-sony-xperia-lagan-yuga: constraint cpufreq regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (10 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 11/23] ARM: dts: qcom: apq8064-ifc6410: " Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 13/23] ARM: dts: qcom: apq8064: rename SAW nodes to power-manager Dmitry Baryshkov
` (10 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add additional constraints to the CPUfreq-related regulators, it is
better be safe than sorry there.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
index 2412aa3e3e8d..5b911e5f0b55 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
@@ -139,7 +139,7 @@ pm8921_s2: s2 {
};
pm8921_s3: s3 {
- regulator-min-microvolt = <500000>;
+ regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
bias-pull-down;
@@ -290,7 +290,7 @@ pm8921_l23: l23 {
};
pm8921_l24: l24 {
- regulator-min-microvolt = <750000>;
+ regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1150000>;
bias-pull-down;
};
@@ -344,7 +344,11 @@ pm8921_lvs6: lvs6 {
bias-pull-down;
};
+ /* HFPLL regulator */
pm8921_lvs7: lvs7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
bias-pull-down;
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 13/23] ARM: dts: qcom: apq8064: rename SAW nodes to power-manager
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (11 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 12/23] ARM: dts: qcom: apq8064-sony-xperia-lagan-yuga: " Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 14/23] ARM: dts: qcom: apq8064: declare SAW2 regulators Dmitry Baryshkov
` (9 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Per the power-domain.yaml, the power-controller node name is reserved
for power-domain providers. Rename SAW2 nodes to 'power-manager', the
name which is suggested by qcom,spm.yaml
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index 5b7d2c6f0ce9..2f94d26fc792 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -365,25 +365,25 @@ acc3: clock-controller@20b8000 {
#clock-cells = <0>;
};
- saw0: power-controller@2089000 {
+ saw0: power-manager@2089000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
regulator;
};
- saw1: power-controller@2099000 {
+ saw1: power-manager@2099000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
regulator;
};
- saw2: power-controller@20a9000 {
+ saw2: power-manager@20a9000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020a9000 0x1000>, <0x02009000 0x1000>;
regulator;
};
- saw3: power-controller@20b9000 {
+ saw3: power-manager@20b9000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020b9000 0x1000>, <0x02009000 0x1000>;
regulator;
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 14/23] ARM: dts: qcom: apq8064: declare SAW2 regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (12 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 13/23] ARM: dts: qcom: apq8064: rename SAW nodes to power-manager Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller Dmitry Baryshkov
` (8 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 (SPM and AVS Wrapper) among other things is yet another way to
handle CPU-related PMIC regulators. Provide a way to control voltage of
these regulators.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index 2f94d26fc792..ba7d5ef8de17 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -368,25 +368,41 @@ acc3: clock-controller@20b8000 {
saw0: power-manager@2089000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw0_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
saw1: power-manager@2099000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw1_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
saw2: power-manager@20a9000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020a9000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw2_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
saw3: power-manager@20b9000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020b9000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw3_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
sps_sic_non_secure: sps-sic-non-secure@12100000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (13 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 14/23] ARM: dts: qcom: apq8064: declare SAW2 regulators Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 10:54 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling Dmitry Baryshkov
` (7 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Add device node for the clock controller for the CPU cores and L2
clocks. It will be further used by the L2 and by the CPUfreq nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 26 ++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index ba7d5ef8de17..a05e64bff07f 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -213,6 +213,32 @@ sleep_clk: sleep_clk {
};
};
+ kraitcc: clock-controller {
+ compatible = "qcom,krait-cc-v1";
+ clocks = <&gcc PLL9>,
+ <&gcc PLL10>,
+ <&gcc PLL16>,
+ <&gcc PLL17>,
+ <&gcc PLL12>,
+ <&acc0>,
+ <&acc1>,
+ <&acc2>,
+ <&acc3>,
+ <&l2cc>;
+ clock-names = "hfpll0",
+ "hfpll1",
+ "hfpll2",
+ "hfpll3",
+ "hfpll_l2",
+ "acpu0_aux",
+ "acpu1_aux",
+ "acpu2_aux",
+ "acpu3_aux",
+ "acpu_l2_aux";
+ #clock-cells = <1>;
+ #interconnect-cells = <1>;
+ };
+
sfpb_mutex: hwmutex {
compatible = "qcom,sfpb-mutex";
syscon = <&sfpb_wrapper_mutex 0x604 0x4>;
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (14 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 10:55 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support Dmitry Baryshkov
` (6 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Populate L2 cache node with clock, supplies and OPP information to
facilitate scaling L2 frequency.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../dts/qcom/qcom-apq8064-asus-nexus7-flo.dts | 5 +
.../boot/dts/qcom/qcom-apq8064-cm-qs600.dts | 5 +
.../boot/dts/qcom/qcom-apq8064-ifc6410.dts | 5 +
.../qcom-apq8064-sony-xperia-lagan-yuga.dts | 5 +
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 100 +++++++++++++++++-
5 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
index b60761290156..a8f826f0479a 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
@@ -78,6 +78,11 @@ reboot-mode {
};
};
+&L2 {
+ vdd-mem-supply = <&pm8921_l24>;
+ vdd-dig-supply = <&pm8921_s3>;
+};
+
&dsi0 {
vdda-supply = <&pm8921_l2>;/*VDD_MIPI1 to 4*/
vdd-supply = <&pm8921_l8>;
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
index ee071aed9b8d..7372f62fa31d 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
@@ -35,6 +35,11 @@ v3p3_fixed: regulator-v3p3 {
};
};
+&L2 {
+ vdd-mem-supply = <&pm8921_l24>;
+ vdd-dig-supply = <&pm8921_s3>;
+};
+
&gsbi1 {
qcom,mode = <GSBI_PROT_I2C>;
status = "okay";
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
index 062c9cf4ec77..ddc69496100a 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
@@ -69,6 +69,11 @@ ext_3p3v: regulator-ext-3p3v {
};
};
+&L2 {
+ vdd-mem-supply = <&pm8921_l24>;
+ vdd-dig-supply = <&pm8921_s3>;
+};
+
&gsbi1 {
qcom,mode = <GSBI_PROT_I2C>;
status = "okay";
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
index 5b911e5f0b55..8e0c12d406f6 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
@@ -57,6 +57,11 @@ key-volume-up {
};
};
+&L2 {
+ vdd-mem-supply = <&pm8921_l24>;
+ vdd-dig-supply = <&pm8921_s3>;
+};
+
&gsbi5 {
qcom,mode = <GSBI_PROT_I2C_UART>;
status = "okay";
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index a05e64bff07f..21990ca5851a 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -2,6 +2,7 @@
/dts-v1/;
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
+#include <dt-bindings/clock/qcom,krait-cc.h>
#include <dt-bindings/clock/qcom,lcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
@@ -81,9 +82,106 @@ CPU3: cpu@3 {
};
L2: l2-cache {
- compatible = "cache";
+ compatible = "qcom,krait-l2-cache", "cache";
cache-level = <2>;
cache-unified;
+ clocks = <&kraitcc KRAIT_L2>;
+ #interconnect-cells = <1>;
+ operating-points-v2 = <&l2_opp_table>;
+
+ l2_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <950000 950000 1150000>;
+ };
+
+ opp-432000000 {
+ opp-hz = /bits/ 64 <432000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <1050000 1050000 1150000>;
+ };
+
+ opp-486000000 {
+ opp-hz = /bits/ 64 <486000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <1050000 1050000 1150000>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <1050000 1050000 1150000>;
+ };
+
+ opp-594000000 {
+ opp-hz = /bits/ 64 <594000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <1050000 1050000 1150000>;
+ };
+
+ opp-648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <1050000 1050000 1150000>,
+ <1050000 1050000 1150000>;
+ };
+
+ opp-702000000 {
+ opp-hz = /bits/ 64 <702000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-756000000 {
+ opp-hz = /bits/ 64 <756000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-864000000 {
+ opp-hz = /bits/ 64 <864000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-918000000 {
+ opp-hz = /bits/ 64 <918000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-972000000 {
+ opp-hz = /bits/ 64 <972000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-1026000000 {
+ opp-hz = /bits/ 64 <1026000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-1080000000 {
+ opp-hz = /bits/ 64 <1080000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+
+ opp-1134000000 {
+ opp-hz = /bits/ 64 <1134000000>;
+ opp-microvolt = <1150000 1150000 1150000>,
+ <1150000 1150000 1150000>;
+ };
+ };
};
idle-states {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (15 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-28 10:56 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 18/23] ARM: dts: qcom: apq8064: enable passive CPU cooling Dmitry Baryshkov
` (5 subsequent siblings)
22 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Declare CPU frequency-scaling properties. Each CPU has its own clock,
how all CPUs have the same OPP table. Voltage scaling is not (yet)
enabled with this patch. It will be enabled later.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 483 +++++++++++++++++++++++
1 file changed, 483 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index 21990ca5851a..f08d87bcc37e 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/soc/qcom,gsbi.h>
+#include <dt-bindings/soc/qcom,krait-l2-cache.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
/ {
@@ -46,6 +47,13 @@ CPU0: cpu@0 {
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
cpu-idle-states = <&CPU_SPC>;
+ clocks = <&kraitcc KRAIT_CPU_0>;
+ clock-names = "cpu";
+ clock-latency = <100000>;
+ vdd-core-supply = <&saw0_vreg>;
+ interconnects = <&L2 MASTER_KRAIT_L2 &L2 SLAVE_KRAIT_L2>;
+ operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
};
CPU1: cpu@1 {
@@ -57,6 +65,13 @@ CPU1: cpu@1 {
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
cpu-idle-states = <&CPU_SPC>;
+ clocks = <&kraitcc KRAIT_CPU_1>;
+ clock-names = "cpu";
+ clock-latency = <100000>;
+ vdd-core-supply = <&saw1_vreg>;
+ interconnects = <&L2 MASTER_KRAIT_L2 &L2 SLAVE_KRAIT_L2>;
+ operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
};
CPU2: cpu@2 {
@@ -68,6 +83,13 @@ CPU2: cpu@2 {
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
cpu-idle-states = <&CPU_SPC>;
+ clocks = <&kraitcc KRAIT_CPU_2>;
+ clock-names = "cpu";
+ clock-latency = <100000>;
+ vdd-core-supply = <&saw2_vreg>;
+ interconnects = <&L2 MASTER_KRAIT_L2 &L2 SLAVE_KRAIT_L2>;
+ operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
};
CPU3: cpu@3 {
@@ -79,6 +101,13 @@ CPU3: cpu@3 {
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
cpu-idle-states = <&CPU_SPC>;
+ clocks = <&kraitcc KRAIT_CPU_3>;
+ clock-names = "cpu";
+ clock-latency = <100000>;
+ vdd-core-supply = <&saw3_vreg>;
+ interconnects = <&L2 MASTER_KRAIT_L2 &L2 SLAVE_KRAIT_L2>;
+ operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
};
L2: l2-cache {
@@ -195,6 +224,454 @@ CPU_SPC: spc {
};
};
+ cpu_opp_table: opp-table-cpu {
+ compatible = "operating-points-v2-krait-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+
+ /* Voltage thresholds are <target min max> */
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-peak-kBps = <384000>;
+ opp-microvolt-speed0-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed0-pvs1 = <925000 900000 950000>;
+ opp-microvolt-speed0-pvs3 = <875000 850000 900000>;
+ opp-microvolt-speed0-pvs4 = <875000 850000 900000>;
+ opp-microvolt-speed1-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed1-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed2-pvs1 = <925000 925000 925000>;
+ opp-microvolt-speed2-pvs2 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed14-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs5 = <875000 875000 875000>;
+ opp-microvolt-speed14-pvs6 = <900000 875000 925000>;
+ opp-supported-hw = <0x4007>;
+ /*
+ * higher latency as it requires switching between
+ * clock sources
+ */
+ clock-latency-ns = <244144>;
+ };
+
+ opp-486000000 {
+ opp-hz = /bits/ 64 <486000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <975000 975000 1000000>;
+ opp-microvolt-speed0-pvs1 = <950000 925000 975000>;
+ opp-microvolt-speed0-pvs3 = <900000 875000 925000>;
+ opp-microvolt-speed0-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed1-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed2-pvs1 = <925000 925000 925000>;
+ opp-microvolt-speed2-pvs2 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed14-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs5 = <875000 875000 875000>;
+ opp-microvolt-speed14-pvs6 = <875000 875000 875000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-594000000 {
+ opp-hz = /bits/ 64 <594000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <1000000 1000000 1025000>;
+ opp-microvolt-speed0-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed0-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed0-pvs4 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed1-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed2-pvs1 = <925000 925000 925000>;
+ opp-microvolt-speed2-pvs2 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed14-pvs1 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs5 = <875000 875000 875000>;
+ opp-microvolt-speed14-pvs6 = <900000 875000 925000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-702000000 {
+ opp-hz = /bits/ 64 <702000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <1025000 1025000 1050000>;
+ opp-microvolt-speed0-pvs1 = <1000000 975000 1025000>;
+ opp-microvolt-speed0-pvs3 = <950000 925000 975000>;
+ opp-microvolt-speed0-pvs4 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs0 = <962500 962500 987500>;
+ opp-microvolt-speed1-pvs1 = <987500 962500 1012500>;
+ opp-microvolt-speed1-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed1-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs0 = <950000 950000 975000>;
+ opp-microvolt-speed2-pvs1 = <925000 925000 925000>;
+ opp-microvolt-speed2-pvs2 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs5 = <900000 875000 925000>;
+ opp-microvolt-speed2-pvs6 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs0 = <962500 962500 987500>;
+ opp-microvolt-speed14-pvs1 = <987500 962500 1012500>;
+ opp-microvolt-speed14-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs4 = <900000 875000 925000>;
+ opp-microvolt-speed14-pvs5 = <875000 875000 875000>;
+ opp-microvolt-speed14-pvs6 = <900000 875000 925000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <1075000 1075000 1100000>;
+ opp-microvolt-speed0-pvs1 = <1050000 1025000 1075000>;
+ opp-microvolt-speed0-pvs3 = <1000000 975000 1025000>;
+ opp-microvolt-speed0-pvs4 = <987500 962500 1012500>;
+ opp-microvolt-speed1-pvs0 = <1000000 1000000 1025000>;
+ opp-microvolt-speed1-pvs1 = <1000000 975000 1025000>;
+ opp-microvolt-speed1-pvs2 = <962500 937500 987500>;
+ opp-microvolt-speed1-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs4 = <912500 887500 937500>;
+ opp-microvolt-speed1-pvs5 = <912500 887500 937500>;
+ opp-microvolt-speed1-pvs6 = <912500 887500 937500>;
+ opp-microvolt-speed2-pvs0 = <962500 962500 987500>;
+ opp-microvolt-speed2-pvs1 = <937500 937500 937500>;
+ opp-microvolt-speed2-pvs2 = <937500 912500 962500>;
+ opp-microvolt-speed2-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs4 = <912500 887500 937500>;
+ opp-microvolt-speed2-pvs5 = <912500 887500 937500>;
+ opp-microvolt-speed2-pvs6 = <912500 887500 937500>;
+ opp-microvolt-speed14-pvs0 = <1000000 1000000 1025000>;
+ opp-microvolt-speed14-pvs1 = <1000000 975000 1025000>;
+ opp-microvolt-speed14-pvs2 = <962500 937500 987500>;
+ opp-microvolt-speed14-pvs3 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs4 = <912500 887500 937500>;
+ opp-microvolt-speed14-pvs5 = <887500 887500 887500>;
+ opp-microvolt-speed14-pvs6 = <912500 887500 937500>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-918000000 {
+ opp-hz = /bits/ 64 <918000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <1100000 1100000 1125000>;
+ opp-microvolt-speed0-pvs1 = <1075000 1050000 1100000>;
+ opp-microvolt-speed0-pvs3 = <1025000 1000000 1050000>;
+ opp-microvolt-speed0-pvs4 = <1000000 975000 1025000>;
+ opp-microvolt-speed1-pvs0 = <1025000 1025000 1050000>;
+ opp-microvolt-speed1-pvs1 = <1025000 1000000 1050000>;
+ opp-microvolt-speed1-pvs2 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs3 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs4 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs5 = <925000 900000 950000>;
+ opp-microvolt-speed1-pvs6 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs0 = <975000 975000 1000000>;
+ opp-microvolt-speed2-pvs1 = <950000 950000 950000>;
+ opp-microvolt-speed2-pvs2 = <950000 925000 975000>;
+ opp-microvolt-speed2-pvs3 = <937500 912500 962500>;
+ opp-microvolt-speed2-pvs4 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs5 = <925000 900000 950000>;
+ opp-microvolt-speed2-pvs6 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs0 = <1025000 1025000 1050000>;
+ opp-microvolt-speed14-pvs1 = <1025000 1000000 1050000>;
+ opp-microvolt-speed14-pvs2 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs3 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs4 = <925000 900000 950000>;
+ opp-microvolt-speed14-pvs5 = <900000 900000 900000>;
+ opp-microvolt-speed14-pvs6 = <925000 900000 950000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1026000000 {
+ opp-hz = /bits/ 64 <1026000000>;
+ opp-peak-kBps = <648000>;
+ opp-microvolt-speed0-pvs0 = <1125000 1125000 1150000>;
+ opp-microvolt-speed0-pvs1 = <1100000 1075000 1125000>;
+ opp-microvolt-speed0-pvs3 = <1050000 1025000 1075000>;
+ opp-microvolt-speed0-pvs4 = <1025000 1000000 1050000>;
+ opp-microvolt-speed1-pvs0 = <1037500 1037500 1062500>;
+ opp-microvolt-speed1-pvs1 = <1037500 1012500 1062500>;
+ opp-microvolt-speed1-pvs2 = <1000000 975000 1025000>;
+ opp-microvolt-speed1-pvs3 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs4 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs5 = <950000 925000 975000>;
+ opp-microvolt-speed1-pvs6 = <950000 925000 975000>;
+ opp-microvolt-speed2-pvs0 = <1000000 1000000 1025000>;
+ opp-microvolt-speed2-pvs1 = <975000 975000 975000>;
+ opp-microvolt-speed2-pvs2 = <975000 950000 1000000>;
+ opp-microvolt-speed2-pvs3 = <962500 937500 987500>;
+ opp-microvolt-speed2-pvs4 = <950000 925000 975000>;
+ opp-microvolt-speed2-pvs5 = <950000 925000 975000>;
+ opp-microvolt-speed2-pvs6 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs0 = <1037500 1037500 1062500>;
+ opp-microvolt-speed14-pvs1 = <1037500 1012500 1062500>;
+ opp-microvolt-speed14-pvs2 = <1000000 975000 1025000>;
+ opp-microvolt-speed14-pvs3 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs4 = <950000 925000 975000>;
+ opp-microvolt-speed14-pvs5 = <925000 925000 925000>;
+ opp-microvolt-speed14-pvs6 = <950000 925000 975000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1134000000 {
+ opp-hz = /bits/ 64 <1134000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed0-pvs0 = <1175000 1175000 1200000>;
+ opp-microvolt-speed0-pvs1 = <1150000 1125000 1175000>;
+ opp-microvolt-speed0-pvs3 = <1100000 1075000 1125000>;
+ opp-microvolt-speed0-pvs4 = <1075000 1050000 1100000>;
+ opp-microvolt-speed1-pvs0 = <1075000 1075000 1100000>;
+ opp-microvolt-speed1-pvs1 = <1062500 1037500 1087500>;
+ opp-microvolt-speed1-pvs2 = <1025000 1000000 1050000>;
+ opp-microvolt-speed1-pvs3 = <1000000 975000 1025000>;
+ opp-microvolt-speed1-pvs4 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs5 = <962500 937500 987500>;
+ opp-microvolt-speed1-pvs6 = <962500 937500 987500>;
+ opp-microvolt-speed2-pvs0 = <1025000 1025000 1050000>;
+ opp-microvolt-speed2-pvs1 = <1000000 1000000 1000000>;
+ opp-microvolt-speed2-pvs2 = <1000000 975000 1025000>;
+ opp-microvolt-speed2-pvs3 = <987500 962500 1012500>;
+ opp-microvolt-speed2-pvs4 = <975000 950000 1000000>;
+ opp-microvolt-speed2-pvs5 = <962500 937500 987500>;
+ opp-microvolt-speed2-pvs6 = <962500 937500 987500>;
+ opp-microvolt-speed14-pvs0 = <1075000 1075000 1100000>;
+ opp-microvolt-speed14-pvs1 = <1062500 1037500 1087500>;
+ opp-microvolt-speed14-pvs2 = <1025000 1000000 1050000>;
+ opp-microvolt-speed14-pvs3 = <1000000 975000 1025000>;
+ opp-microvolt-speed14-pvs4 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs5 = <937500 937500 937500>;
+ opp-microvolt-speed14-pvs6 = <962500 937500 987500>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1242000000 {
+ opp-hz = /bits/ 64 <1242000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed0-pvs0 = <1200000 1200000 1225000>;
+ opp-microvolt-speed0-pvs1 = <1175000 1150000 1200000>;
+ opp-microvolt-speed0-pvs3 = <1125000 1100000 1150000>;
+ opp-microvolt-speed0-pvs4 = <1100000 1075000 1125000>;
+ opp-microvolt-speed1-pvs0 = <1087500 1087500 1112500>;
+ opp-microvolt-speed1-pvs1 = <1075000 1050000 1100000>;
+ opp-microvolt-speed1-pvs2 = <1037500 1012500 1062500>;
+ opp-microvolt-speed1-pvs3 = <1012500 987500 1037500>;
+ opp-microvolt-speed1-pvs4 = <987500 962500 1012500>;
+ opp-microvolt-speed1-pvs5 = <975000 950000 1000000>;
+ opp-microvolt-speed1-pvs6 = <975000 950000 1000000>;
+ opp-microvolt-speed2-pvs0 = <1037500 1037500 1062500>;
+ opp-microvolt-speed2-pvs1 = <1012500 1012500 1012500>;
+ opp-microvolt-speed2-pvs2 = <1012500 987500 1037500>;
+ opp-microvolt-speed2-pvs3 = <1000000 975000 1025000>;
+ opp-microvolt-speed2-pvs4 = <987500 962500 1012500>;
+ opp-microvolt-speed2-pvs5 = <975000 950000 1000000>;
+ opp-microvolt-speed2-pvs6 = <975000 950000 1000000>;
+ opp-microvolt-speed14-pvs0 = <1087500 1087500 1112500>;
+ opp-microvolt-speed14-pvs1 = <1075000 1050000 1100000>;
+ opp-microvolt-speed14-pvs2 = <1037500 1012500 1062500>;
+ opp-microvolt-speed14-pvs3 = <1012500 987500 1037500>;
+ opp-microvolt-speed14-pvs4 = <987500 962500 1012500>;
+ opp-microvolt-speed14-pvs5 = <950000 950000 950000>;
+ opp-microvolt-speed14-pvs6 = <975000 950000 1000000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1350000000 {
+ opp-hz = /bits/ 64 <1350000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed0-pvs0 = <1225000 1225000 1250000>;
+ opp-microvolt-speed0-pvs1 = <1200000 1175000 1225000>;
+ opp-microvolt-speed0-pvs3 = <1150000 1125000 1175000>;
+ opp-microvolt-speed0-pvs4 = <1125000 1100000 1150000>;
+ opp-microvolt-speed1-pvs0 = <1125000 1125000 1150000>;
+ opp-microvolt-speed1-pvs1 = <1112500 1087500 1137500>;
+ opp-microvolt-speed1-pvs2 = <1062500 1037500 1087500>;
+ opp-microvolt-speed1-pvs3 = <1025000 1000000 1050000>;
+ opp-microvolt-speed1-pvs4 = <1000000 975000 1025000>;
+ opp-microvolt-speed1-pvs5 = <987500 962500 1012500>;
+ opp-microvolt-speed1-pvs6 = <987500 962500 1012500>;
+ opp-microvolt-speed2-pvs0 = <1062500 1062500 1087500>;
+ opp-microvolt-speed2-pvs1 = <1037500 1037500 1037500>;
+ opp-microvolt-speed2-pvs2 = <1037500 1012500 1062500>;
+ opp-microvolt-speed2-pvs3 = <1025000 1000000 1050000>;
+ opp-microvolt-speed2-pvs4 = <1000000 975000 1025000>;
+ opp-microvolt-speed2-pvs5 = <987500 962500 1012500>;
+ opp-microvolt-speed2-pvs6 = <987500 962500 1012500>;
+ opp-microvolt-speed14-pvs0 = <1125000 1125000 1150000>;
+ opp-microvolt-speed14-pvs1 = <1112500 1087500 1137500>;
+ opp-microvolt-speed14-pvs2 = <1062500 1037500 1087500>;
+ opp-microvolt-speed14-pvs3 = <1025000 1000000 1050000>;
+ opp-microvolt-speed14-pvs4 = <1000000 975000 1025000>;
+ opp-microvolt-speed14-pvs5 = <962500 962500 962500>;
+ opp-microvolt-speed14-pvs6 = <987500 962500 1012500>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1458000000 {
+ opp-hz = /bits/ 64 <1458000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed0-pvs0 = <1237500 1237500 1262500>;
+ opp-microvolt-speed0-pvs1 = <1212500 1187500 1237500>;
+ opp-microvolt-speed0-pvs3 = <1162500 1137500 1187500>;
+ opp-microvolt-speed0-pvs4 = <1137500 1112500 1162500>;
+ opp-microvolt-speed1-pvs0 = <1150000 1150000 1175000>;
+ opp-microvolt-speed1-pvs1 = <1137500 1112500 1162500>;
+ opp-microvolt-speed1-pvs2 = <1100000 1075000 1125000>;
+ opp-microvolt-speed1-pvs3 = <1062500 1037500 1087500>;
+ opp-microvolt-speed1-pvs4 = <1025000 1000000 1050000>;
+ opp-microvolt-speed1-pvs5 = <1012500 987500 1037500>;
+ opp-microvolt-speed1-pvs6 = <1000000 975000 1025000>;
+ opp-microvolt-speed2-pvs0 = <1100000 1100000 1125000>;
+ opp-microvolt-speed2-pvs1 = <1075000 1075000 1075000>;
+ opp-microvolt-speed2-pvs2 = <1075000 1050000 1100000>;
+ opp-microvolt-speed2-pvs3 = <1050000 1025000 1075000>;
+ opp-microvolt-speed2-pvs4 = <1025000 1000000 1050000>;
+ opp-microvolt-speed2-pvs5 = <1012500 987500 1037500>;
+ opp-microvolt-speed2-pvs6 = <1000000 975000 1025000>;
+ opp-microvolt-speed14-pvs0 = <1150000 1150000 1175000>;
+ opp-microvolt-speed14-pvs1 = <1137500 1112500 1162500>;
+ opp-microvolt-speed14-pvs2 = <1100000 1075000 1125000>;
+ opp-microvolt-speed14-pvs3 = <1062500 1037500 1087500>;
+ opp-microvolt-speed14-pvs4 = <1025000 1000000 1050000>;
+ opp-microvolt-speed14-pvs5 = <987500 987500 987500>;
+ opp-microvolt-speed14-pvs6 = <1000000 975000 1025000>;
+ opp-supported-hw = <0x4007>;
+ };
+
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed0-pvs0 = <1250000 1250000 1275000>;
+ opp-microvolt-speed0-pvs1 = <1225000 1200000 1250000>;
+ opp-microvolt-speed0-pvs3 = <1175000 1150000 1200000>;
+ opp-microvolt-speed0-pvs4 = <1150000 1125000 1175000>;
+ opp-microvolt-speed14-pvs0 = <1162500 1162500 1187500>;
+ opp-microvolt-speed14-pvs1 = <1150000 1125000 1175000>;
+ opp-microvolt-speed14-pvs2 = <1112500 1087500 1137500>;
+ opp-microvolt-speed14-pvs3 = <1075000 1050000 1100000>;
+ opp-microvolt-speed14-pvs4 = <1037500 1012500 1062500>;
+ opp-microvolt-speed14-pvs5 = <1000000 1000000 1000000>;
+ opp-microvolt-speed14-pvs6 = <1012500 987500 1037500>;
+ opp-supported-hw = <0x4001>;
+ };
+
+ opp-1566000000 {
+ opp-hz = /bits/ 64 <1566000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed1-pvs0 = <1175000 1175000 1200000>;
+ opp-microvolt-speed1-pvs1 = <1175000 1150000 1200000>;
+ opp-microvolt-speed1-pvs2 = <1125000 1100000 1150000>;
+ opp-microvolt-speed1-pvs3 = <1087500 1062500 1112500>;
+ opp-microvolt-speed1-pvs4 = <1062500 1037500 1087500>;
+ opp-microvolt-speed1-pvs5 = <1037500 1012500 1062500>;
+ opp-microvolt-speed1-pvs6 = <1025000 1000000 1050000>;
+ opp-microvolt-speed2-pvs0 = <1125000 1125000 1150000>;
+ opp-microvolt-speed2-pvs1 = <1100000 1100000 1100000>;
+ opp-microvolt-speed2-pvs2 = <1100000 1075000 1125000>;
+ opp-microvolt-speed2-pvs3 = <1075000 1050000 1100000>;
+ opp-microvolt-speed2-pvs4 = <1062500 1037500 1087500>;
+ opp-microvolt-speed2-pvs5 = <1037500 1012500 1062500>;
+ opp-microvolt-speed2-pvs6 = <1025000 1000000 1050000>;
+ opp-supported-hw = <0x06>;
+ };
+
+ opp-1674000000 {
+ opp-hz = /bits/ 64 <1674000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed1-pvs0 = <1225000 1225000 1250000>;
+ opp-microvolt-speed1-pvs1 = <1212500 1187500 1237500>;
+ opp-microvolt-speed1-pvs2 = <1162500 1137500 1187500>;
+ opp-microvolt-speed1-pvs3 = <1125000 1100000 1150000>;
+ opp-microvolt-speed1-pvs4 = <1100000 1075000 1125000>;
+ opp-microvolt-speed1-pvs5 = <1075000 1050000 1100000>;
+ opp-microvolt-speed1-pvs6 = <1050000 1025000 1075000>;
+ opp-microvolt-speed2-pvs0 = <1175000 1175000 1200000>;
+ opp-microvolt-speed2-pvs1 = <1137500 1137500 1137500>;
+ opp-microvolt-speed2-pvs2 = <1137500 1112500 1162500>;
+ opp-microvolt-speed2-pvs3 = <1112500 1087500 1137500>;
+ opp-microvolt-speed2-pvs4 = <1100000 1075000 1125000>;
+ opp-microvolt-speed2-pvs5 = <1075000 1050000 1100000>;
+ opp-microvolt-speed2-pvs6 = <1050000 1025000 1075000>;
+ opp-supported-hw = <0x06>;
+ };
+
+ opp-1728000000 {
+ opp-hz = /bits/ 64 <1728000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed1-pvs0 = <1250000 1250000 1275000>;
+ opp-microvolt-speed1-pvs1 = <1225000 1200000 1250000>;
+ opp-microvolt-speed1-pvs2 = <1187500 1162500 1212500>;
+ opp-microvolt-speed1-pvs3 = <1150000 1125000 1175000>;
+ opp-microvolt-speed1-pvs4 = <1125000 1100000 1150000>;
+ opp-microvolt-speed1-pvs5 = <1100000 1075000 1125000>;
+ opp-microvolt-speed1-pvs6 = <1075000 1050000 1100000>;
+ opp-supported-hw = <0x02>;
+ };
+
+ opp-1782000000 {
+ opp-hz = /bits/ 64 <1782000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed2-pvs0 = <1225000 1225000 1250000>;
+ opp-microvolt-speed2-pvs1 = <1187500 1187500 1187500>;
+ opp-microvolt-speed2-pvs2 = <1187500 1162500 1212500>;
+ opp-microvolt-speed2-pvs3 = <1162500 1137500 1187500>;
+ opp-microvolt-speed2-pvs4 = <1137500 1112500 1162500>;
+ opp-microvolt-speed2-pvs5 = <1112500 1087500 1137500>;
+ opp-microvolt-speed2-pvs6 = <1087500 1062500 1112500>;
+ opp-supported-hw = <0x04>;
+ };
+
+ opp-1890000000 {
+ opp-hz = /bits/ 64 <1890000000>;
+ opp-peak-kBps = <1134000>;
+ opp-microvolt-speed2-pvs0 = <1287500 1287500 1312500>;
+ opp-microvolt-speed2-pvs1 = <1250000 1250000 1250000>;
+ opp-microvolt-speed2-pvs2 = <1237500 1212500 1262500>;
+ opp-microvolt-speed2-pvs3 = <1200000 1175000 1225000>;
+ opp-microvolt-speed2-pvs4 = <1175000 1150000 1200000>;
+ opp-microvolt-speed2-pvs5 = <1150000 1125000 1175000>;
+ opp-microvolt-speed2-pvs6 = <1125000 1100000 1150000>;
+ opp-supported-hw = <0x04>;
+ };
+ };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x0>;
@@ -796,9 +1273,15 @@ qfprom: qfprom@700000 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ speedbin_efuse: speedbin@c0 {
+ reg = <0x0c0 0x4>;
+ };
+
tsens_calib: calib@404 {
reg = <0x404 0x10>;
};
+
tsens_backup: backup_calib@414 {
reg = <0x414 0x10>;
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 18/23] ARM: dts: qcom: apq8064: enable passive CPU cooling
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (16 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 19/23] ARM: dts: qcom: msm8960: declare SAW2 regulators Dmitry Baryshkov
` (4 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
Wire up CPUs and thermal trip points to save the SoC from overheating by
lowering the CPU frequency.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 29 ++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index f08d87bcc37e..638b2201ee0d 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -11,6 +11,7 @@
#include <dt-bindings/soc/qcom,krait-l2-cache.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -697,6 +698,13 @@ cpu_crit0: trip1 {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device = <&CPU0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
cpu1-thermal {
@@ -718,6 +726,13 @@ cpu_crit1: trip1 {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&CPU1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
cpu2-thermal {
@@ -739,6 +754,13 @@ cpu_crit2: trip1 {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert2>;
+ cooling-device = <&CPU2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
cpu3-thermal {
@@ -760,6 +782,13 @@ cpu_crit3: trip1 {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert3>;
+ cooling-device = <&CPU3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 19/23] ARM: dts: qcom: msm8960: declare SAW2 regulators
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (17 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 18/23] ARM: dts: qcom: apq8064: enable passive CPU cooling Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 20/23] ARM: dts: qcom: apq8084: drop 'regulator' property from SAW2 device Dmitry Baryshkov
` (3 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 (SPM and AVS Wrapper) among other things is yet another way to
handle CPU-related PMIC regulators. Provide a way to control voltage of
these regulators.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index f420740e068e..0ab340405784 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -223,13 +223,21 @@ acc1: clock-controller@2098000 {
saw0: regulator@2089000 {
compatible = "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw0_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
saw1: regulator@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
- regulator;
+
+ saw1_vreg: regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
gsbi5: gsbi@16400000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 20/23] ARM: dts: qcom: apq8084: drop 'regulator' property from SAW2 device
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (18 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 19/23] ARM: dts: qcom: msm8960: declare SAW2 regulators Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 21/23] ARM: dts: qcom: msm8974: " Dmitry Baryshkov
` (2 subsequent siblings)
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 device should describe the regulator constraints rather than
just declaring that it has the regulator.
Drop the 'regulator' property. If/when CPU voltage scaling is
implemented for this platform, proper regulator node show be added
instead.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-apq8084.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
index 2b1f9d0fb510..24bc2cbfbd96 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
@@ -652,7 +652,6 @@ saw3: power-controller@f90b9000 {
saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
- regulator;
};
acc0: power-manager@f9088000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 21/23] ARM: dts: qcom: msm8974: drop 'regulator' property from SAW2 device
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (19 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 20/23] ARM: dts: qcom: apq8084: drop 'regulator' property from SAW2 device Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 22/23] ARM: dts: qcom: ipq4019: drop 'regulator' property from SAW2 devices Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 23/23] ARM: dts: qcom: ipq8064: " Dmitry Baryshkov
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 device should describe the regulator constraints rather than
just declaring that it has the regulator.
Drop the 'regulator' property. If/when CPU voltage scaling is
implemented for this platform, proper regulator node show be added
instead.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index d54be72fe3b2..7d844236de0f 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -416,7 +416,6 @@ saw3: power-controller@f90b9000 {
saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
- regulator;
};
acc0: power-manager@f9088000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 22/23] ARM: dts: qcom: ipq4019: drop 'regulator' property from SAW2 devices
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (20 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 21/23] ARM: dts: qcom: msm8974: " Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 23/23] ARM: dts: qcom: ipq8064: " Dmitry Baryshkov
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 device should describe the regulator constraints rather than
just declaring that it has the regulator.
Drop the 'regulator' property. If/when CPU voltage scaling is
implemented for this platform, proper regulator nodes show be added
instead.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi b/arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi
index 9844e0b7cff9..d7bd97997ff9 100644
--- a/arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi
@@ -353,31 +353,26 @@ acc3: power-manager@b0b8000 {
saw0: regulator@b089000 {
compatible = "qcom,saw2";
reg = <0x0b089000 0x1000>, <0x0b009000 0x1000>;
- regulator;
};
saw1: regulator@b099000 {
compatible = "qcom,saw2";
reg = <0x0b099000 0x1000>, <0x0b009000 0x1000>;
- regulator;
};
saw2: regulator@b0a9000 {
compatible = "qcom,saw2";
reg = <0x0b0a9000 0x1000>, <0x0b009000 0x1000>;
- regulator;
};
saw3: regulator@b0b9000 {
compatible = "qcom,saw2";
reg = <0x0b0b9000 0x1000>, <0x0b009000 0x1000>;
- regulator;
};
saw_l2: regulator@b012000 {
compatible = "qcom,saw2";
reg = <0xb012000 0x1000>;
- regulator;
};
blsp1_uart1: serial@78af000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 23/23] ARM: dts: qcom: ipq8064: drop 'regulator' property from SAW2 devices
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
` (21 preceding siblings ...)
2023-08-27 11:50 ` [PATCH v4 22/23] ARM: dts: qcom: ipq4019: drop 'regulator' property from SAW2 devices Dmitry Baryshkov
@ 2023-08-27 11:50 ` Dmitry Baryshkov
22 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-27 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
The SAW2 device should describe the regulator constraints rather than
just declaring that it has the regulator.
Drop the 'regulator' property. If/when CPU voltage scaling is
implemented for this platform, proper regulator nodes show be added
instead.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
index c3677440b786..191d1cb27cb7 100644
--- a/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
@@ -589,7 +589,6 @@ acc0: clock-controller@2088000 {
saw0: regulator@2089000 {
compatible = "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
- regulator;
};
acc1: clock-controller@2098000 {
@@ -604,7 +603,6 @@ acc1: clock-controller@2098000 {
saw1: regulator@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
- regulator;
};
nss_common: syscon@3000000 {
--
2.39.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator
2023-08-27 11:50 ` [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator Dmitry Baryshkov
@ 2023-08-28 10:49 ` Konrad Dybcio
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Dybcio @ 2023-08-28 10:49 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> The SPM / SAW2 device also provides a voltage regulator functionality
> with optional AVS (Adaptive Voltage Scaling) support. The exact register
> sequence and voltage ranges differs from device to device.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-08-27 11:50 ` [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling Dmitry Baryshkov
@ 2023-08-28 10:49 ` Konrad Dybcio
2023-10-11 15:49 ` Rob Herring
1 sibling, 0 replies; 44+ messages in thread
From: Konrad Dybcio @ 2023-08-28 10:49 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> Add a simple driver that handles scaling of L2 frequency and voltages.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
[...]
> +MODULE_DESCRIPTION("Qualcomm Krait L2 scaling driver");
> +MODULE_LICENSE("GPL v2");
Checkpatch?
Konrad
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller
2023-08-27 11:50 ` [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller Dmitry Baryshkov
@ 2023-08-28 10:54 ` Konrad Dybcio
2023-08-28 11:38 ` Dmitry Baryshkov
0 siblings, 1 reply; 44+ messages in thread
From: Konrad Dybcio @ 2023-08-28 10:54 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> Add device node for the clock controller for the CPU cores and L2
> clocks. It will be further used by the L2 and by the CPUfreq nodes.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 26 ++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> index ba7d5ef8de17..a05e64bff07f 100644
> --- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> @@ -213,6 +213,32 @@ sleep_clk: sleep_clk {
> };
> };
>
> + kraitcc: clock-controller {
> + compatible = "qcom,krait-cc-v1";
> + clocks = <&gcc PLL9>,
> + <&gcc PLL10>,
> + <&gcc PLL16>,
> + <&gcc PLL17>,
> + <&gcc PLL12>,
> + <&acc0>,
> + <&acc1>,
> + <&acc2>,
> + <&acc3>,
> + <&l2cc>;
> + clock-names = "hfpll0",
> + "hfpll1",
> + "hfpll2",
> + "hfpll3",
> + "hfpll_l2",
> + "acpu0_aux",
> + "acpu1_aux",
> + "acpu2_aux",
> + "acpu3_aux",
> + "acpu_l2_aux";
> + #clock-cells = <1>;
> + #interconnect-cells = <1>;
Doesn't only the L2 device register with icc?
Konrad
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling
2023-08-27 11:50 ` [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling Dmitry Baryshkov
@ 2023-08-28 10:55 ` Konrad Dybcio
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Dybcio @ 2023-08-28 10:55 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> Populate L2 cache node with clock, supplies and OPP information to
> facilitate scaling L2 frequency.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support
2023-08-27 11:50 ` [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support Dmitry Baryshkov
@ 2023-08-28 10:56 ` Konrad Dybcio
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Dybcio @ 2023-08-28 10:56 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> Declare CPU frequency-scaling properties. Each CPU has its own clock,
> how all CPUs have the same OPP table. Voltage scaling is not (yet)
> enabled with this patch. It will be enabled later.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller
2023-08-28 10:54 ` Konrad Dybcio
@ 2023-08-28 11:38 ` Dmitry Baryshkov
0 siblings, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-28 11:38 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Ilia Lin, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Michael Turquette, Rafael J. Wysocki, Georgi Djakov,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Mon, 28 Aug 2023 at 13:54, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>
> On 27.08.2023 13:50, Dmitry Baryshkov wrote:
> > Add device node for the clock controller for the CPU cores and L2
> > clocks. It will be further used by the L2 and by the CPUfreq nodes.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 26 ++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> > index ba7d5ef8de17..a05e64bff07f 100644
> > --- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> > +++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> > @@ -213,6 +213,32 @@ sleep_clk: sleep_clk {
> > };
> > };
> >
> > + kraitcc: clock-controller {
> > + compatible = "qcom,krait-cc-v1";
> > + clocks = <&gcc PLL9>,
> > + <&gcc PLL10>,
> > + <&gcc PLL16>,
> > + <&gcc PLL17>,
> > + <&gcc PLL12>,
> > + <&acc0>,
> > + <&acc1>,
> > + <&acc2>,
> > + <&acc3>,
> > + <&l2cc>;
> > + clock-names = "hfpll0",
> > + "hfpll1",
> > + "hfpll2",
> > + "hfpll3",
> > + "hfpll_l2",
> > + "acpu0_aux",
> > + "acpu1_aux",
> > + "acpu2_aux",
> > + "acpu3_aux",
> > + "acpu_l2_aux";
> > + #clock-cells = <1>;
> > + #interconnect-cells = <1>;
> Doesn't only the L2 device register with icc?
True. I'll drop this
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms
2023-08-27 11:50 ` [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms Dmitry Baryshkov
@ 2023-08-28 15:33 ` Rob Herring
0 siblings, 0 replies; 44+ messages in thread
From: Rob Herring @ 2023-08-28 15:33 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Krzysztof Kozlowski, Conor Dooley, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Ilia Lin, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Michael Turquette, Rafael J. Wysocki, Georgi Djakov,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Sun, Aug 27, 2023 at 02:50:14PM +0300, Dmitry Baryshkov wrote:
> The L2 cache device on Qualcomm Krait platforms controls the supplying
> voltages and the cache frequency. Add corresponding bindings for this
> device.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> .../bindings/cache/qcom,krait-l2-cache.yaml | 86 +++++++++++++++++++
> include/dt-bindings/soc/qcom,krait-l2-cache.h | 12 +++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
> create mode 100644 include/dt-bindings/soc/qcom,krait-l2-cache.h
>
> diff --git a/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml b/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
> new file mode 100644
> index 000000000000..59ce11dd0a24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cache/qcom,krait-l2-cache.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
'only', not 'or-later'
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cache/qcom,krait-l2-cache.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Krait L2 Cache
> +
> +maintainers:
> + - Bjorn Andersson <andersson@kernel.org>
> +
> +description:
> + L2 cache on Qualcomm Krait platforms is shared between all CPU cores. L2
> + cache frequency and voltages should be scaled according to the needs of the
> + cores.
> +
> +allOf:
> + - $ref: /schemas/cache-controller.yaml#
> +
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,krait-l2-cache
> +
> + required:
> + - compatible
> +
> +properties:
> + compatible:
> + items:
> + - const: qcom,krait-l2-cache
> + - const: cache
> +
> + clocks:
> + maxItems: 1
> +
> + '#interconnect-cells':
> + const: 1
> +
> + vdd-mem-supply:
> + description: suppling regulator for the memory cells of the cache
> +
> + vdd-dig-supply:
> + description: suppling regulator for the digital logic of the cache
> +
> + operating-points-v2: true
> + opp-table:
> + type: object
> +
> +required:
> + - compatible
> + - cache-level
> + - cache-unified
> + - clocks
> + - '#interconnect-cells'
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/soc/qcom,krait-l2-cache.h>
> +
> + l2-cache {
> + compatible = "qcom,krait-l2-cache", "cache";
> + cache-level = <2>;
> + cache-unified;
> + vdd-mem-supply = <&pm8921_l24>;
> + vdd-dig-supply = <&pm8921_s3>;
> + clocks = <&kraitcc 4>;
> + #interconnect-cells = <1>;
> + operating-points-v2 = <&l2_opp_table>;
> +
> + l2_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-384000000 {
> + opp-hz = /bits/ 64 <384000000>;
> + opp-microvolt = <1050000 1050000 1150000>,
> + <950000 950000 1150000>;
> + };
> + };
> + };
> +...
> +
> diff --git a/include/dt-bindings/soc/qcom,krait-l2-cache.h b/include/dt-bindings/soc/qcom,krait-l2-cache.h
> new file mode 100644
> index 000000000000..c9a38d368111
> --- /dev/null
> +++ b/include/dt-bindings/soc/qcom,krait-l2-cache.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (C) 2023 Linaro Ltd. All rights reserved.
> + */
> +
> +#ifndef __DT_BINDINGS_SOC_QCOM_KRAIT_L2_CACHE_H
> +#define __DT_BINDINGS_SOC_QCOM_KRAIT_L2_CACHE_H
> +
> +#define MASTER_KRAIT_L2 0
> +#define SLAVE_KRAIT_L2 1
> +
> +#endif
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
[not found] ` <493aff10d698c9ca5bdbeae45250f5fe.sboyd@kernel.org>
@ 2023-08-28 21:18 ` Dmitry Baryshkov
2023-10-03 8:30 ` Dmitry Baryshkov
1 sibling, 0 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-08-28 21:18 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andy Gross, Bjorn Andersson, Conor Dooley, Georgi Djakov,
Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski, Michael Turquette,
Nishanth Menon, Rafael J. Wysocki, Rob Herring, Viresh Kumar,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Mon, 28 Aug 2023 at 21:10, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > index d787f2ea36d9..45ffb068979d 100644
> > --- a/drivers/interconnect/icc-clk.c
> > +++ b/drivers/interconnect/icc-clk.c
> > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > {
> > struct icc_clk_node *qn = src->data;
> > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > int ret;
> >
> > if (!qn || !qn->clk)
> > return 0;
> >
> > - if (!src->peak_bw) {
> > + if (qn->opp)
> > + return dev_pm_opp_set_rate(qn->dev, rate);
>
> Just curious how does lockdep do with this? Doesn't OPP call into
> interconnect code, so lockdep will complain about ABBA?
Interesting question. I should check it.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
[not found] ` <493aff10d698c9ca5bdbeae45250f5fe.sboyd@kernel.org>
2023-08-28 21:18 ` Dmitry Baryshkov
@ 2023-10-03 8:30 ` Dmitry Baryshkov
2023-10-03 13:01 ` Stephan Gerhold
1 sibling, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-10-03 8:30 UTC (permalink / raw)
To: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar
Cc: linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On 28/08/2023 21:09, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
>> diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
>> index d787f2ea36d9..45ffb068979d 100644
>> --- a/drivers/interconnect/icc-clk.c
>> +++ b/drivers/interconnect/icc-clk.c
>> @@ -25,12 +28,16 @@ struct icc_clk_provider {
>> static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
>> {
>> struct icc_clk_node *qn = src->data;
>> + unsigned long rate = icc_units_to_bps(src->peak_bw);
>> int ret;
>>
>> if (!qn || !qn->clk)
>> return 0;
>>
>> - if (!src->peak_bw) {
>> + if (qn->opp)
>> + return dev_pm_opp_set_rate(qn->dev, rate);
>
> Just curious how does lockdep do with this? Doesn't OPP call into
> interconnect code, so lockdep will complain about ABBA?
Unfortunately it does. It seems, the icc-clk is not a proper way to go
here. I will take a look at reusing set_required_opps for this case.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 8:30 ` Dmitry Baryshkov
@ 2023-10-03 13:01 ` Stephan Gerhold
2023-10-03 13:36 ` Dmitry Baryshkov
0 siblings, 1 reply; 44+ messages in thread
From: Stephan Gerhold @ 2023-10-03 13:01 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar, linux-arm-msm, devicetree, linux-pm, linux-clk,
Christian Marangi
On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> On 28/08/2023 21:09, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > index d787f2ea36d9..45ffb068979d 100644
> > > --- a/drivers/interconnect/icc-clk.c
> > > +++ b/drivers/interconnect/icc-clk.c
> > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > {
> > > struct icc_clk_node *qn = src->data;
> > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > int ret;
> > > if (!qn || !qn->clk)
> > > return 0;
> > > - if (!src->peak_bw) {
> > > + if (qn->opp)
> > > + return dev_pm_opp_set_rate(qn->dev, rate);
> >
> > Just curious how does lockdep do with this? Doesn't OPP call into
> > interconnect code, so lockdep will complain about ABBA?
>
> Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> I will take a look at reusing set_required_opps for this case.
>
Could you elaborate a bit which locks exactly cause trouble here?
I'm probably missing something here.
From a quick look at the OPP code I don't see a global lock taken there
for the entire OPP switch sequence, so I'm not sure how this could cause
an ABBA deadlock.
Thanks,
Stephan
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 13:01 ` Stephan Gerhold
@ 2023-10-03 13:36 ` Dmitry Baryshkov
2023-10-03 14:17 ` Stephan Gerhold
0 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-10-03 13:36 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar, linux-arm-msm, devicetree, linux-pm, linux-clk,
Christian Marangi
On Tue, 3 Oct 2023 at 16:02, Stephan Gerhold <stephan@gerhold.net> wrote:
>
> On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> > On 28/08/2023 21:09, Stephen Boyd wrote:
> > > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > > index d787f2ea36d9..45ffb068979d 100644
> > > > --- a/drivers/interconnect/icc-clk.c
> > > > +++ b/drivers/interconnect/icc-clk.c
> > > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > > {
> > > > struct icc_clk_node *qn = src->data;
> > > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > > int ret;
> > > > if (!qn || !qn->clk)
> > > > return 0;
> > > > - if (!src->peak_bw) {
> > > > + if (qn->opp)
> > > > + return dev_pm_opp_set_rate(qn->dev, rate);
> > >
> > > Just curious how does lockdep do with this? Doesn't OPP call into
> > > interconnect code, so lockdep will complain about ABBA?
> >
> > Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> > I will take a look at reusing set_required_opps for this case.
> >
>
> Could you elaborate a bit which locks exactly cause trouble here?
> I'm probably missing something here.
>
> From a quick look at the OPP code I don't see a global lock taken there
> for the entire OPP switch sequence, so I'm not sure how this could cause
> an ABBA deadlock.
For example:
[ 7.680041] Chain exists of:
[ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
[ 7.680041]
[ 7.687955] Possible unsafe locking scenario:
[ 7.687955]
[ 7.699039] CPU0 CPU1
[ 7.704752] ---- ----
[ 7.709266] lock(fs_reclaim);
[ 7.713779] lock(regulator_ww_class_acquire);
[ 7.716919] lock(fs_reclaim);
[ 7.724204] lock(icc_bw_lock);
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 13:36 ` Dmitry Baryshkov
@ 2023-10-03 14:17 ` Stephan Gerhold
2023-10-03 15:31 ` Dmitry Baryshkov
0 siblings, 1 reply; 44+ messages in thread
From: Stephan Gerhold @ 2023-10-03 14:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar, linux-arm-msm, devicetree, linux-pm, linux-clk,
Christian Marangi
On Tue, Oct 03, 2023 at 04:36:11PM +0300, Dmitry Baryshkov wrote:
> On Tue, 3 Oct 2023 at 16:02, Stephan Gerhold <stephan@gerhold.net> wrote:
> >
> > On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> > > On 28/08/2023 21:09, Stephen Boyd wrote:
> > > > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > > > index d787f2ea36d9..45ffb068979d 100644
> > > > > --- a/drivers/interconnect/icc-clk.c
> > > > > +++ b/drivers/interconnect/icc-clk.c
> > > > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > > > {
> > > > > struct icc_clk_node *qn = src->data;
> > > > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > > > int ret;
> > > > > if (!qn || !qn->clk)
> > > > > return 0;
> > > > > - if (!src->peak_bw) {
> > > > > + if (qn->opp)
> > > > > + return dev_pm_opp_set_rate(qn->dev, rate);
> > > >
> > > > Just curious how does lockdep do with this? Doesn't OPP call into
> > > > interconnect code, so lockdep will complain about ABBA?
> > >
> > > Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> > > I will take a look at reusing set_required_opps for this case.
> > >
> >
> > Could you elaborate a bit which locks exactly cause trouble here?
> > I'm probably missing something here.
> >
> > From a quick look at the OPP code I don't see a global lock taken there
> > for the entire OPP switch sequence, so I'm not sure how this could cause
> > an ABBA deadlock.
>
> For example:
>
> [ 7.680041] Chain exists of:
> [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> [ 7.680041]
> [ 7.687955] Possible unsafe locking scenario:
> [ 7.687955]
> [ 7.699039] CPU0 CPU1
> [ 7.704752] ---- ----
> [ 7.709266] lock(fs_reclaim);
> [ 7.713779] lock(regulator_ww_class_acquire);
> [ 7.716919] lock(fs_reclaim);
> [ 7.724204] lock(icc_bw_lock);
>
Hm, I'm not entirely sure how to interpret this. Is there really a
connection between OPP and ICC here? It looks more like ICC <->
regulator and somehow related to memory allocations (the fs_reclaim).
Was there more output around this?
In general, I would expect that adjusting a regulator from an
interconnect driver should be made possible somehow. Just because the
RPM firmware or similar typically handles this internally on Qualcomm
platforms doesn't mean no one else will ever need to do this. If you
have a higher bandwidth requests, need to increase the clock, which
again depends on a higher voltage, then you need to be able to do the
regulator_set_voltage() from the ICC driver somehow.
Thanks,
Stephan
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 14:17 ` Stephan Gerhold
@ 2023-10-03 15:31 ` Dmitry Baryshkov
2023-10-03 16:04 ` Stephan Gerhold
2023-10-10 4:14 ` Stephen Boyd
0 siblings, 2 replies; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-10-03 15:31 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar, linux-arm-msm, devicetree, linux-pm, linux-clk,
Christian Marangi
On Tue, 3 Oct 2023 at 17:17, Stephan Gerhold <stephan@gerhold.net> wrote:
>
> On Tue, Oct 03, 2023 at 04:36:11PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 3 Oct 2023 at 16:02, Stephan Gerhold <stephan@gerhold.net> wrote:
> > >
> > > On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> > > > On 28/08/2023 21:09, Stephen Boyd wrote:
> > > > > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > > > > index d787f2ea36d9..45ffb068979d 100644
> > > > > > --- a/drivers/interconnect/icc-clk.c
> > > > > > +++ b/drivers/interconnect/icc-clk.c
> > > > > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > > > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > > > > {
> > > > > > struct icc_clk_node *qn = src->data;
> > > > > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > > > > int ret;
> > > > > > if (!qn || !qn->clk)
> > > > > > return 0;
> > > > > > - if (!src->peak_bw) {
> > > > > > + if (qn->opp)
> > > > > > + return dev_pm_opp_set_rate(qn->dev, rate);
> > > > >
> > > > > Just curious how does lockdep do with this? Doesn't OPP call into
> > > > > interconnect code, so lockdep will complain about ABBA?
> > > >
> > > > Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> > > > I will take a look at reusing set_required_opps for this case.
> > > >
> > >
> > > Could you elaborate a bit which locks exactly cause trouble here?
> > > I'm probably missing something here.
> > >
> > > From a quick look at the OPP code I don't see a global lock taken there
> > > for the entire OPP switch sequence, so I'm not sure how this could cause
> > > an ABBA deadlock.
> >
> > For example:
> >
> > [ 7.680041] Chain exists of:
> > [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> > [ 7.680041]
> > [ 7.687955] Possible unsafe locking scenario:
> > [ 7.687955]
> > [ 7.699039] CPU0 CPU1
> > [ 7.704752] ---- ----
> > [ 7.709266] lock(fs_reclaim);
> > [ 7.713779] lock(regulator_ww_class_acquire);
> > [ 7.716919] lock(fs_reclaim);
> > [ 7.724204] lock(icc_bw_lock);
> >
>
> Hm, I'm not entirely sure how to interpret this. Is there really a
> connection between OPP and ICC here? It looks more like ICC <->
> regulator and somehow related to memory allocations (the fs_reclaim).
>
> Was there more output around this?
[ 7.362902] ======================================================
[ 7.363447] WARNING: possible circular locking dependency detected
[ 7.369434] 6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129 Not tainted
[ 7.375604] ------------------------------------------------------
[ 7.382453] swapper/0/1 is trying to acquire lock:
[ 7.388437] c143445c (icc_bw_lock){+.+.}-{3:3}, at: icc_init+0x0/0x104
[ 7.393225]
[ 7.393225] but task is already holding lock:
[ 7.399730] c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
[ 7.405547]
[ 7.405547] which lock already depends on the new lock.
[ 7.405547]
[ 7.412077]
[ 7.412077] the existing dependency chain (in reverse order) is:
[ 7.420310]
[ 7.420310] -> #2 (fs_reclaim){+.+.}-{0:0}:
[ 7.427767] fs_reclaim_acquire+0x60/0x94
[ 7.433492] __kmem_cache_alloc_node+0x30/0x2b4
[ 7.437742] __kmalloc_node_track_caller+0x48/0x244
[ 7.442954] kstrdup+0x30/0x58
[ 7.448325] create_regulator+0x70/0x2b8
[ 7.451981] regulator_resolve_supply+0x3bc/0x7f4
[ 7.456234] regulator_register+0x9b0/0xb50
[ 7.461352] devm_regulator_register+0x50/0x8c
[ 7.466216] rpm_reg_probe+0xf4/0x1a0
[ 7.471244] platform_probe+0x5c/0xb0
[ 7.475157] really_probe+0xc8/0x2d8
[ 7.479318] __driver_probe_device+0x88/0x1a0
[ 7.483488] driver_probe_device+0x30/0x108
[ 7.488262] __driver_attach_async_helper+0x4c/0xa0
[ 7.493133] async_run_entry_fn+0x24/0xb0
[ 7.498504] process_one_work+0x208/0x5e4
[ 7.502844] worker_thread+0x1e0/0x4a4
[ 7.507356] kthread+0x100/0x120
[ 7.511874] ret_from_fork+0x14/0x28
[ 7.515428]
[ 7.515428] -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
[ 7.519528] lock_release+0x164/0x340
[ 7.526713] __mutex_unlock_slowpath+0x3c/0x2fc
[ 7.530626] regulator_lock_dependent+0x1a4/0x298
[ 7.535839] regulator_set_voltage+0x30/0xfc
[ 7.540866] krait_l2_set_one_supply+0x28/0x84
[ 7.545729] krait_l2_config_regulators+0x90/0x1c4
[ 7.550851] _set_opp+0xf0/0x438
[ 7.556144] dev_pm_opp_set_rate+0x118/0x224
[ 7.559703] icc_node_add+0xe8/0x15c
[ 7.564474] icc_clk_register+0x150/0x208
[ 7.568556] krait_l2_probe+0x100/0x114
[ 7.572988] platform_probe+0x5c/0xb0
[ 7.577495] really_probe+0xc8/0x2d8
[ 7.581487] __driver_probe_device+0x88/0x1a0
[ 7.585658] driver_probe_device+0x30/0x108
[ 7.590433] __device_attach_driver+0x94/0x10c
[ 7.595300] bus_for_each_drv+0x84/0xd8
[ 7.600326] __device_attach+0xac/0x1a8
[ 7.604580] bus_probe_device+0x8c/0x90
[ 7.608919] device_add+0x5c8/0x7a4
[ 7.613265] of_platform_device_create_pdata+0x90/0xbc
[ 7.617260] qcom_cpufreq_init+0xa8/0x130
[ 7.622984] do_one_initcall+0x68/0x2d8
[ 7.627235] kernel_init_freeable+0x1ac/0x208
[ 7.631752] kernel_init+0x18/0x12c
[ 7.636441] ret_from_fork+0x14/0x28
[ 7.640602]
[ 7.640602] -> #0 (icc_bw_lock){+.+.}-{3:3}:
[ 7.644607] __lock_acquire+0x1530/0x28fc
[ 7.650413] lock_acquire+0x10c/0x33c
[ 7.654757] icc_init+0x40/0x104
[ 7.658917] do_one_initcall+0x68/0x2d8
[ 7.662740] kernel_init_freeable+0x1ac/0x208
[ 7.667168] kernel_init+0x18/0x12c
[ 7.671855] ret_from_fork+0x14/0x28
[ 7.676018]
[ 7.676018] other info that might help us debug this:
[ 7.676018]
[ 7.680041] Chain exists of:
[ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
[ 7.680041]
[ 7.687955] Possible unsafe locking scenario:
[ 7.687955]
[ 7.699039] CPU0 CPU1
[ 7.704752] ---- ----
[ 7.709266] lock(fs_reclaim);
[ 7.713779] lock(regulator_ww_class_acquire);
[ 7.716919] lock(fs_reclaim);
[ 7.724204] lock(icc_bw_lock);
[ 7.729833]
[ 7.729833] *** DEADLOCK ***
[ 7.729833]
[ 7.733071] 1 lock held by swapper/0/1:
[ 7.738691] #0: c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
[ 7.742528]
[ 7.742528] stack backtrace:
[ 7.749463] CPU: 3 PID: 1 Comm: swapper/0 Not tainted
6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129
[ 7.754010] Hardware name: Generic DT based system
[ 7.763183] unwind_backtrace from show_stack+0x10/0x14
[ 7.767957] show_stack from dump_stack_lvl+0x60/0x90
[ 7.773082] dump_stack_lvl from check_noncircular+0x174/0x18c
[ 7.778288] check_noncircular from __lock_acquire+0x1530/0x28fc
[ 7.784018] __lock_acquire from lock_acquire+0x10c/0x33c
[ 7.790178] lock_acquire from icc_init+0x40/0x104
[ 7.795475] icc_init from do_one_initcall+0x68/0x2d8
[ 7.800159] do_one_initcall from kernel_init_freeable+0x1ac/0x208
[ 7.805286] kernel_init_freeable from kernel_init+0x18/0x12c
[ 7.811361] kernel_init from ret_from_fork+0x14/0x28
[ 7.817177] Exception stack(0xf081dfb0 to 0xf081dff8)
> In general, I would expect that adjusting a regulator from an
> interconnect driver should be made possible somehow. Just because the
> RPM firmware or similar typically handles this internally on Qualcomm
> platforms doesn't mean no one else will ever need to do this. If you
> have a higher bandwidth requests, need to increase the clock, which
> again depends on a higher voltage, then you need to be able to do the
> regulator_set_voltage() from the ICC driver somehow.
This kind of dependency is handled by the consumer, not by the ICC
driver. Usually we explicitly put them to the opp tables, matching
rates and volage.
I think I'll still check the required-opps approach. It will require
manually aggregating the L2 rate requirements, but then we will be
safe from such kinds of interdependencies. And maybe then we can also
rewrite msm8996 to use required-opps too.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 15:31 ` Dmitry Baryshkov
@ 2023-10-03 16:04 ` Stephan Gerhold
2023-10-10 4:14 ` Stephen Boyd
1 sibling, 0 replies; 44+ messages in thread
From: Stephan Gerhold @ 2023-10-03 16:04 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Andy Gross, Bjorn Andersson, Conor Dooley,
Georgi Djakov, Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski,
Michael Turquette, Nishanth Menon, Rafael J. Wysocki, Rob Herring,
Viresh Kumar, linux-arm-msm, devicetree, linux-pm, linux-clk,
Christian Marangi
On Tue, Oct 03, 2023 at 06:31:27PM +0300, Dmitry Baryshkov wrote:
> On Tue, 3 Oct 2023 at 17:17, Stephan Gerhold <stephan@gerhold.net> wrote:
> > On Tue, Oct 03, 2023 at 04:36:11PM +0300, Dmitry Baryshkov wrote:
> > > On Tue, 3 Oct 2023 at 16:02, Stephan Gerhold <stephan@gerhold.net> wrote:
> > > > On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> > > > > On 28/08/2023 21:09, Stephen Boyd wrote:
> > > > > > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > > > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > > > > > index d787f2ea36d9..45ffb068979d 100644
> > > > > > > --- a/drivers/interconnect/icc-clk.c
> > > > > > > +++ b/drivers/interconnect/icc-clk.c
> > > > > > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > > > > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > > > > > {
> > > > > > > struct icc_clk_node *qn = src->data;
> > > > > > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > > > > > int ret;
> > > > > > > if (!qn || !qn->clk)
> > > > > > > return 0;
> > > > > > > - if (!src->peak_bw) {
> > > > > > > + if (qn->opp)
> > > > > > > + return dev_pm_opp_set_rate(qn->dev, rate);
> > > > > >
> > > > > > Just curious how does lockdep do with this? Doesn't OPP call into
> > > > > > interconnect code, so lockdep will complain about ABBA?
> > > > >
> > > > > Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> > > > > I will take a look at reusing set_required_opps for this case.
> > > > >
> > > >
> > > > Could you elaborate a bit which locks exactly cause trouble here?
> > > > I'm probably missing something here.
> > > >
> > > > From a quick look at the OPP code I don't see a global lock taken there
> > > > for the entire OPP switch sequence, so I'm not sure how this could cause
> > > > an ABBA deadlock.
> > >
> > > For example:
> > >
> > > [ 7.680041] Chain exists of:
> > > [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> > > [ 7.680041]
> > > [ 7.687955] Possible unsafe locking scenario:
> > > [ 7.687955]
> > > [ 7.699039] CPU0 CPU1
> > > [ 7.704752] ---- ----
> > > [ 7.709266] lock(fs_reclaim);
> > > [ 7.713779] lock(regulator_ww_class_acquire);
> > > [ 7.716919] lock(fs_reclaim);
> > > [ 7.724204] lock(icc_bw_lock);
> > >
> >
> > Hm, I'm not entirely sure how to interpret this. Is there really a
> > connection between OPP and ICC here? It looks more like ICC <->
> > regulator and somehow related to memory allocations (the fs_reclaim).
> >
> > Was there more output around this?
>
> [ 7.362902] ======================================================
> [ 7.363447] WARNING: possible circular locking dependency detected
> [ 7.369434] 6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129 Not tainted
> [ 7.375604] ------------------------------------------------------
> [ 7.382453] swapper/0/1 is trying to acquire lock:
> [ 7.388437] c143445c (icc_bw_lock){+.+.}-{3:3}, at: icc_init+0x0/0x104
> [ 7.393225]
> [ 7.393225] but task is already holding lock:
> [ 7.399730] c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
> [ 7.405547]
> [ 7.405547] which lock already depends on the new lock.
> [ 7.405547]
> [ 7.412077]
> [ 7.412077] the existing dependency chain (in reverse order) is:
> [ 7.420310]
> [ 7.420310] -> #2 (fs_reclaim){+.+.}-{0:0}:
> [ 7.427767] fs_reclaim_acquire+0x60/0x94
> [ 7.433492] __kmem_cache_alloc_node+0x30/0x2b4
> [ 7.437742] __kmalloc_node_track_caller+0x48/0x244
> [ 7.442954] kstrdup+0x30/0x58
> [ 7.448325] create_regulator+0x70/0x2b8
> [ 7.451981] regulator_resolve_supply+0x3bc/0x7f4
> [ 7.456234] regulator_register+0x9b0/0xb50
> [ 7.461352] devm_regulator_register+0x50/0x8c
> [ 7.466216] rpm_reg_probe+0xf4/0x1a0
> [ 7.471244] platform_probe+0x5c/0xb0
> [ 7.475157] really_probe+0xc8/0x2d8
> [ 7.479318] __driver_probe_device+0x88/0x1a0
> [ 7.483488] driver_probe_device+0x30/0x108
> [ 7.488262] __driver_attach_async_helper+0x4c/0xa0
> [ 7.493133] async_run_entry_fn+0x24/0xb0
> [ 7.498504] process_one_work+0x208/0x5e4
> [ 7.502844] worker_thread+0x1e0/0x4a4
> [ 7.507356] kthread+0x100/0x120
> [ 7.511874] ret_from_fork+0x14/0x28
> [ 7.515428]
> [ 7.515428] -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
> [ 7.519528] lock_release+0x164/0x340
> [ 7.526713] __mutex_unlock_slowpath+0x3c/0x2fc
> [ 7.530626] regulator_lock_dependent+0x1a4/0x298
> [ 7.535839] regulator_set_voltage+0x30/0xfc
> [ 7.540866] krait_l2_set_one_supply+0x28/0x84
> [ 7.545729] krait_l2_config_regulators+0x90/0x1c4
> [ 7.550851] _set_opp+0xf0/0x438
> [ 7.556144] dev_pm_opp_set_rate+0x118/0x224
> [ 7.559703] icc_node_add+0xe8/0x15c
> [ 7.564474] icc_clk_register+0x150/0x208
> [ 7.568556] krait_l2_probe+0x100/0x114
> [ 7.572988] platform_probe+0x5c/0xb0
> [ 7.577495] really_probe+0xc8/0x2d8
> [ 7.581487] __driver_probe_device+0x88/0x1a0
> [ 7.585658] driver_probe_device+0x30/0x108
> [ 7.590433] __device_attach_driver+0x94/0x10c
> [ 7.595300] bus_for_each_drv+0x84/0xd8
> [ 7.600326] __device_attach+0xac/0x1a8
> [ 7.604580] bus_probe_device+0x8c/0x90
> [ 7.608919] device_add+0x5c8/0x7a4
> [ 7.613265] of_platform_device_create_pdata+0x90/0xbc
> [ 7.617260] qcom_cpufreq_init+0xa8/0x130
> [ 7.622984] do_one_initcall+0x68/0x2d8
> [ 7.627235] kernel_init_freeable+0x1ac/0x208
> [ 7.631752] kernel_init+0x18/0x12c
> [ 7.636441] ret_from_fork+0x14/0x28
> [ 7.640602]
> [ 7.640602] -> #0 (icc_bw_lock){+.+.}-{3:3}:
> [ 7.644607] __lock_acquire+0x1530/0x28fc
> [ 7.650413] lock_acquire+0x10c/0x33c
> [ 7.654757] icc_init+0x40/0x104
> [ 7.658917] do_one_initcall+0x68/0x2d8
> [ 7.662740] kernel_init_freeable+0x1ac/0x208
> [ 7.667168] kernel_init+0x18/0x12c
> [ 7.671855] ret_from_fork+0x14/0x28
> [ 7.676018]
> [ 7.676018] other info that might help us debug this:
> [ 7.676018]
> [ 7.680041] Chain exists of:
> [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> [ 7.680041]
> [ 7.687955] Possible unsafe locking scenario:
> [ 7.687955]
> [ 7.699039] CPU0 CPU1
> [ 7.704752] ---- ----
> [ 7.709266] lock(fs_reclaim);
> [ 7.713779] lock(regulator_ww_class_acquire);
> [ 7.716919] lock(fs_reclaim);
> [ 7.724204] lock(icc_bw_lock);
> [ 7.729833]
> [ 7.729833] *** DEADLOCK ***
> [ 7.729833]
> [ 7.733071] 1 lock held by swapper/0/1:
> [ 7.738691] #0: c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
> [ 7.742528]
> [ 7.742528] stack backtrace:
> [ 7.749463] CPU: 3 PID: 1 Comm: swapper/0 Not tainted
> 6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129
> [ 7.754010] Hardware name: Generic DT based system
> [ 7.763183] unwind_backtrace from show_stack+0x10/0x14
> [ 7.767957] show_stack from dump_stack_lvl+0x60/0x90
> [ 7.773082] dump_stack_lvl from check_noncircular+0x174/0x18c
> [ 7.778288] check_noncircular from __lock_acquire+0x1530/0x28fc
> [ 7.784018] __lock_acquire from lock_acquire+0x10c/0x33c
> [ 7.790178] lock_acquire from icc_init+0x40/0x104
> [ 7.795475] icc_init from do_one_initcall+0x68/0x2d8
> [ 7.800159] do_one_initcall from kernel_init_freeable+0x1ac/0x208
> [ 7.805286] kernel_init_freeable from kernel_init+0x18/0x12c
> [ 7.811361] kernel_init from ret_from_fork+0x14/0x28
> [ 7.817177] Exception stack(0xf081dfb0 to 0xf081dff8)
>
Thanks! I assume you haven't noticed an actual deadlock (i.e. cpufreq
not progressing) without lockdep?
FWIW I'm not fully convinced that this deadlock can actually happen in
practice for your particular limited use case (i.e. that it is not a
false positive).
> > In general, I would expect that adjusting a regulator from an
> > interconnect driver should be made possible somehow. Just because the
> > RPM firmware or similar typically handles this internally on Qualcomm
> > platforms doesn't mean no one else will ever need to do this. If you
> > have a higher bandwidth requests, need to increase the clock, which
> > again depends on a higher voltage, then you need to be able to do the
> > regulator_set_voltage() from the ICC driver somehow.
>
> This kind of dependency is handled by the consumer, not by the ICC
> driver. Usually we explicitly put them to the opp tables, matching
> rates and volage.
>
Right, but I'm talking about the voltage requirements of the aggregated
bus clock. The rate for that is calculated from the different bandwidth
requirements from all the consumers and not just a single one. From the
kernel perspective, the interconnect driver is the consumer of that
clock. On Qualcomm SMD RPM platforms the voltage adjustment for those is
handled behind the scenes by the RPM firmware (no idea about RPMH and
RPM-old).
But one could easily think of a (non-Qualcomm) SoC without RPM, where
the interconnect driver calculates a particular bus rate for multiple
consumers and then needs to vote for a power domain or regulator to be
able to generate that clock safely.
> I think I'll still check the required-opps approach. It will require
> manually aggregating the L2 rate requirements, but then we will be
> safe from such kinds of interdependencies. And maybe then we can also
> rewrite msm8996 to use required-opps too.
>
Sure, thanks! I think at the moment the required-opps implementation is
somewhat entangled with power domains/genpd but perhaps it's easy enough
to refactor that to be more general.
Thanks,
Stephan
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP
2023-10-03 15:31 ` Dmitry Baryshkov
2023-10-03 16:04 ` Stephan Gerhold
@ 2023-10-10 4:14 ` Stephen Boyd
1 sibling, 0 replies; 44+ messages in thread
From: Stephen Boyd @ 2023-10-10 4:14 UTC (permalink / raw)
To: Dmitry Baryshkov, Stephan Gerhold
Cc: Andy Gross, Bjorn Andersson, Conor Dooley, Georgi Djakov,
Ilia Lin, Konrad Dybcio, Krzysztof Kozlowski, Michael Turquette,
Nishanth Menon, Rafael J. Wysocki, Rob Herring, Viresh Kumar,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Douglas Anderson
Quoting Dmitry Baryshkov (2023-10-03 08:31:27)
> On Tue, 3 Oct 2023 at 17:17, Stephan Gerhold <stephan@gerhold.net> wrote:
> >
> > On Tue, Oct 03, 2023 at 04:36:11PM +0300, Dmitry Baryshkov wrote:
> > > On Tue, 3 Oct 2023 at 16:02, Stephan Gerhold <stephan@gerhold.net> wrote:
> > > >
> > > > On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> > > > > On 28/08/2023 21:09, Stephen Boyd wrote:
> > > > > > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > > > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > > > > > index d787f2ea36d9..45ffb068979d 100644
> > > > > > > --- a/drivers/interconnect/icc-clk.c
> > > > > > > +++ b/drivers/interconnect/icc-clk.c
> > > > > > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > > > > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > > > > > {
> > > > > > > struct icc_clk_node *qn = src->data;
> > > > > > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > > > > > int ret;
> > > > > > > if (!qn || !qn->clk)
> > > > > > > return 0;
> > > > > > > - if (!src->peak_bw) {
> > > > > > > + if (qn->opp)
> > > > > > > + return dev_pm_opp_set_rate(qn->dev, rate);
> > > > > >
> > > > > > Just curious how does lockdep do with this? Doesn't OPP call into
> > > > > > interconnect code, so lockdep will complain about ABBA?
> > > > >
> > > > > Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> > > > > I will take a look at reusing set_required_opps for this case.
> > > > >
> > > >
> > > > Could you elaborate a bit which locks exactly cause trouble here?
> > > > I'm probably missing something here.
> > > >
> > > > From a quick look at the OPP code I don't see a global lock taken there
> > > > for the entire OPP switch sequence, so I'm not sure how this could cause
> > > > an ABBA deadlock.
> > >
> > > For example:
> > >
> > > [ 7.680041] Chain exists of:
> > > [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> > > [ 7.680041]
> > > [ 7.687955] Possible unsafe locking scenario:
> > > [ 7.687955]
> > > [ 7.699039] CPU0 CPU1
> > > [ 7.704752] ---- ----
> > > [ 7.709266] lock(fs_reclaim);
> > > [ 7.713779] lock(regulator_ww_class_acquire);
> > > [ 7.716919] lock(fs_reclaim);
> > > [ 7.724204] lock(icc_bw_lock);
> > >
> >
> > Hm, I'm not entirely sure how to interpret this. Is there really a
> > connection between OPP and ICC here? It looks more like ICC <->
> > regulator and somehow related to memory allocations (the fs_reclaim).
> >
> > Was there more output around this?
>
> [ 7.362902] ======================================================
> [ 7.363447] WARNING: possible circular locking dependency detected
> [ 7.369434] 6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129 Not tainted
> [ 7.375604] ------------------------------------------------------
> [ 7.382453] swapper/0/1 is trying to acquire lock:
> [ 7.388437] c143445c (icc_bw_lock){+.+.}-{3:3}, at: icc_init+0x0/0x104
> [ 7.393225]
> [ 7.393225] but task is already holding lock:
> [ 7.399730] c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
> [ 7.405547]
> [ 7.405547] which lock already depends on the new lock.
> [ 7.405547]
> [ 7.412077]
> [ 7.412077] the existing dependency chain (in reverse order) is:
> [ 7.420310]
> [ 7.420310] -> #2 (fs_reclaim){+.+.}-{0:0}:
> [ 7.427767] fs_reclaim_acquire+0x60/0x94
> [ 7.433492] __kmem_cache_alloc_node+0x30/0x2b4
> [ 7.437742] __kmalloc_node_track_caller+0x48/0x244
> [ 7.442954] kstrdup+0x30/0x58
> [ 7.448325] create_regulator+0x70/0x2b8
The regulator core should avoid holding the lock while calling into
kstrdup() and also debugfs file creation APIs.
-Stephen
> [ 7.451981] regulator_resolve_supply+0x3bc/0x7f4
> [ 7.456234] regulator_register+0x9b0/0xb50
> [ 7.461352] devm_regulator_register+0x50/0x8c
> [ 7.466216] rpm_reg_probe+0xf4/0x1a0
> [ 7.471244] platform_probe+0x5c/0xb0
> [ 7.475157] really_probe+0xc8/0x2d8
> [ 7.479318] __driver_probe_device+0x88/0x1a0
> [ 7.483488] driver_probe_device+0x30/0x108
> [ 7.488262] __driver_attach_async_helper+0x4c/0xa0
> [ 7.493133] async_run_entry_fn+0x24/0xb0
> [ 7.498504] process_one_work+0x208/0x5e4
> [ 7.502844] worker_thread+0x1e0/0x4a4
> [ 7.507356] kthread+0x100/0x120
> [ 7.511874] ret_from_fork+0x14/0x28
> [ 7.515428]
> [ 7.515428] -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
> [ 7.519528] lock_release+0x164/0x340
> [ 7.526713] __mutex_unlock_slowpath+0x3c/0x2fc
> [ 7.530626] regulator_lock_dependent+0x1a4/0x298
> [ 7.535839] regulator_set_voltage+0x30/0xfc
> [ 7.540866] krait_l2_set_one_supply+0x28/0x84
> [ 7.545729] krait_l2_config_regulators+0x90/0x1c4
> [ 7.550851] _set_opp+0xf0/0x438
> [ 7.556144] dev_pm_opp_set_rate+0x118/0x224
> [ 7.559703] icc_node_add+0xe8/0x15c
> [ 7.564474] icc_clk_register+0x150/0x208
> [ 7.568556] krait_l2_probe+0x100/0x114
> [ 7.572988] platform_probe+0x5c/0xb0
> [ 7.577495] really_probe+0xc8/0x2d8
> [ 7.581487] __driver_probe_device+0x88/0x1a0
> [ 7.585658] driver_probe_device+0x30/0x108
> [ 7.590433] __device_attach_driver+0x94/0x10c
> [ 7.595300] bus_for_each_drv+0x84/0xd8
> [ 7.600326] __device_attach+0xac/0x1a8
> [ 7.604580] bus_probe_device+0x8c/0x90
> [ 7.608919] device_add+0x5c8/0x7a4
> [ 7.613265] of_platform_device_create_pdata+0x90/0xbc
> [ 7.617260] qcom_cpufreq_init+0xa8/0x130
> [ 7.622984] do_one_initcall+0x68/0x2d8
> [ 7.627235] kernel_init_freeable+0x1ac/0x208
> [ 7.631752] kernel_init+0x18/0x12c
> [ 7.636441] ret_from_fork+0x14/0x28
> [ 7.640602]
> [ 7.640602] -> #0 (icc_bw_lock){+.+.}-{3:3}:
> [ 7.644607] __lock_acquire+0x1530/0x28fc
> [ 7.650413] lock_acquire+0x10c/0x33c
> [ 7.654757] icc_init+0x40/0x104
> [ 7.658917] do_one_initcall+0x68/0x2d8
> [ 7.662740] kernel_init_freeable+0x1ac/0x208
> [ 7.667168] kernel_init+0x18/0x12c
> [ 7.671855] ret_from_fork+0x14/0x28
> [ 7.676018]
> [ 7.676018] other info that might help us debug this:
> [ 7.676018]
> [ 7.680041] Chain exists of:
> [ 7.680041] icc_bw_lock --> regulator_ww_class_acquire --> fs_reclaim
> [ 7.680041]
> [ 7.687955] Possible unsafe locking scenario:
> [ 7.687955]
> [ 7.699039] CPU0 CPU1
> [ 7.704752] ---- ----
> [ 7.709266] lock(fs_reclaim);
> [ 7.713779] lock(regulator_ww_class_acquire);
> [ 7.716919] lock(fs_reclaim);
> [ 7.724204] lock(icc_bw_lock);
> [ 7.729833]
> [ 7.729833] *** DEADLOCK ***
> [ 7.729833]
> [ 7.733071] 1 lock held by swapper/0/1:
> [ 7.738691] #0: c1397444 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x18/0x104
> [ 7.742528]
> [ 7.742528] stack backtrace:
> [ 7.749463] CPU: 3 PID: 1 Comm: swapper/0 Not tainted
> 6.6.0-rc3-next-20230929-08870-g49503b4b9f55 #129
> [ 7.754010] Hardware name: Generic DT based system
> [ 7.763183] unwind_backtrace from show_stack+0x10/0x14
> [ 7.767957] show_stack from dump_stack_lvl+0x60/0x90
> [ 7.773082] dump_stack_lvl from check_noncircular+0x174/0x18c
> [ 7.778288] check_noncircular from __lock_acquire+0x1530/0x28fc
> [ 7.784018] __lock_acquire from lock_acquire+0x10c/0x33c
> [ 7.790178] lock_acquire from icc_init+0x40/0x104
> [ 7.795475] icc_init from do_one_initcall+0x68/0x2d8
> [ 7.800159] do_one_initcall from kernel_init_freeable+0x1ac/0x208
> [ 7.805286] kernel_init_freeable from kernel_init+0x18/0x12c
> [ 7.811361] kernel_init from ret_from_fork+0x14/0x28
> [ 7.817177] Exception stack(0xf081dfb0 to 0xf081dff8)
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-08-27 11:50 ` [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling Dmitry Baryshkov
2023-08-28 10:49 ` Konrad Dybcio
@ 2023-10-11 15:49 ` Rob Herring
2023-10-11 18:19 ` Dmitry Baryshkov
1 sibling, 1 reply; 44+ messages in thread
From: Rob Herring @ 2023-10-11 15:49 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Krzysztof Kozlowski, Conor Dooley, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Ilia Lin, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Michael Turquette, Rafael J. Wysocki, Georgi Djakov,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> Add a simple driver that handles scaling of L2 frequency and voltages.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
[...]
> +static const struct of_device_id krait_l2_match_table[] = {
> + { .compatible = "qcom,krait-l2-cache" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> +
> +static struct platform_driver krait_l2_driver = {
> + .probe = krait_l2_probe,
> + .remove = krait_l2_remove,
> + .driver = {
> + .name = "qcom-krait-l2",
> + .of_match_table = krait_l2_match_table,
> + .sync_state = icc_sync_state,
> + },
> +};
As I mentioned in the other thread, cache devices already have a struct
device. Specifically, they have a struct device (no subclass) on the
cpu_subsys bus type. So there should be no need for a platform device
and second struct device.
See drivers/acpi/processor_driver.c for an example. Or grep any use of
"cpu_subsys".
Rob
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-10-11 15:49 ` Rob Herring
@ 2023-10-11 18:19 ` Dmitry Baryshkov
2023-10-11 18:44 ` Rob Herring
0 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2023-10-11 18:19 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar
Cc: Krzysztof Kozlowski, Conor Dooley, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Ilia Lin, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Michael Turquette, Rafael J. Wysocki, Georgi Djakov,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Wed, 11 Oct 2023 at 18:49, Rob Herring <robh@kernel.org> wrote:
>
> On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> > Add a simple driver that handles scaling of L2 frequency and voltages.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
>
> [...]
>
> > +static const struct of_device_id krait_l2_match_table[] = {
> > + { .compatible = "qcom,krait-l2-cache" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> > +
> > +static struct platform_driver krait_l2_driver = {
> > + .probe = krait_l2_probe,
> > + .remove = krait_l2_remove,
> > + .driver = {
> > + .name = "qcom-krait-l2",
> > + .of_match_table = krait_l2_match_table,
> > + .sync_state = icc_sync_state,
> > + },
> > +};
>
> As I mentioned in the other thread, cache devices already have a struct
> device. Specifically, they have a struct device (no subclass) on the
> cpu_subsys bus type. So there should be no need for a platform device
> and second struct device.
>
> See drivers/acpi/processor_driver.c for an example. Or grep any use of
> "cpu_subsys".
Most likely you mean drivers/base/cacheinfo.c. I saw this code, I
don't think it makes a good fit here. The cacheinfo devices provide
information only, they are not tied to DT nodes in any way. cpu_subsys
doesn't provide a way to match drivers with subsys devices in the
non-ACPI case, etc. Moreover, the whole cacheinfo subsys is
non-existing on arm32, there is no cacheinfo implementation there,
thanks to the overall variety of architectures.
Thus said, I don't think cacheinfo makes a good fit for the case of
scaling L2 cache.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-10-11 18:19 ` Dmitry Baryshkov
@ 2023-10-11 18:44 ` Rob Herring
2024-01-04 2:02 ` Dmitry Baryshkov
0 siblings, 1 reply; 44+ messages in thread
From: Rob Herring @ 2023-10-11 18:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Viresh Kumar, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette,
Rafael J. Wysocki, Georgi Djakov, linux-arm-msm, devicetree,
linux-pm, linux-clk, Christian Marangi, Stephan Gerhold
On Wed, Oct 11, 2023 at 1:20 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Wed, 11 Oct 2023 at 18:49, Rob Herring <robh@kernel.org> wrote:
> >
> > On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> > > Add a simple driver that handles scaling of L2 frequency and voltages.
> > >
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > ---
> >
> > [...]
> >
> > > +static const struct of_device_id krait_l2_match_table[] = {
> > > + { .compatible = "qcom,krait-l2-cache" },
> > > + {}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> > > +
> > > +static struct platform_driver krait_l2_driver = {
> > > + .probe = krait_l2_probe,
> > > + .remove = krait_l2_remove,
> > > + .driver = {
> > > + .name = "qcom-krait-l2",
> > > + .of_match_table = krait_l2_match_table,
> > > + .sync_state = icc_sync_state,
> > > + },
> > > +};
> >
> > As I mentioned in the other thread, cache devices already have a struct
> > device. Specifically, they have a struct device (no subclass) on the
> > cpu_subsys bus type. So there should be no need for a platform device
> > and second struct device.
> >
> > See drivers/acpi/processor_driver.c for an example. Or grep any use of
> > "cpu_subsys".
>
> Most likely you mean drivers/base/cacheinfo.c. I saw this code, I
> don't think it makes a good fit here. The cacheinfo devices provide
> information only, they are not tied to DT nodes in any way.
They are completely tied to DT nodes beyond L1.
> cpu_subsys
> doesn't provide a way to match drivers with subsys devices in the
> non-ACPI case, etc.
That's a 2 line addition to add DT support.
> Moreover, the whole cacheinfo subsys is
> non-existing on arm32, there is no cacheinfo implementation there,
> thanks to the overall variety of architectures.
Humm, well I don't think it would be too hard to add, but I won't ask
you to do that. All the info comes from DT or can come from DT, so it
should be just a matter of arm32 calling the cacheinfo init.
> Thus said, I don't think cacheinfo makes a good fit for the case of
> scaling L2 cache.
I still disagree. It's not really cacheinfo. That is what creates the
devices, but it's the cpu_subsys bus type. Why do you care that it is
platform bus vs. cpu_subsys?
On a separate issue, I'd propose you move this to drivers/cache/
instead of the dumping ground that is drivers/soc/. It's nothing more
than a location to collect cache related drivers ATM because we seem
to be accumulating more of them.
Rob
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2023-10-11 18:44 ` Rob Herring
@ 2024-01-04 2:02 ` Dmitry Baryshkov
2024-01-15 16:16 ` Rob Herring
0 siblings, 1 reply; 44+ messages in thread
From: Dmitry Baryshkov @ 2024-01-04 2:02 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Rafael J. Wysocki
Cc: Viresh Kumar, Krzysztof Kozlowski, Conor Dooley, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Ilia Lin, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Michael Turquette, Georgi Djakov,
linux-arm-msm, devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
HI Rob,
Resurrecting old thread, but I think it's better as it has context.
Added driver core maintainers, see discussion points below.
On Wed, 11 Oct 2023 at 21:44, Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Oct 11, 2023 at 1:20 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Wed, 11 Oct 2023 at 18:49, Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> > > > Add a simple driver that handles scaling of L2 frequency and voltages.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > ---
> > >
> > > [...]
> > >
> > > > +static const struct of_device_id krait_l2_match_table[] = {
> > > > + { .compatible = "qcom,krait-l2-cache" },
> > > > + {}
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> > > > +
> > > > +static struct platform_driver krait_l2_driver = {
> > > > + .probe = krait_l2_probe,
> > > > + .remove = krait_l2_remove,
> > > > + .driver = {
> > > > + .name = "qcom-krait-l2",
> > > > + .of_match_table = krait_l2_match_table,
> > > > + .sync_state = icc_sync_state,
> > > > + },
> > > > +};
> > >
> > > As I mentioned in the other thread, cache devices already have a struct
> > > device. Specifically, they have a struct device (no subclass) on the
> > > cpu_subsys bus type. So there should be no need for a platform device
> > > and second struct device.
> > >
> > > See drivers/acpi/processor_driver.c for an example. Or grep any use of
> > > "cpu_subsys".
> >
> > Most likely you mean drivers/base/cacheinfo.c. I saw this code, I
> > don't think it makes a good fit here. The cacheinfo devices provide
> > information only, they are not tied to DT nodes in any way.
>
> They are completely tied to DT nodes beyond L1.
>
> > cpu_subsys
> > doesn't provide a way to match drivers with subsys devices in the
> > non-ACPI case, etc.
>
> That's a 2 line addition to add DT support.
>
> > Moreover, the whole cacheinfo subsys is
> > non-existing on arm32, there is no cacheinfo implementation there,
> > thanks to the overall variety of architectures.
>
> Humm, well I don't think it would be too hard to add, but I won't ask
> you to do that. All the info comes from DT or can come from DT, so it
> should be just a matter of arm32 calling the cacheinfo init.
>
> > Thus said, I don't think cacheinfo makes a good fit for the case of
> > scaling L2 cache.
>
> I still disagree. It's not really cacheinfo. That is what creates the
> devices, but it's the cpu_subsys bus type. Why do you care that it is
> platform bus vs. cpu_subsys?
I finally found a timeslot to look at cacheinfo. I added support for
arm32 cacheinfo (which is fine) and tried using cacheinfo devices for
L2 driver mapping (the RFC has been posted at [1]).
But after I actually tried using it for the L2 cache driver. I
stumbled upon several issues, which I'd like to discuss before rushing
to code.
First, you supposed that cacheinfo devices land onto the cpu_subsys
bus. However only actual CPU devices end up on cpu_subsys. CPU cache
devices are created using cpu_device_create(), but despite its name
they don't go to cpu_subsys.
Second and more important, these devices are created without any
attempt to share them. So on a 4-core system I have 4 distinct devices
for L2 cache even though it is shared between all cores.
root@qcom-armv7a:~# stat -c "%N %i" /sys/bus/cpu/devices/cpu*/cache/index2/level
/sys/bus/cpu/devices/cpu0/cache/index2/level 15537
/sys/bus/cpu/devices/cpu1/cache/index2/level 15560
/sys/bus/cpu/devices/cpu2/cache/index2/level 15583
/sys/bus/cpu/devices/cpu3/cache/index2/level 15606
I think it makes sense to rework cacheinfo to create actual CPU cache
devices (maybe having a separate cache bus).
In my case it should become something like:
cpu0-2-unified (shared between all 4 cores)
cpu0-1-icache
cpu0-1-dcache
cpu1-1-icache
cpu1-1-dcache
...
I'm not sure if it's worth supporting more than one instance of the
same kind per level (e.g. I think current cacheinfo has nothing
against having two I-cache or two D-cache devices)
The cpuN/cache/indexM should become symlinks to those cache devices.
What do you think?
[1] https://lore.kernel.org/linux-arm-msm/CAA8EJppCRzknaujKFyLa_i7x4UnX31YFSyjtux+zJ0harixrbA@mail.gmail.com
> On a separate issue, I'd propose you move this to drivers/cache/
> instead of the dumping ground that is drivers/soc/. It's nothing more
> than a location to collect cache related drivers ATM because we seem
> to be accumulating more of them.
I thought about reusing drivers/devfreq, it already has the Mediatek CCI driver.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling
2024-01-04 2:02 ` Dmitry Baryshkov
@ 2024-01-15 16:16 ` Rob Herring
0 siblings, 0 replies; 44+ messages in thread
From: Rob Herring @ 2024-01-15 16:16 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Viresh Kumar,
Krzysztof Kozlowski, Conor Dooley, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Ilia Lin, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Michael Turquette, Georgi Djakov, linux-arm-msm,
devicetree, linux-pm, linux-clk, Christian Marangi,
Stephan Gerhold
On Wed, Jan 3, 2024 at 8:02 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> HI Rob,
>
> Resurrecting old thread, but I think it's better as it has context.
>
> Added driver core maintainers, see discussion points below.
>
> On Wed, 11 Oct 2023 at 21:44, Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, Oct 11, 2023 at 1:20 PM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > >
> > > On Wed, 11 Oct 2023 at 18:49, Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> > > > > Add a simple driver that handles scaling of L2 frequency and voltages.
> > > > >
> > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > > ---
> > > >
> > > > [...]
> > > >
> > > > > +static const struct of_device_id krait_l2_match_table[] = {
> > > > > + { .compatible = "qcom,krait-l2-cache" },
> > > > > + {}
> > > > > +};
> > > > > +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> > > > > +
> > > > > +static struct platform_driver krait_l2_driver = {
> > > > > + .probe = krait_l2_probe,
> > > > > + .remove = krait_l2_remove,
> > > > > + .driver = {
> > > > > + .name = "qcom-krait-l2",
> > > > > + .of_match_table = krait_l2_match_table,
> > > > > + .sync_state = icc_sync_state,
> > > > > + },
> > > > > +};
> > > >
> > > > As I mentioned in the other thread, cache devices already have a struct
> > > > device. Specifically, they have a struct device (no subclass) on the
> > > > cpu_subsys bus type. So there should be no need for a platform device
> > > > and second struct device.
> > > >
> > > > See drivers/acpi/processor_driver.c for an example. Or grep any use of
> > > > "cpu_subsys".
> > >
> > > Most likely you mean drivers/base/cacheinfo.c. I saw this code, I
> > > don't think it makes a good fit here. The cacheinfo devices provide
> > > information only, they are not tied to DT nodes in any way.
> >
> > They are completely tied to DT nodes beyond L1.
> >
> > > cpu_subsys
> > > doesn't provide a way to match drivers with subsys devices in the
> > > non-ACPI case, etc.
> >
> > That's a 2 line addition to add DT support.
> >
> > > Moreover, the whole cacheinfo subsys is
> > > non-existing on arm32, there is no cacheinfo implementation there,
> > > thanks to the overall variety of architectures.
> >
> > Humm, well I don't think it would be too hard to add, but I won't ask
> > you to do that. All the info comes from DT or can come from DT, so it
> > should be just a matter of arm32 calling the cacheinfo init.
> >
> > > Thus said, I don't think cacheinfo makes a good fit for the case of
> > > scaling L2 cache.
> >
> > I still disagree. It's not really cacheinfo. That is what creates the
> > devices, but it's the cpu_subsys bus type. Why do you care that it is
> > platform bus vs. cpu_subsys?
>
> I finally found a timeslot to look at cacheinfo. I added support for
> arm32 cacheinfo (which is fine) and tried using cacheinfo devices for
> L2 driver mapping (the RFC has been posted at [1]).
> But after I actually tried using it for the L2 cache driver. I
> stumbled upon several issues, which I'd like to discuss before rushing
> to code.
>
> First, you supposed that cacheinfo devices land onto the cpu_subsys
> bus. However only actual CPU devices end up on cpu_subsys. CPU cache
> devices are created using cpu_device_create(), but despite its name
> they don't go to cpu_subsys.
>
> Second and more important, these devices are created without any
> attempt to share them. So on a 4-core system I have 4 distinct devices
> for L2 cache even though it is shared between all cores.
I wonder if that's because things are created in CPU hotplug callbacks
and there might be ordering problems if cache devices are created in
another code path.
Also, I think on some PowerPC systems, CPUs can move to different L2
(or L3?) caches when hot unplugged and then plugged. So hotplug
rescans everything. I don't think that would be a problem with this
and PowerPC does its own scanning anyways. Just wanted you to be aware
of the issue.
> root@qcom-armv7a:~# stat -c "%N %i" /sys/bus/cpu/devices/cpu*/cache/index2/level
> /sys/bus/cpu/devices/cpu0/cache/index2/level 15537
> /sys/bus/cpu/devices/cpu1/cache/index2/level 15560
> /sys/bus/cpu/devices/cpu2/cache/index2/level 15583
> /sys/bus/cpu/devices/cpu3/cache/index2/level 15606
>
> I think it makes sense to rework cacheinfo to create actual CPU cache
> devices (maybe having a separate cache bus).
> In my case it should become something like:
>
> cpu0-2-unified (shared between all 4 cores)
> cpu0-1-icache
> cpu0-1-dcache
> cpu1-1-icache
> cpu1-1-dcache
> ...
>
> I'm not sure if it's worth supporting more than one instance of the
> same kind per level (e.g. I think current cacheinfo has nothing
> against having two I-cache or two D-cache devices)
Probably a safe assumption. Though I think old XScale CPUs had a 1K
mini I-cache and the main L1 I-cache. I guess that's really an L0
cache though.
> The cpuN/cache/indexM should become symlinks to those cache devices.
>
> What do you think?
Seems like a good improvement to me if changing the current way
doesn't cause an ABI issue.
> [1] https://lore.kernel.org/linux-arm-msm/CAA8EJppCRzknaujKFyLa_i7x4UnX31YFSyjtux+zJ0harixrbA@mail.gmail.com
>
> > On a separate issue, I'd propose you move this to drivers/cache/
> > instead of the dumping ground that is drivers/soc/. It's nothing more
> > than a location to collect cache related drivers ATM because we seem
> > to be accumulating more of them.
>
> I thought about reusing drivers/devfreq, it already has the Mediatek CCI driver.
Anywhere except drivers/misc/ would be an improvement over
drivers/soc/. devfreq is more tied to interconnects than caches
though.
Rob
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2024-01-15 16:17 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-27 11:50 [PATCH v4 00/23] ARM: qcom: apq8064: support CPU frequency scaling Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 01/23] dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 02/23] dt-bindings: soc: qcom: qcom,saw2: define optional regulator node Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 03/23] dt-bindings: clock: qcom,krait-cc: Krait core clock controller Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 04/23] dt-bindings: cache: describe L2 cache on Qualcomm Krait platforms Dmitry Baryshkov
2023-08-28 15:33 ` Rob Herring
2023-08-27 11:50 ` [PATCH v4 05/23] interconnect: icc-clk: add support for scaling using OPP Dmitry Baryshkov
[not found] ` <493aff10d698c9ca5bdbeae45250f5fe.sboyd@kernel.org>
2023-08-28 21:18 ` Dmitry Baryshkov
2023-10-03 8:30 ` Dmitry Baryshkov
2023-10-03 13:01 ` Stephan Gerhold
2023-10-03 13:36 ` Dmitry Baryshkov
2023-10-03 14:17 ` Stephan Gerhold
2023-10-03 15:31 ` Dmitry Baryshkov
2023-10-03 16:04 ` Stephan Gerhold
2023-10-10 4:14 ` Stephen Boyd
2023-08-27 11:50 ` [PATCH v4 06/23] clk: qcom: krait-cc: rewrite driver to use clk_hw instead of clk Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 07/23] soc: qcom: spm: add support for voltage regulator Dmitry Baryshkov
2023-08-28 10:49 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 08/23] soc: qcom: Add driver for Qualcomm Krait L2 cache scaling Dmitry Baryshkov
2023-08-28 10:49 ` Konrad Dybcio
2023-10-11 15:49 ` Rob Herring
2023-10-11 18:19 ` Dmitry Baryshkov
2023-10-11 18:44 ` Rob Herring
2024-01-04 2:02 ` Dmitry Baryshkov
2024-01-15 16:16 ` Rob Herring
2023-08-27 11:50 ` [PATCH v4 09/23] ARM: dts: qcom: apq8064-asus-nexus7-flo: constraint cpufreq regulators Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 10/23] ARM: dts: qcom: apq8064-cm-qs600: " Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 11/23] ARM: dts: qcom: apq8064-ifc6410: " Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 12/23] ARM: dts: qcom: apq8064-sony-xperia-lagan-yuga: " Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 13/23] ARM: dts: qcom: apq8064: rename SAW nodes to power-manager Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 14/23] ARM: dts: qcom: apq8064: declare SAW2 regulators Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 15/23] ARM: dts: qcom: apq8064: add Krait clock controller Dmitry Baryshkov
2023-08-28 10:54 ` Konrad Dybcio
2023-08-28 11:38 ` Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 16/23] ARM: dts: qcom: apq8064: add L2 cache scaling Dmitry Baryshkov
2023-08-28 10:55 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 17/23] ARM: dts: qcom: apq8064: add simple CPUFreq support Dmitry Baryshkov
2023-08-28 10:56 ` Konrad Dybcio
2023-08-27 11:50 ` [PATCH v4 18/23] ARM: dts: qcom: apq8064: enable passive CPU cooling Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 19/23] ARM: dts: qcom: msm8960: declare SAW2 regulators Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 20/23] ARM: dts: qcom: apq8084: drop 'regulator' property from SAW2 device Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 21/23] ARM: dts: qcom: msm8974: " Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 22/23] ARM: dts: qcom: ipq4019: drop 'regulator' property from SAW2 devices Dmitry Baryshkov
2023-08-27 11:50 ` [PATCH v4 23/23] ARM: dts: qcom: ipq8064: " Dmitry Baryshkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).