* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Rob Herring (Arm) @ 2026-03-28 14:26 UTC (permalink / raw)
To: Khushal Chitturi
Cc: devicetree, linux-kernel, linux-pm, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Linus Walleij
In-Reply-To: <20260328124707.141209-1-khushalchitturi@gmail.com>
On Sat, 28 Mar 2026 18:17:07 +0530, Khushal Chitturi wrote:
> Convert the Cortina Systems Gemini Poweroff Controller bindings to
> DT schema.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> .../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
> .../bindings/power/reset/gemini-poweroff.txt | 17 --------
> 2 files changed, 42 insertions(+), 17 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260328124707.141209-1-khushalchitturi@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS d5fd8cd3b0d8b0d995d9f97135e2ac680d3ed1f1
From: kernel test robot @ 2026-03-28 13:37 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: d5fd8cd3b0d8b0d995d9f97135e2ac680d3ed1f1 Merge branch 'thermal-core-fixes' into bleeding-edge
elapsed time: 1098m
configs tested: 209
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260328 gcc-15.2.0
arc randconfig-002-20260328 gcc-15.2.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm aspeed_g4_defconfig clang-23
arm defconfig gcc-15.2.0
arm randconfig-001-20260328 gcc-15.2.0
arm randconfig-002-20260328 gcc-15.2.0
arm randconfig-003-20260328 gcc-15.2.0
arm randconfig-004-20260328 gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260328 gcc-14.3.0
arm64 randconfig-002-20260328 gcc-14.3.0
arm64 randconfig-003-20260328 gcc-14.3.0
arm64 randconfig-004-20260328 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260328 gcc-14.3.0
csky randconfig-002-20260328 gcc-14.3.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260328 gcc-11.5.0
hexagon randconfig-002-20260328 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260328 clang-20
i386 buildonly-randconfig-002-20260328 clang-20
i386 buildonly-randconfig-002-20260328 gcc-12
i386 buildonly-randconfig-003-20260328 clang-20
i386 buildonly-randconfig-003-20260328 gcc-14
i386 buildonly-randconfig-004-20260328 clang-20
i386 buildonly-randconfig-005-20260328 clang-20
i386 buildonly-randconfig-006-20260328 clang-20
i386 buildonly-randconfig-006-20260328 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260328 clang-20
i386 randconfig-002-20260328 clang-20
i386 randconfig-003-20260328 clang-20
i386 randconfig-004-20260328 clang-20
i386 randconfig-005-20260328 clang-20
i386 randconfig-006-20260328 clang-20
i386 randconfig-007-20260328 clang-20
i386 randconfig-011-20260328 gcc-13
i386 randconfig-012-20260328 gcc-13
i386 randconfig-012-20260328 gcc-14
i386 randconfig-013-20260328 clang-20
i386 randconfig-013-20260328 gcc-13
i386 randconfig-014-20260328 gcc-13
i386 randconfig-014-20260328 gcc-14
i386 randconfig-015-20260328 gcc-13
i386 randconfig-016-20260328 gcc-13
i386 randconfig-017-20260328 clang-20
i386 randconfig-017-20260328 gcc-13
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260328 gcc-11.5.0
loongarch randconfig-002-20260328 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip27_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260328 gcc-11.5.0
nios2 randconfig-002-20260328 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260328 gcc-10.5.0
parisc randconfig-002-20260328 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc cell_defconfig gcc-15.2.0
powerpc randconfig-001-20260328 gcc-10.5.0
powerpc randconfig-002-20260328 gcc-10.5.0
powerpc64 randconfig-001-20260328 gcc-10.5.0
powerpc64 randconfig-002-20260328 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260328 clang-23
riscv randconfig-002-20260328 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260328 clang-23
s390 randconfig-002-20260328 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260328 clang-23
sh randconfig-002-20260328 clang-23
sh se7705_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260328 gcc-14
sparc randconfig-002-20260328 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260328 gcc-14
sparc64 randconfig-002-20260328 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260328 gcc-14
um randconfig-002-20260328 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260328 clang-20
x86_64 buildonly-randconfig-002-20260328 clang-20
x86_64 buildonly-randconfig-003-20260328 clang-20
x86_64 buildonly-randconfig-004-20260328 clang-20
x86_64 buildonly-randconfig-005-20260328 clang-20
x86_64 buildonly-randconfig-006-20260328 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260328 clang-20
x86_64 randconfig-001-20260328 gcc-14
x86_64 randconfig-002-20260328 gcc-13
x86_64 randconfig-002-20260328 gcc-14
x86_64 randconfig-003-20260328 gcc-14
x86_64 randconfig-004-20260328 gcc-14
x86_64 randconfig-005-20260328 clang-20
x86_64 randconfig-005-20260328 gcc-14
x86_64 randconfig-006-20260328 gcc-14
x86_64 randconfig-011-20260328 clang-20
x86_64 randconfig-012-20260328 clang-20
x86_64 randconfig-013-20260328 clang-20
x86_64 randconfig-014-20260328 clang-20
x86_64 randconfig-015-20260328 clang-20
x86_64 randconfig-016-20260328 clang-20
x86_64 randconfig-071-20260328 gcc-12
x86_64 randconfig-072-20260328 gcc-12
x86_64 randconfig-073-20260328 gcc-12
x86_64 randconfig-074-20260328 gcc-12
x86_64 randconfig-075-20260328 gcc-12
x86_64 randconfig-076-20260328 gcc-12
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260328 gcc-14
xtensa randconfig-002-20260328 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-28 12:47 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Linus Walleij, linux-pm, devicetree, linux-kernel,
Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..1f9af7f34004
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ power-controller@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 2/4] dt-bindings: thermal: lmh: Add SDM670 compatible
From: Krzysztof Kozlowski @ 2026-03-28 12:20 UTC (permalink / raw)
To: Richard Acayan
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
In-Reply-To: <20260328014041.83777-3-mailingradian@gmail.com>
On Fri, Mar 27, 2026 at 09:40:39PM -0400, Richard Acayan wrote:
> Document the SDM670 LMh.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Why are you sending patches already applied 18 days ago?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] thermal: core: Address thermal zone removal races with resume
From: Rafael J. Wysocki @ 2026-03-28 11:50 UTC (permalink / raw)
To: Dan Carpenter
Cc: oe-kbuild, Rafael J. Wysocki, Linux PM, lkp, oe-kbuild-all,
Mauricio Faria de Oliveira, LKML, Daniel Lezcano, Lukasz Luba
In-Reply-To: <202603280307.P9324SuS-lkp@intel.com>
Hi,
On Sat, Mar 28, 2026 at 9:03 AM Dan Carpenter <error27@gmail.com> wrote:
>
> Hi Rafael,
>
> kernel test robot noticed the following build warnings:
>
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Rafael-J-Wysocki/thermal-core-Address-thermal-zone-removal-races-with-resume/20260327-222101
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git thermal
> patch link: https://lore.kernel.org/r/12876512.O9o76ZdvQC%40rafael.j.wysocki
> patch subject: [PATCH v1] thermal: core: Address thermal zone removal races with resume
> config: i386-randconfig-141-20260328 (https://download.01.org/0day-ci/archive/20260328/202603280307.P9324SuS-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> smatch: v0.5.0-9004-gb810ac53
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Reported-by: Dan Carpenter <error27@gmail.com>
> | Closes: https://lore.kernel.org/r/202603280307.P9324SuS-lkp@intel.com/
>
> smatch warnings:
> drivers/thermal/thermal_core.c:1913 thermal_init() warn: missing error code 'result'
>
> vim +/result +1913 drivers/thermal/thermal_core.c
>
> 203d3d4aa48233 drivers/thermal/thermal.c Zhang Rui 2008-01-17 1900 static int __init thermal_init(void)
> 203d3d4aa48233 drivers/thermal/thermal.c Zhang Rui 2008-01-17 1901 {
> 80a26a5c22b90a drivers/thermal/thermal_core.c Zhang Rui 2013-03-26 1902 int result;
> 80a26a5c22b90a drivers/thermal/thermal_core.c Zhang Rui 2013-03-26 1903
> 755113d7678681 drivers/thermal/thermal_core.c Daniel Lezcano 2024-01-09 1904 thermal_debug_init();
> 755113d7678681 drivers/thermal/thermal_core.c Daniel Lezcano 2024-01-09 1905
> d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1906 result = thermal_netlink_init();
> d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1907 if (result)
> d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1908 goto error;
> d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1909
> f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1910 thermal_wq = alloc_workqueue("thermal_events",
> f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1911 WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
> f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1912 if (!thermal_wq)
> f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 @1913 goto unregister_netlink;
>
> result = -ENOMEM;
>
>
> --
This has been fixed in the v2:
https://lore.kernel.org/linux-pm/6267615.lOV4Wx5bFT@rafael.j.wysocki/
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Barnabás Czémán @ 2026-03-28 8:22 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <ocrzwxmr256h3ef7ifwx3z6jgtzubiha3forfi7nao6gakb6wu@recertxxhlip>
On 2026-03-27 21:26, Dmitry Baryshkov wrote:
> On Fri, Mar 27, 2026 at 09:11:43PM +0100, Barnabás Czémán wrote:
>> Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
>> is using mss-supply as a regulator usually it is pm8953_s1.
>> Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
>> as a pm domain.
>>
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>> .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
>> include/dt-bindings/power/qcom-rpmpd.h | 20
>> +++++++++++++-------
>> 2 files changed, 14 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>> b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>> index 8174ceeab572..659936d6a46e 100644
>> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>> @@ -48,6 +48,7 @@ properties:
>> - qcom,sc7280-rpmhpd
>> - qcom,sc8180x-rpmhpd
>> - qcom,sc8280xp-rpmhpd
>> + - qcom,sdm632-rpmpd
>> - qcom,sdm660-rpmpd
>> - qcom,sdm670-rpmhpd
>> - qcom,sdm845-rpmhpd
>> diff --git a/include/dt-bindings/power/qcom-rpmpd.h
>> b/include/dt-bindings/power/qcom-rpmpd.h
>> index 4371ac941f29..2d82434b993c 100644
>> --- a/include/dt-bindings/power/qcom-rpmpd.h
>> +++ b/include/dt-bindings/power/qcom-rpmpd.h
>> @@ -84,13 +84,11 @@
>> #define QM215_VDDMX_AO MSM8917_VDDMX_AO
>>
>> /* MSM8953 Power Domain Indexes */
>> -#define MSM8953_VDDMD 0
>> -#define MSM8953_VDDMD_AO 1
>> -#define MSM8953_VDDCX 2
>> -#define MSM8953_VDDCX_AO 3
>> -#define MSM8953_VDDCX_VFL 4
>> -#define MSM8953_VDDMX 5
>> -#define MSM8953_VDDMX_AO 6
>> +#define MSM8953_VDDCX RPMPD_VDDCX
>> +#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
>> +#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
>> +#define MSM8953_VDDMX RPMPD_VDDMX
>> +#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
>
> Well, no. This is an ABI break. It will make previous DT to stop from
> working. You can drop unused indices, but you can not change the values
> used by the existing domains.
Do these indices never can be changed?
>
>>
>> /* MSM8974 Power Domain Indexes */
>> #define MSM8974_VDDCX 0
>> @@ -156,6 +154,14 @@
>> #define QCS404_LPIMX 5
>> #define QCS404_LPIMX_VFL 6
>>
>> +/* SDM632 Power Domain Indexes */
>> +#define SDM632_VDDMD 0
>> +#define SDM632_VDDCX 1
>> +#define SDM632_VDDCX_AO 2
>> +#define SDM632_VDDCX_VFL 3
>> +#define SDM632_VDDMX 4
>> +#define SDM632_VDDMX_AO 5
>
> Please use RPMHPD_* instead of introducing new entries.
I do not understand completely, should I use RPHPD bindings in rpmpd
driver or
I should use rpmhpd driver for SDM632?
>
>> +
>> /* SDM660 Power Domains */
>> #define SDM660_VDDCX RPMPD_VDDCX
>> #define SDM660_VDDCX_AO RPMPD_VDDCX_AO
>>
>> --
>> 2.53.0
>>
^ permalink raw reply
* Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load()
From: Qais Yousef @ 2026-03-28 8:09 UTC (permalink / raw)
To: Lukasz Luba
Cc: Xuewen Yan, Viresh Kumar, Xuewen Yan, rui.zhang, rafael, linux-pm,
amit.kachhap, daniel.lezcano, linux-kernel, ke.wang, di.shen,
jeson.gao, Peter Zijlstra, Vincent Guittot
In-Reply-To: <c816757a-3169-4d5f-942b-4c49be89ebe1@arm.com>
On 03/26/26 09:21, Lukasz Luba wrote:
>
>
> On 3/26/26 09:05, Qais Yousef wrote:
> > On 03/24/26 10:46, Lukasz Luba wrote:
> > >
> > > On 3/24/26 02:20, Xuewen Yan wrote:
> > > > On Mon, Mar 23, 2026 at 9:25 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 3/23/26 11:06, Viresh Kumar wrote:
> > > > > > On 23-03-26, 10:52, Lukasz Luba wrote:
> > > > > > > > How is that okay ? What am I missing ?
> > > > > >
> > > > > > I was missing !SMP :)
> > > > > >
> > > > > > > Right, there is a mix of two things.
> > > > > > > The 'i' left but should be removed as well, since
> > > > > > > this is !SMP code with only 1 cpu and i=0.
> > > >
> > > > That's also why we sent out patch 1/2; after all, it is always 0 on
> > > > !SMP systems.
> > > >
> > > > > > >
> > > > > > > The whole split which has been made for getting
> > > > > > > the load or utilization from CPU(s) needs to be
> > > > > > > cleaned. The compiled code looks different since
> > > > > > > it knows there is non-SMP config used.
> > > > > >
> > > > > > Right, we are allocating that for num_cpus (which should be 1 CPU
> > > > > > anyway). The entire thing must be cleaned.
> > > > > >
> > > > > > > Do you want to clean that or I should do this?
> > > > > >
> > > > > > It would be helpful if you can do it :)
> > > > > >
> > > > >
> > > > > OK, I will. Thanks for your involvement Viresh!
> > > > >
> > > > > Xuewen please wait with your v2, I will send
> > > > > a redesign of this left code today.
> > > >
> > > > Okay, and Qais's point is also worth considering: do we actually need
> > > > sched_cpu_util()?
> > > > The way I see it, generally speaking, the request_power derived from
> > > > idle_time might be higher than what we get from sched_cpu_util().
> > > > Take this scenario as an example:
> > > > Consider a CPU running at the lowest frequency with 50% idle time,
> > > > versus one running at the highest frequency with the same 50% idle
> > > > time.
> > > > In this case, using idle_time yields the same load value for both.
> > > > However, sched_cpu_util() would report a lower load when the CPU
> > > > frequency is low. This results in a smaller request_power...
> >
> > Invariance will cause settling time to stretch longer, but it should settle to
> > the correct value eventually. But generally another case against util is that
> > it has grown to be a description of compute demand more than true idleness of
> > the system.
> >
> > >
> > > Right, there are 2 things to consider:
> > > 1. what is the utilization when the CPU still have idle time, e.g.
> > > this 50% that you mentioned
> > > 2. what is the utilization when there is no idle time and CPU
> > > is fully busy (and starts throttling due to heat)
> >
> > Hmm I think what you're trying to say here we need to distinguish between two
> > cases 50% or fully busy? I think how idle the system is a better question to
> > ask rather than what is the utilization (given the ubiquity of the signal
> > nowadays)
>
> Yes, these two cases, which are different and util signal is not the
> best for that idleness one.
>
>
> >
> > >
> > > In this thermal fwk we are mostly in the 2nd case. In that case the
> >
> > But from power allocator perspective (which I think is the context, right?),
> > you want to know if you can shift power?
>
> I would like to know the avg power in the last X ms window, then
> allocate, shift, set.
>
> >
> > > utilization on CPU's runqueue goes to 1024 no mater the CPU's frequency.
> > > We know which highest frequency was allowed to run and we pick the power
> > > value from EM for it. That's why the estimation is not that bad (apart
> > > from power variation for different flavors of workloads: heavy SIMD vs.
> > > normal integer/load).
> > >
> > > In 1st case scenario we might underestimate the power, but that
> > > is not the thermal stress situation anyway, so the max OPP is
> > > still allowed.
> > >
> > > So far it is hard to find the best power model to use and robust CPU
> > > load mechanisms. Adding more complexity and creating some
> > > over-engineered code in the kernel to maintain might not have sense.
> > > The thermal solutions are solved in the Firmware nowadays since the
> > > kernel won't react that fast for some rapid changes.
> > >
> > > We have to balance the complexity here.
> >
> > I am not verse in all the details, so not sure what complexity you are
> > referring to. IMHO the idle time is a more stable view for how much a breathing
> > room the cpu has. It also deals better with long decay of blocked load
> > over-estimating the utilization. AFAICS just sample the idle over a window when
> > you need to take a decision and you'd solve several problems in one go.
>
> We have issues in estimating power in that X ms window due to fast
> frequency changes. You know how often we can change the frequency,
> almost per-task enqueue (and e.g. uclamp pushes that even harder).
>
> Simple approach for assuming that the frequency we see now on CPU
> has been there for the whole Xms period is 'not the best'.
> The util information w/o uclamp information is not helping
> much (even we we would try to derive the freq out of it).
>
> Now even more complex - the FW can change the freq way often
> than the kernel. So the question is how far we have to push
> the whole kernel and those frameworks to deal with those new
> platforms.
>
> Then add the power variation due to different computation types
> e.g. SIMD heavy vs simple logging task (high power vs. low power
> usage at the same OPP).
>
> IMHO we have to find a balance since even more complex models
> in kernel won't be able to handle that.
>
> I have been experimenting with the Active Stats patch set for
> quite a while, but then FW came into the equation and complicated
> the situation. It will be still better for such platform
> where FW doesn't change the freq, so this approach based on
> idle stats is worth to add IMO.
Hmm isn't this orthogonal? It seems cpu util is used today to estimate how busy
(or idle) the cpu is. You can decouple the dep on util (and scheduler in
general) and monitor system idleness.
Anyway. Please don't add this ifdefry and the strange deps on scx. This is
a recipe for shooting ourselves in the foot.
^ permalink raw reply
* Re: [PATCH v1] thermal: core: Address thermal zone removal races with resume
From: Dan Carpenter @ 2026-03-28 8:03 UTC (permalink / raw)
To: oe-kbuild, Rafael J. Wysocki, Linux PM
Cc: lkp, oe-kbuild-all, Mauricio Faria de Oliveira, LKML,
Daniel Lezcano, Lukasz Luba
In-Reply-To: <12876512.O9o76ZdvQC@rafael.j.wysocki>
Hi Rafael,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rafael-J-Wysocki/thermal-core-Address-thermal-zone-removal-races-with-resume/20260327-222101
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git thermal
patch link: https://lore.kernel.org/r/12876512.O9o76ZdvQC%40rafael.j.wysocki
patch subject: [PATCH v1] thermal: core: Address thermal zone removal races with resume
config: i386-randconfig-141-20260328 (https://download.01.org/0day-ci/archive/20260328/202603280307.P9324SuS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
smatch: v0.5.0-9004-gb810ac53
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202603280307.P9324SuS-lkp@intel.com/
smatch warnings:
drivers/thermal/thermal_core.c:1913 thermal_init() warn: missing error code 'result'
vim +/result +1913 drivers/thermal/thermal_core.c
203d3d4aa48233 drivers/thermal/thermal.c Zhang Rui 2008-01-17 1900 static int __init thermal_init(void)
203d3d4aa48233 drivers/thermal/thermal.c Zhang Rui 2008-01-17 1901 {
80a26a5c22b90a drivers/thermal/thermal_core.c Zhang Rui 2013-03-26 1902 int result;
80a26a5c22b90a drivers/thermal/thermal_core.c Zhang Rui 2013-03-26 1903
755113d7678681 drivers/thermal/thermal_core.c Daniel Lezcano 2024-01-09 1904 thermal_debug_init();
755113d7678681 drivers/thermal/thermal_core.c Daniel Lezcano 2024-01-09 1905
d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1906 result = thermal_netlink_init();
d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1907 if (result)
d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1908 goto error;
d2a89b52839597 drivers/thermal/thermal_core.c Daniel Lezcano 2020-07-17 1909
f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1910 thermal_wq = alloc_workqueue("thermal_events",
f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1911 WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 1912 if (!thermal_wq)
f777132b791874 drivers/thermal/thermal_core.c Rafael J. Wysocki 2026-03-26 @1913 goto unregister_netlink;
result = -ENOMEM;
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: qcom: sdm670: add thermal zones and thermal devices
From: Richard Acayan @ 2026-03-28 1:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
Cc: Richard Acayan
In-Reply-To: <20260328014041.83777-1-mailingradian@gmail.com>
Add thermal zones to safeguard from overheating to high temperatures,
along with the thermal sensors (TSENS) and CPU frequency limits (LMh).
The temperatures are very high, but should still be safeguard for
devices that do not specify their own thermal zones.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 +++++++++++++++++++++++++++
1 file changed, 400 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index f115bc6e64f3..c5f7655421a3 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -20,6 +20,7 @@
#include <dt-bindings/phy/phy-qcom-qusb2.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&intc>;
@@ -62,6 +63,7 @@ cpu0: cpu@0 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd0>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_0>;
l2_0: l2-cache {
compatible = "cache";
@@ -89,6 +91,7 @@ cpu1: cpu@100 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd1>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_100>;
l2_100: l2-cache {
compatible = "cache";
@@ -111,6 +114,7 @@ cpu2: cpu@200 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd2>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_200>;
l2_200: l2-cache {
compatible = "cache";
@@ -133,6 +137,7 @@ cpu3: cpu@300 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd3>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_300>;
l2_300: l2-cache {
compatible = "cache";
@@ -155,6 +160,7 @@ cpu4: cpu@400 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd4>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_400>;
l2_400: l2-cache {
compatible = "cache";
@@ -177,6 +183,7 @@ cpu5: cpu@500 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd5>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_500>;
l2_500: l2-cache {
compatible = "cache";
@@ -199,6 +206,7 @@ cpu6: cpu@600 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd6>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_600>;
l2_600: l2-cache {
compatible = "cache";
@@ -221,6 +229,7 @@ cpu7: cpu@700 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd7>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_700>;
l2_700: l2-cache {
compatible = "cache";
@@ -1408,6 +1417,8 @@ gpu: gpu@5000000 {
nvmem-cells = <&gpu_speed_bin>;
nvmem-cell-names = "speed_bin";
+ #cooling-cells = <2>;
+
status = "disabled";
gpu_zap_shader: zap-shader {
@@ -2100,6 +2111,28 @@ dispcc: clock-controller@af00000 {
#power-domain-cells = <1>;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1000>,
+ <0 0x0c222000 0 0x1000>;
+ interrupts-extended = <&pdc 26 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 28 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <13>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c265000 0 0x1000>,
+ <0 0x0c223000 0 0x1000>;
+ interrupts-extended = <&pdc 27 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 29 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <8>;
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,sdm670-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0 0x15000000 0 0x80000>;
@@ -2289,5 +2322,372 @@ cpufreq_hw: cpufreq@17d43000 {
#freq-domain-cells = <1>;
};
+
+ lmh_cluster1: lmh@17d70800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d70800 0 0x400>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu6>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ lmh_cluster0: lmh@17d78800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d78800 0 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu0>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ thermal-zones {
+ aoss0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 0>;
+
+ trips {
+ aoss0_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 1>;
+
+ trips {
+ cpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 2>;
+
+ trips {
+ cpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu2-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 3>;
+
+ trips {
+ cpu2_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu3-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 4>;
+
+ trips {
+ cpu3_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 5>;
+
+ trips {
+ cluster0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 6>;
+
+ trips {
+ cluster1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu4-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 7>;
+
+ trips {
+ cpu4_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu5-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 8>;
+
+ trips {
+ cpu5_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu6-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 9>;
+
+ trips {
+ cpu6_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu7-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 10>;
+
+ trips {
+ cpu7_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 11>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu0_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 12>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu1_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ aoss1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 0>;
+
+ trips {
+ aoss1_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 1>;
+
+ trips {
+ q6_modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ mem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 2>;
+
+ trips {
+ mem_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ wlan-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 3>;
+
+ trips {
+ wlan_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-hvx-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 4>;
+
+ trips {
+ q6_hvx_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ camera-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 5>;
+
+ trips {
+ camera_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ video-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 6>;
+
+ trips {
+ video_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 7>;
+
+ trips {
+ modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Richard Acayan @ 2026-03-28 1:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
Cc: Richard Acayan
In-Reply-To: <20260328014041.83777-1-mailingradian@gmail.com>
The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
some SoCs divide the CPUs into different sizes of clusters. In SDM670,
the first 6 CPUs are in the little cluster and the next 2 are in the big
cluster. Define the clusters in the match data and define the different
cluster configuration for SDM670.
Currently, this only supports 8 CPUs and tolerates linking to any CPU in
the cluster.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
index 3d072b7a4a6d..46c1e301f6c8 100644
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -30,14 +30,17 @@
#define LMH_REG_DCVS_INTR_CLR 0x8
-#define LMH_ENABLE_ALGOS 1
-
struct lmh_hw_data {
void __iomem *base;
struct irq_domain *domain;
int irq;
};
+struct lmh_soc_data {
+ bool enable_algos;
+ u32 node_ids[8];
+};
+
static irqreturn_t lmh_handle_irq(int hw_irq, void *data)
{
struct lmh_hw_data *lmh_data = data;
@@ -100,8 +103,8 @@ static int lmh_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct device_node *cpu_node;
struct lmh_hw_data *lmh_data;
+ const struct lmh_soc_data *match_data;
int temp_low, temp_high, temp_arm, cpu_id, ret;
- unsigned int enable_alg;
u32 node_id;
if (!qcom_scm_is_available())
@@ -144,10 +147,9 @@ static int lmh_probe(struct platform_device *pdev)
* for other platforms, revisit this to check if the <cpu-id, node-id> should be part
* of a dt match table.
*/
- if (cpu_id == 0) {
- node_id = LMH_CLUSTER0_NODE_ID;
- } else if (cpu_id == 4) {
- node_id = LMH_CLUSTER1_NODE_ID;
+ match_data = of_device_get_match_data(dev);
+ if (cpu_id >= 0 && cpu_id < 8) {
+ node_id = match_data->node_ids[cpu_id];
} else {
dev_err(dev, "Wrong CPU id associated with LMh node\n");
return -EINVAL;
@@ -156,9 +158,7 @@ static int lmh_probe(struct platform_device *pdev)
if (!qcom_scm_lmh_dcvsh_available())
return -EINVAL;
- enable_alg = (uintptr_t)of_device_get_match_data(dev);
-
- if (enable_alg) {
+ if (match_data->enable_algos) {
ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_CRNT, LMH_ALGO_MODE_ENABLE, 1,
LMH_NODE_DCVS, node_id, 0);
if (ret)
@@ -231,10 +231,53 @@ static int lmh_probe(struct platform_device *pdev)
return 0;
}
+static const struct lmh_soc_data sdm670_lmh_data = {
+ .enable_algos = true,
+ .node_ids = {
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ },
+};
+
+static const struct lmh_soc_data sdm845_lmh_data = {
+ .enable_algos = true,
+ .node_ids = {
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ },
+};
+
+static const struct lmh_soc_data sm8150_lmh_data = {
+ .enable_algos = false,
+ .node_ids = {
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER0_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ LMH_CLUSTER1_NODE_ID,
+ },
+};
+
static const struct of_device_id lmh_table[] = {
- { .compatible = "qcom,sc8180x-lmh", },
- { .compatible = "qcom,sdm845-lmh", .data = (void *)LMH_ENABLE_ALGOS},
- { .compatible = "qcom,sm8150-lmh", },
+ { .compatible = "qcom,sc8180x-lmh", .data = &sm8150_lmh_data },
+ { .compatible = "qcom,sdm670-lmh", .data = &sdm670_lmh_data },
+ { .compatible = "qcom,sdm845-lmh", .data = &sdm845_lmh_data },
+ { .compatible = "qcom,sm8150-lmh", .data = &sm8150_lmh_data },
{}
};
MODULE_DEVICE_TABLE(of, lmh_table);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: thermal: lmh: Add SDM670 compatible
From: Richard Acayan @ 2026-03-28 1:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
Cc: Richard Acayan
In-Reply-To: <20260328014041.83777-1-mailingradian@gmail.com>
Document the SDM670 LMh.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
index 1175bb358382..ce72347e29d1 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
@@ -22,6 +22,9 @@ properties:
- qcom,sc8180x-lmh
- qcom,sdm845-lmh
- qcom,sm8150-lmh
+ - items:
+ - const: qcom,sdm670-lmh
+ - const: qcom,sdm845-lmh
- items:
- const: qcom,qcm2290-lmh
- const: qcom,sm8150-lmh
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: thermal: tsens: add SDM670 compatible
From: Richard Acayan @ 2026-03-28 1:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
Cc: Richard Acayan
In-Reply-To: <20260328014041.83777-1-mailingradian@gmail.com>
Add the compatible for the thermal sensors on the SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 3c5256b0cd9f..6c84f22ae322 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -71,6 +71,7 @@ properties:
- qcom,sc8180x-tsens
- qcom,sc8280xp-tsens
- qcom,sdm630-tsens
+ - qcom,sdm670-tsens
- qcom,sdm845-tsens
- qcom,sm6115-tsens
- qcom,sm6350-tsens
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/4] SDM670 Basic SoC thermal zones
From: Richard Acayan @ 2026-03-28 1:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
Cc: Richard Acayan
This adds support for the thermal sensor, for thermal-based CPU
throttling via LMh, and for thermal zones.
Changes since v3 (https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com):
- support LMh clusters starting at CPU 6 (dt-bindings tag dropped) (3/4)
Changes since v2 (https://lore.kernel.org/r/20260304014530.27775-1-mailingradian@gmail.com):
- remove cooling from memory thermal zone (3/3)
Changes since v1 (https://lore.kernel.org/r/20260210021607.12576-1-mailingradian@gmail.com):
- add review tag from Krzysztof (1/3)
- replace CPU thermal zones with lmh (2/3, 3/3)
Richard Acayan (4):
dt-bindings: thermal: tsens: add SDM670 compatible
dt-bindings: thermal: lmh: Add SDM670 compatible
thermal/qcom/lmh: support SDM670 and its CPU clusters
arm64: dts: qcom: sdm670: add thermal zones and thermal devices
.../devicetree/bindings/thermal/qcom-lmh.yaml | 3 +
.../bindings/thermal/qcom-tsens.yaml | 1 +
arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 ++++++++++++++++++
drivers/thermal/qcom/lmh.c | 69 ++-
4 files changed, 460 insertions(+), 13 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 0/7] MSM8953/SDM632 rpmpd/mss fixes
From: Dmitry Baryshkov @ 2026-03-27 20:45 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <083d2560294855857663df23e8900f9b@mainlining.org>
On Fri, Mar 27, 2026 at 09:38:20PM +0100, Barnabás Czémán wrote:
> On 2026-03-27 21:33, Dmitry Baryshkov wrote:
> > On Fri, Mar 27, 2026 at 09:11:42PM +0100, Barnabás Czémán wrote:
> > > SDM632 pm domains are different from MSM8953 because MSM8953
> > > is defining pm8953_s1 as regulator but SDM632 is defining it
> > > as pm domain.
> > >
> > > This patch series correcting the pm domains defined in rpmpd
> > > driver and splitting the MSS resources for the both SoC to match
> > > the reality.
> > >
> > > These changes was discussed in a previous threads:
> > > https://lore.kernel.org/all/2b057aa5-4416-4fd4-aeab-6bc23acbb53d@oss.qualcomm.com/
> >
> > Was 4.9 never expected to work on MSM8953? Or did it require firmware
> > changes?
> There is no official 4.9 kernel for MSM8953 devices, all of them are using
> 3.18.
> There are unofficial 4.9 ports for those devices but all of them defining s1
> as
> a regulator so the regulators were changed back like it was on 3.18.
Ack, thanks. I was looking at the msm-4.4 tree from the sdm660 branches,
which has msm8953.dtsi. Thanks for the confirmation.
> >
> > >
> > > Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> > > ---
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/7] MSM8953/SDM632 rpmpd/mss fixes
From: Barnabás Czémán @ 2026-03-27 20:38 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <lv2ali4zgsfdh54yd74cx5mvec2z5kg7v4rkayyukpjt6juyft@vzprb3rvewkm>
On 2026-03-27 21:33, Dmitry Baryshkov wrote:
> On Fri, Mar 27, 2026 at 09:11:42PM +0100, Barnabás Czémán wrote:
>> SDM632 pm domains are different from MSM8953 because MSM8953
>> is defining pm8953_s1 as regulator but SDM632 is defining it
>> as pm domain.
>>
>> This patch series correcting the pm domains defined in rpmpd
>> driver and splitting the MSS resources for the both SoC to match
>> the reality.
>>
>> These changes was discussed in a previous threads:
>> https://lore.kernel.org/all/2b057aa5-4416-4fd4-aeab-6bc23acbb53d@oss.qualcomm.com/
>
> Was 4.9 never expected to work on MSM8953? Or did it require firmware
> changes?
There is no official 4.9 kernel for MSM8953 devices, all of them are
using 3.18.
There are unofficial 4.9 ports for those devices but all of them
defining s1 as
a regulator so the regulators were changed back like it was on 3.18.
>
>>
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
^ permalink raw reply
* Re: [PATCH 4/7] arm64: dts: qcom: msm8953: fix modem pm domains
From: Dmitry Baryshkov @ 2026-03-27 20:35 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-4-6098dc997d66@mainlining.org>
On Fri, Mar 27, 2026 at 09:11:46PM +0100, Barnabás Czémán wrote:
> MSM8953 MSS is using mss-supply as regulator.
"On MSM8953 MSS regulators is controlled using the voltages rather than
performance levels. Correct DT definition and model the MSS as a
regulator rather than a power domain".
Also please squash with the changes actually making use of the
regulator.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/7] MSM8953/SDM632 rpmpd/mss fixes
From: Dmitry Baryshkov @ 2026-03-27 20:33 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
On Fri, Mar 27, 2026 at 09:11:42PM +0100, Barnabás Czémán wrote:
> SDM632 pm domains are different from MSM8953 because MSM8953
> is defining pm8953_s1 as regulator but SDM632 is defining it
> as pm domain.
>
> This patch series correcting the pm domains defined in rpmpd
> driver and splitting the MSS resources for the both SoC to match
> the reality.
>
> These changes was discussed in a previous threads:
> https://lore.kernel.org/all/2b057aa5-4416-4fd4-aeab-6bc23acbb53d@oss.qualcomm.com/
Was 4.9 never expected to work on MSM8953? Or did it require firmware
changes?
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Dmitry Baryshkov @ 2026-03-27 20:26 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-1-6098dc997d66@mainlining.org>
On Fri, Mar 27, 2026 at 09:11:43PM +0100, Barnabás Czémán wrote:
> Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
> is using mss-supply as a regulator usually it is pm8953_s1.
> Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
> as a pm domain.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> include/dt-bindings/power/qcom-rpmpd.h | 20 +++++++++++++-------
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> index 8174ceeab572..659936d6a46e 100644
> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> @@ -48,6 +48,7 @@ properties:
> - qcom,sc7280-rpmhpd
> - qcom,sc8180x-rpmhpd
> - qcom,sc8280xp-rpmhpd
> + - qcom,sdm632-rpmpd
> - qcom,sdm660-rpmpd
> - qcom,sdm670-rpmhpd
> - qcom,sdm845-rpmhpd
> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> index 4371ac941f29..2d82434b993c 100644
> --- a/include/dt-bindings/power/qcom-rpmpd.h
> +++ b/include/dt-bindings/power/qcom-rpmpd.h
> @@ -84,13 +84,11 @@
> #define QM215_VDDMX_AO MSM8917_VDDMX_AO
>
> /* MSM8953 Power Domain Indexes */
> -#define MSM8953_VDDMD 0
> -#define MSM8953_VDDMD_AO 1
> -#define MSM8953_VDDCX 2
> -#define MSM8953_VDDCX_AO 3
> -#define MSM8953_VDDCX_VFL 4
> -#define MSM8953_VDDMX 5
> -#define MSM8953_VDDMX_AO 6
> +#define MSM8953_VDDCX RPMPD_VDDCX
> +#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
> +#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
> +#define MSM8953_VDDMX RPMPD_VDDMX
> +#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
Well, no. This is an ABI break. It will make previous DT to stop from
working. You can drop unused indices, but you can not change the values
used by the existing domains.
>
> /* MSM8974 Power Domain Indexes */
> #define MSM8974_VDDCX 0
> @@ -156,6 +154,14 @@
> #define QCS404_LPIMX 5
> #define QCS404_LPIMX_VFL 6
>
> +/* SDM632 Power Domain Indexes */
> +#define SDM632_VDDMD 0
> +#define SDM632_VDDCX 1
> +#define SDM632_VDDCX_AO 2
> +#define SDM632_VDDCX_VFL 3
> +#define SDM632_VDDMX 4
> +#define SDM632_VDDMX_AO 5
Please use RPMHPD_* instead of introducing new entries.
> +
> /* SDM660 Power Domains */
> #define SDM660_VDDCX RPMPD_VDDCX
> #define SDM660_VDDCX_AO RPMPD_VDDCX_AO
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 6/7] remoteproc: qcom_q6v5_mss: Add SDM632 MSS
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
Add support for SDM632 mss, it is very similar to MSM8953 mss only
difference SDM632 is using mss-supply as pm domain.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
drivers/remoteproc/qcom_q6v5_mss.c | 47 ++++++++++++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 86edd826ede8..e63432184767 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -271,6 +271,7 @@ enum {
MSS_MSM8998,
MSS_SC7180,
MSS_SC7280,
+ MSS_SDM632,
MSS_SDM660,
MSS_SDM845,
};
@@ -760,6 +761,7 @@ static int q6v5proc_reset(struct q6v5 *qproc)
qproc->version == MSS_MSM8953 ||
qproc->version == MSS_MSM8996 ||
qproc->version == MSS_MSM8998 ||
+ qproc->version == MSS_SDM632 ||
qproc->version == MSS_SDM660) {
/* Override the ACC value if required */
@@ -770,7 +772,9 @@ static int q6v5proc_reset(struct q6v5 *qproc)
writel(QDSP6SS_ACC_OVERRIDE_VAL_9607,
qproc->reg_base + QDSP6SS_STRAP_ACC);
else if (qproc->version != MSS_MSM8909 &&
- qproc->version != MSS_MSM8953)
+ qproc->version != MSS_MSM8953 &&
+ qproc->version != MSS_SDM632)
+ /* Override the ACC value if required */
writel(QDSP6SS_ACC_OVERRIDE_VAL,
qproc->reg_base + QDSP6SS_STRAP_ACC);
@@ -830,7 +834,8 @@ static int q6v5proc_reset(struct q6v5 *qproc)
/* Turn on L1, L2, ETB and JU memories 1 at a time */
if (qproc->version == MSS_MSM8940 ||
qproc->version == MSS_MSM8953 ||
- qproc->version == MSS_MSM8996) {
+ qproc->version == MSS_MSM8996 ||
+ qproc->version == MSS_SDM632) {
mem_pwr_ctl = QDSP6SS_MEM_PWR_CTL;
i = 19;
reverse = 0;
@@ -2303,6 +2308,43 @@ static const struct rproc_hexagon_res sc7280_mss = {
.version = MSS_SC7280,
};
+static const struct rproc_hexagon_res sdm632_mss = {
+ .hexagon_mba_image = "mba.mbn",
+ .proxy_supply = (struct qcom_mss_reg_res[]) {
+ {
+ .supply = "pll",
+ .uA = 100000,
+ },
+ {}
+ },
+ .proxy_clk_names = (char*[]){
+ "xo",
+ NULL
+ },
+ .active_clk_names = (char*[]){
+ "iface",
+ "bus",
+ "mem",
+ NULL
+ },
+ .proxy_pd_names = (char*[]) {
+ "cx",
+ "mx",
+ "mss",
+ NULL
+ },
+ .need_mem_protection = false,
+ .need_pas_mem_setup = true,
+ .has_alt_reset = false,
+ .has_mba_logs = false,
+ .has_spare_reg = false,
+ .has_qaccept_regs = false,
+ .has_ext_bhs_reg = false,
+ .has_ext_cntl_regs = false,
+ .has_vq6 = false,
+ .version = MSS_SDM632,
+};
+
static const struct rproc_hexagon_res sdm660_mss = {
.hexagon_mba_image = "mba.mbn",
.proxy_clk_names = (char*[]){
@@ -2896,6 +2938,7 @@ static const struct of_device_id q6v5_of_match[] = {
{ .compatible = "qcom,msm8998-mss-pil", .data = &msm8998_mss},
{ .compatible = "qcom,sc7180-mss-pil", .data = &sc7180_mss},
{ .compatible = "qcom,sc7280-mss-pil", .data = &sc7280_mss},
+ { .compatible = "qcom,sdm632-mss-pil", .data = &sdm632_mss},
{ .compatible = "qcom,sdm660-mss-pil", .data = &sdm660_mss},
{ .compatible = "qcom,sdm845-mss-pil", .data = &sdm845_mss},
{ },
--
2.53.0
^ permalink raw reply related
* [PATCH 5/7] dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
SDM632 MSS is very similar for MSM8953 mss the difference is
mss-supply is a pm domain on SDM632, previously SDM632 MSS
was represented by MSM8953 MSS. Correct the bindings to
described it correctly.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
.../devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
index 8c0ff4dfad10..9154d2b541e8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
@@ -27,6 +27,7 @@ properties:
- qcom,msm8940-mss-pil
- qcom,msm8953-mss-pil
- qcom,msm8974-mss-pil
+ - qcom,sdm632-mss-pil
- const: qcom,q6v5-pil
description: Deprecated, prefer using qcom,msm8916-mss-pil
@@ -79,14 +80,14 @@ properties:
(not valid for qcom,msm8226-mss-pil, qcom,msm8926-mss-pil
and qcom,msm8974-mss-pil)
- description: MSS proxy power domain (control handed over after startup)
- (only valid for qcom,msm8953-mss-pil)
+ (only valid for qcom,sdm632-mss-pil)
minItems: 1
power-domain-names:
items:
- const: cx
- const: mx # not valid for qcom,msm8226-mss-pil, qcom-msm8926-mss-pil and qcom,msm8974-mss-pil
- - const: mss # only valid for qcom,msm8953-mss-pil
+ - const: mss # only valid for qcom,sdm632-mss-pil
minItems: 1
pll-supply:
@@ -214,7 +215,7 @@ allOf:
- if:
properties:
compatible:
- const: qcom,msm8953-mss-pil
+ const: qcom,sdm632-mss-pil
then:
properties:
power-domains:
@@ -236,6 +237,7 @@ allOf:
- qcom,msm8917-mss-pil
- qcom,msm8937-mss-pil
- qcom,msm8940-mss-pil
+ - qcom,msm8953-mss-pil
then:
properties:
power-domains:
@@ -282,6 +284,7 @@ allOf:
- qcom,msm8917-mss-pil
- qcom,msm8937-mss-pil
- qcom,msm8940-mss-pil
+ - qcom,msm8953-mss-pil
- qcom,msm8974-mss-pil
then:
required:
--
2.53.0
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: qcom: sdm632: Correct power domains
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
SDM632 is using different pm domains from MSM8953 override them
where it is needed.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
arch/arm64/boot/dts/qcom/sdm632.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
index 40d86d91b67f..b1dbcffd51b6 100644
--- a/arch/arm64/boot/dts/qcom/sdm632.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
@@ -87,3 +87,34 @@ opp-725000000 {
required-opps = <&rpmpd_opp_turbo>;
};
};
+
+&lpass {
+ power-domains = <&rpmpd SDM632_VDDCX>;
+ power-domain-names = "cx";
+};
+
+&mpss {
+ compatible = "qcom,sdm632-mss-pil";
+ power-domains = <&rpmpd SDM632_VDDCX>,
+ <&rpmpd SDM632_VDDMX>,
+ <&rpmpd SDM632_VDDMD>;
+ power-domain-names = "cx", "mx", "mss";
+};
+
+&rpmpd {
+ compatible = "qcom,sdm632-rpmpd";
+};
+
+&sdhc_1 {
+ power-domains = <&rpmpd SDM632_VDDCX>;
+};
+
+&sdhc_2 {
+ power-domains = <&rpmpd SDM632_VDDCX>;
+};
+
+&wcnss {
+ power-domains = <&rpmpd SDM632_VDDCX>,
+ <&rpmpd SDM632_VDDMX>;
+ power-domain-names = "cx", "mx";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 4/7] arm64: dts: qcom: msm8953: fix modem pm domains
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
MSM8953 MSS is using mss-supply as regulator.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 753167c3f861..c7dc08858d54 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -1451,9 +1451,8 @@ mpss: remoteproc@4080000 {
"handover", "stop-ack";
power-domains = <&rpmpd MSM8953_VDDCX>,
- <&rpmpd MSM8953_VDDMX>,
- <&rpmpd MSM8953_VDDMD>;
- power-domain-names = "cx", "mx","mss";
+ <&rpmpd MSM8953_VDDMX>;
+ power-domain-names = "cx", "mx";
clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
<&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
--
2.53.0
^ permalink raw reply related
* [PATCH 2/7] pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
Remove modem related pm domains from MSM8953 rpmpd because MSM8953 MSS
is using mss-supply as regulator.
Split SDM632 rpmpd from MSM8953 because SDM632 MSS is using mss-supply
as pm domain.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
drivers/pmdomain/qcom/rpmpd.c | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/pmdomain/qcom/rpmpd.c b/drivers/pmdomain/qcom/rpmpd.c
index 15a11ff282c3..cff755306759 100644
--- a/drivers/pmdomain/qcom/rpmpd.c
+++ b/drivers/pmdomain/qcom/rpmpd.c
@@ -503,19 +503,8 @@ static struct rpmpd md_s1a_corner_ao = {
.key = KEY_CORNER,
};
-static struct rpmpd md_s1a_lvl_ao;
static struct rpmpd md_s1a_lvl = {
.pd = { .name = "md", },
- .peer = &md_s1a_lvl_ao,
- .res_type = RPMPD_SMPA,
- .res_id = 1,
- .key = KEY_LEVEL,
-};
-
-static struct rpmpd md_s1a_lvl_ao = {
- .pd = { .name = "md_ao", },
- .peer = &md_s1a_lvl,
- .active_only = true,
.res_type = RPMPD_SMPA,
.res_id = 1,
.key = KEY_LEVEL,
@@ -703,13 +692,11 @@ static const struct rpmpd_desc msm8917_desc = {
};
static struct rpmpd *msm8953_rpmpds[] = {
- [MSM8953_VDDMD] = &md_s1a_lvl,
- [MSM8953_VDDMD_AO] = &md_s1a_lvl_ao,
- [MSM8953_VDDCX] = &cx_s2a_lvl,
- [MSM8953_VDDCX_AO] = &cx_s2a_lvl_ao,
- [MSM8953_VDDCX_VFL] = &cx_s2a_vfl,
- [MSM8953_VDDMX] = &mx_s7a_lvl,
- [MSM8953_VDDMX_AO] = &mx_s7a_lvl_ao,
+ [RPMPD_VDDCX] = &cx_s2a_lvl,
+ [RPMPD_VDDCX_AO] = &cx_s2a_lvl_ao,
+ [RPMPD_VDDCX_VFL] = &cx_s2a_vfl,
+ [RPMPD_VDDMX] = &mx_s7a_lvl,
+ [RPMPD_VDDMX_AO] = &mx_s7a_lvl_ao,
};
static const struct rpmpd_desc msm8953_desc = {
@@ -844,6 +831,21 @@ static const struct rpmpd_desc qm215_desc = {
.max_state = RPM_SMD_LEVEL_TURBO,
};
+static struct rpmpd *sdm632_rpmpds[] = {
+ [SDM632_VDDMD] = &md_s1a_lvl,
+ [SDM632_VDDCX] = &cx_s2a_lvl,
+ [SDM632_VDDCX_AO] = &cx_s2a_lvl_ao,
+ [SDM632_VDDCX_VFL] = &cx_s2a_vfl,
+ [SDM632_VDDMX] = &mx_s7a_lvl,
+ [SDM632_VDDMX_AO] = &mx_s7a_lvl_ao,
+};
+
+static const struct rpmpd_desc sdm632_desc = {
+ .rpmpds = sdm632_rpmpds,
+ .num_pds = ARRAY_SIZE(sdm632_rpmpds),
+ .max_state = RPM_SMD_LEVEL_TURBO,
+};
+
static struct rpmpd *sdm660_rpmpds[] = {
[RPMPD_VDDCX] = &cx_rwcx0_lvl,
[RPMPD_VDDCX_AO] = &cx_rwcx0_lvl_ao,
@@ -948,6 +950,7 @@ static const struct of_device_id rpmpd_match_table[] = {
{ .compatible = "qcom,qcm2290-rpmpd", .data = &qcm2290_desc },
{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
{ .compatible = "qcom,qm215-rpmpd", .data = &qm215_desc },
+ { .compatible = "qcom,sdm632-rpmpd", .data = &sdm632_desc },
{ .compatible = "qcom,sdm660-rpmpd", .data = &sdm660_desc },
{ .compatible = "qcom,sm6115-rpmpd", .data = &sm6115_desc },
{ .compatible = "qcom,sm6125-rpmpd", .data = &sm6125_desc },
--
2.53.0
^ permalink raw reply related
* [PATCH 0/7] MSM8953/SDM632 rpmpd/mss fixes
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
SDM632 pm domains are different from MSM8953 because MSM8953
is defining pm8953_s1 as regulator but SDM632 is defining it
as pm domain.
This patch series correcting the pm domains defined in rpmpd
driver and splitting the MSS resources for the both SoC to match
the reality.
These changes was discussed in a previous threads:
https://lore.kernel.org/all/2b057aa5-4416-4fd4-aeab-6bc23acbb53d@oss.qualcomm.com/
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
Barnabás Czémán (7):
dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953
remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953
arm64: dts: qcom: msm8953: fix modem pm domains
dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632
remoteproc: qcom_q6v5_mss: Add SDM632 MSS
arm64: dts: qcom: sdm632: Correct power domains
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
.../bindings/remoteproc/qcom,msm8916-mss-pil.yaml | 9 ++--
arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 +-
arch/arm64/boot/dts/qcom/sdm632.dtsi | 31 ++++++++++++
drivers/pmdomain/qcom/rpmpd.c | 39 ++++++++-------
drivers/remoteproc/qcom_q6v5_mss.c | 56 ++++++++++++++++++++--
include/dt-bindings/power/qcom-rpmpd.h | 20 +++++---
7 files changed, 127 insertions(+), 34 deletions(-)
---
base-commit: 8e42d2514a7e8eb8d740d0ba82339dd6c0b6463f
change-id: 20260319-sdm632-rpmpd-c0e3eb548f58
Best regards,
--
Barnabás Czémán <barnabas.czeman@mainlining.org>
^ permalink raw reply
* [PATCH 3/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
MSM8953 MSS is using mss-supply as regulator what is usually pm8953_s1.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
drivers/remoteproc/qcom_q6v5_mss.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 4e9eb5bd11fa..86edd826ede8 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -2705,6 +2705,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
},
{}
},
+ .active_supply = (struct qcom_mss_reg_res[]) {
+ {
+ .supply = "mss",
+ .uV = 1050000,
+ .uA = 100000,
+ },
+ {}
+ },
.proxy_clk_names = (char*[]){
"xo",
NULL
@@ -2718,7 +2726,6 @@ static const struct rproc_hexagon_res msm8953_mss = {
.proxy_pd_names = (char*[]) {
"cx",
"mx",
- "mss",
NULL
},
.need_mem_protection = false,
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox