[PATCH 0/2] qcom: SM8750: Enable CPUFreq support

[PATCH 0/2] qcom: SM8750: Enable CPUFreq support

[Jagadeesh Kona]

This series enables CPUFreq support on the SM8750 SoC
using the SCMI perf protocol.

Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
---
Jagadeesh Kona (2):
      dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller
      arm64: dts: qcom: SM8750: Enable CPUFreq support

 .../bindings/mailbox/qcom,cpucp-mbox.yaml          |  1 +
 arch/arm64/boot/dts/qcom/sm8750.dtsi               | 73 +++++++++++++++++-----
 2 files changed, 58 insertions(+), 16 deletions(-)
---
base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
change-id: 20251210-sm8750-cpufreq-733ed7e5a3ed

Best regards,
-- 
Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>

[PATCH 1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller

[Jagadeesh Kona]

Document CPU Control Processor (CPUCP) mailbox controller for Qualcomm
SM8750 SoCs. It is software compatible with X1E80100 CPUCP mailbox
controller hence fallback to it.

Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
index 9122c3d2dc30fade96eaf54aee41f890327deb6c..9d99af46e531aec615f91f1c139ce4fa482e41c3 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
@@ -19,6 +19,7 @@ properties:
       - items:
           - enum:
               - qcom,glymur-cpucp-mbox
+              - qcom,sm8750-cpucp-mbox
           - const: qcom,x1e80100-cpucp-mbox
       - enum:
           - qcom,x1e80100-cpucp-mbox

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller

[Rob Herring (Arm)]

On Thu, 11 Dec 2025 00:32:23 +0530, Jagadeesh Kona wrote:
> Document CPU Control Processor (CPUCP) mailbox controller for Qualcomm
> SM8750 SoCs. It is software compatible with X1E80100 CPUCP mailbox
> controller hence fallback to it.
> 
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller

[Jassi Brar]

On Wed, Dec 10, 2025 at 1:02 PM Jagadeesh Kona
<jagadeesh.kona@oss.qualcomm.com> wrote:
>
> Document CPU Control Processor (CPUCP) mailbox controller for Qualcomm
> SM8750 SoCs. It is software compatible with X1E80100 CPUCP mailbox
> controller hence fallback to it.
>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> index 9122c3d2dc30fade96eaf54aee41f890327deb6c..9d99af46e531aec615f91f1c139ce4fa482e41c3 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> @@ -19,6 +19,7 @@ properties:
>        - items:
>            - enum:
>                - qcom,glymur-cpucp-mbox
> +              - qcom,sm8750-cpucp-mbox
>            - const: qcom,x1e80100-cpucp-mbox
>        - enum:
>            - qcom,x1e80100-cpucp-mbox
>
> --
> 2.34.1
>
Applied, after trivial rebase on top of "dt-bindings: mailbox: qcom:
Add CPUCP mailbox controller bindings for Kaanapali"

Thanks

Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller

[Krzysztof Kozlowski]

On 18/01/2026 20:40, Jassi Brar wrote:
> On Wed, Dec 10, 2025 at 1:02 PM Jagadeesh Kona
> <jagadeesh.kona@oss.qualcomm.com> wrote:
>>
>> Document CPU Control Processor (CPUCP) mailbox controller for Qualcomm
>> SM8750 SoCs. It is software compatible with X1E80100 CPUCP mailbox
>> controller hence fallback to it.
>>
>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
>> index 9122c3d2dc30fade96eaf54aee41f890327deb6c..9d99af46e531aec615f91f1c139ce4fa482e41c3 100644
>> --- a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
>> +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
>> @@ -19,6 +19,7 @@ properties:
>>        - items:
>>            - enum:
>>                - qcom,glymur-cpucp-mbox
>> +              - qcom,sm8750-cpucp-mbox
>>            - const: qcom,x1e80100-cpucp-mbox
>>        - enum:
>>            - qcom,x1e80100-cpucp-mbox
>>
>> --
>> 2.34.1
>>
> Applied, after trivial rebase on top of "dt-bindings: mailbox: qcom:
> Add CPUCP mailbox controller bindings for Kaanapali"

Both patches were already applied (see other emails in this thread).
Please drop.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller

[Jassi Brar]

On Tue, Jan 20, 2026 at 4:22 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 18/01/2026 20:40, Jassi Brar wrote:
> > On Wed, Dec 10, 2025 at 1:02 PM Jagadeesh Kona
> > <jagadeesh.kona@oss.qualcomm.com> wrote:
> >>
> >> Document CPU Control Processor (CPUCP) mailbox controller for Qualcomm
> >> SM8750 SoCs. It is software compatible with X1E80100 CPUCP mailbox
> >> controller hence fallback to it.
> >>
> >> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> >> ---
> >>  Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> >> index 9122c3d2dc30fade96eaf54aee41f890327deb6c..9d99af46e531aec615f91f1c139ce4fa482e41c3 100644
> >> --- a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> >> +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
> >> @@ -19,6 +19,7 @@ properties:
> >>        - items:
> >>            - enum:
> >>                - qcom,glymur-cpucp-mbox
> >> +              - qcom,sm8750-cpucp-mbox
> >>            - const: qcom,x1e80100-cpucp-mbox
> >>        - enum:
> >>            - qcom,x1e80100-cpucp-mbox
> >>
> >> --
> >> 2.34.1
> >>
> > Applied, after trivial rebase on top of "dt-bindings: mailbox: qcom:
> > Add CPUCP mailbox controller bindings for Kaanapali"
>
> Both patches were already applied (see other emails in this thread).
> Please drop.
>
Dropped.
thnx.

[PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Jagadeesh Kona]

Add the cpucp mailbox, sram and SCMI nodes required to enable
the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.

Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 73 ++++++++++++++++++++++++++++--------
 1 file changed, 57 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 3f0b57f428bbb388521c27d9ae96bbef3d62b2e2..ae4d768b68721c5e35aa80d1aa63a02289b72ce6 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -35,8 +35,8 @@ cpu0: cpu@0 {
 			reg = <0x0 0x0>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd0>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd0>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 
 			l2_0: l2-cache {
 				compatible = "cache";
@@ -51,8 +51,8 @@ cpu1: cpu@100 {
 			reg = <0x0 0x100>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd1>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd1>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu2: cpu@200 {
@@ -61,8 +61,8 @@ cpu2: cpu@200 {
 			reg = <0x0 0x200>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd2>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd2>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu3: cpu@300 {
@@ -71,8 +71,8 @@ cpu3: cpu@300 {
 			reg = <0x0 0x300>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd3>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd3>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu4: cpu@400 {
@@ -81,8 +81,8 @@ cpu4: cpu@400 {
 			reg = <0x0 0x400>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd4>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd4>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu5: cpu@500 {
@@ -91,8 +91,8 @@ cpu5: cpu@500 {
 			reg = <0x0 0x500>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
-			power-domains = <&cpu_pd5>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd5>, <&scmi_dvfs 0>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu6: cpu@10000 {
@@ -101,8 +101,8 @@ cpu6: cpu@10000 {
 			reg = <0x0 0x10000>;
 			enable-method = "psci";
 			next-level-cache = <&l2_1>;
-			power-domains = <&cpu_pd6>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd6>, <&scmi_dvfs 1>;
+			power-domain-names = "psci", "perf";
 
 			l2_1: l2-cache {
 				compatible = "cache";
@@ -117,8 +117,8 @@ cpu7: cpu@10100 {
 			reg = <0x0 0x10100>;
 			enable-method = "psci";
 			next-level-cache = <&l2_1>;
-			power-domains = <&cpu_pd7>;
-			power-domain-names = "psci";
+			power-domains = <&cpu_pd7>, <&scmi_dvfs 1>;
+			power-domain-names = "psci", "perf";
 		};
 
 		cpu-map {
@@ -206,6 +206,21 @@ scm: scm {
 			interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
 		};
+
+		scmi {
+			compatible = "arm,scmi";
+			mboxes = <&cpucp_mbox 0>, <&cpucp_mbox 2>;
+			mbox-names = "tx", "rx";
+			shmem = <&cpu_scp_lpri0>, <&cpu_scp_lpri1>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			scmi_dvfs: protocol@13 {
+				reg = <0x13>;
+				#power-domain-cells = <1>;
+			};
+		};
 	};
 
 	clk_virt: interconnect-0 {
@@ -3743,6 +3758,13 @@ opp-403000000 {
 			};
 		};
 
+		cpucp_mbox: mailbox@16430000 {
+			compatible = "qcom,sm8750-cpucp-mbox", "qcom,x1e80100-cpucp-mbox";
+			reg = <0x0 0x16430000 0x0 0x8000>, <0x0 0x17830000 0x0 0x8000>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			#mbox-cells = <1>;
+		};
+
 		apps_rsc: rsc@16500000 {
 			compatible = "qcom,rpmh-rsc";
 			reg = <0x0 0x16500000 0x0 0x10000>,
@@ -3954,6 +3976,25 @@ frame@1680d000 {
 			};
 		};
 
+		sram: sram@17b4e000 {
+			compatible = "mmio-sram";
+			reg = <0x0 0x17b4e000 0x0 0x400>;
+
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0x17b4e000 0x400>;
+
+			cpu_scp_lpri0: scp-sram-section@0 {
+				compatible = "arm,scmi-shmem";
+				reg = <0x0 0x200>;
+			};
+
+			cpu_scp_lpri1: scp-sram-section@200 {
+				compatible = "arm,scmi-shmem";
+				reg = <0x200 0x200>;
+			};
+		};
+
 		/* cluster0 */
 		pmu@240b3400 {
 			compatible = "qcom,sm8750-cpu-bwmon", "qcom,sdm845-bwmon";

-- 
2.34.1

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Dmitry Baryshkov]

On Thu, Dec 11, 2025 at 12:32:24AM +0530, Jagadeesh Kona wrote:
> Add the cpucp mailbox, sram and SCMI nodes required to enable
> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
> 
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/sm8750.dtsi | 73 ++++++++++++++++++++++++++++--------
>  1 file changed, 57 insertions(+), 16 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Abel Vesa]

On 25-12-11 00:32:24, Jagadeesh Kona wrote:
> Add the cpucp mailbox, sram and SCMI nodes required to enable
> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
> 
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>

Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Sibi Sankar]

On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
> Add the cpucp mailbox, sram and SCMI nodes required to enable
> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---
>   arch/arm64/boot/dts/qcom/sm8750.dtsi | 73 ++++++++++++++++++++++++++++--------
>   1 file changed, 57 insertions(+), 16 deletions(-)

Reviewed-by: Sibi Sankar<sibi.sankar@oss.qualcomm.com>

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Konrad Dybcio]

On 12/10/25 8:02 PM, Jagadeesh Kona wrote:
> Add the cpucp mailbox, sram and SCMI nodes required to enable
> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
> 
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Akhil P Oommen]

On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
> Add the cpucp mailbox, sram and SCMI nodes required to enable
> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
> 
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>

Just curious, does this patch enable thermal mitigation for CPU clusters
too?

-Akhil.

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Konrad Dybcio]

On 1/19/26 8:00 PM, Akhil P Oommen wrote:
> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>
>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> 
> Just curious, does this patch enable thermal mitigation for CPU clusters
> too?

If nothing changed, we have lets-not-explode type mitigations via LMH,
but lets-not-burn-the-user would require a skin temp sensor to be
wired up, which then could be used to enable some cooling action

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Akhil P Oommen]

On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>
>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>
>> Just curious, does this patch enable thermal mitigation for CPU clusters
>> too?
> 
> If nothing changed, we have lets-not-explode type mitigations via LMH,
> but lets-not-burn-the-user would require a skin temp sensor to be
> wired up, which then could be used to enable some cooling action

In some chipsets, I have noticed that the gpu cooling device throttles
GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
temperature tripping up GPU Tsens.

So, I am wondering if there are any additional CPU cooling related
changes required to get a reasonable overall performance under thermal
constraints.

-Akhil.

> 
> Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Konrad Dybcio]

On 1/20/26 12:25 PM, Akhil P Oommen wrote:
> On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
>> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>>
>>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>>
>>> Just curious, does this patch enable thermal mitigation for CPU clusters
>>> too?
>>
>> If nothing changed, we have lets-not-explode type mitigations via LMH,
>> but lets-not-burn-the-user would require a skin temp sensor to be
>> wired up, which then could be used to enable some cooling action
> 
> In some chipsets, I have noticed that the gpu cooling device throttles
> GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
> unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
> temperature tripping up GPU Tsens.
> 
> So, I am wondering if there are any additional CPU cooling related
> changes required to get a reasonable overall performance under thermal
> constraints.

Yes, something like the aforementioned skin-temp sensor at least..

Today Linux will not throttle the CPUs at all (they're not even declared
as cooling devices) and we sorta agreed that in general it's a good thing
(tm), because otherwise we'd be coding in a cooling profile into the SoC
DTSI without taking into account the cooling capabilities of a given end
device (i.e. in an extreme case, a PC with SM8650 with a cooler that's
3kg of aluminium vs a Steam Frame headset where the SoC is centimeters
away from your face)

Currently, we have cooling policies for devices with fans and the only
other action is based on a skin temperature sensor (sc8280xp + x13s).
Everything else is left up to the LMH defaults. AFAIK work is ongoing to
create a more informed solution, that would have to (quite obviously)
live in userland.

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Akhil P Oommen]

On 1/20/2026 8:13 PM, Konrad Dybcio wrote:
> On 1/20/26 12:25 PM, Akhil P Oommen wrote:
>> On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
>>> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>>>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>>>
>>>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>>>
>>>> Just curious, does this patch enable thermal mitigation for CPU clusters
>>>> too?
>>>
>>> If nothing changed, we have lets-not-explode type mitigations via LMH,
>>> but lets-not-burn-the-user would require a skin temp sensor to be
>>> wired up, which then could be used to enable some cooling action
>>
>> In some chipsets, I have noticed that the gpu cooling device throttles
>> GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
>> unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
>> temperature tripping up GPU Tsens.
>>
>> So, I am wondering if there are any additional CPU cooling related
>> changes required to get a reasonable overall performance under thermal
>> constraints.
> 
> Yes, something like the aforementioned skin-temp sensor at least..

I suppose this sensor is off-chip and slow to react.

> 
> Today Linux will not throttle the CPUs at all (they're not even declared
> as cooling devices) and we sorta agreed that in general it's a good thing
> (tm), because otherwise we'd be coding in a cooling profile into the SoC
> DTSI without taking into account the cooling capabilities of a given end
> device (i.e. in an extreme case, a PC with SM8650 with a cooler that's
> 3kg of aluminium vs a Steam Frame headset where the SoC is centimeters
> away from your face)
> 
> Currently, we have cooling policies for devices with fans and the only
> other action is based on a skin temperature sensor (sc8280xp + x13s).
> Everything else is left up to the LMH defaults. AFAIK work is ongoing to
> create a more informed solution, that would have to (quite obviously)
> live in userland.

I can understand that the skin-temp based mitigation is influenced by
various design decision outside of the SoC die. But I think there should
an on-chip sensor based mitigation which is fast and usually for a short
duration which helps to avoid extreme temperature or violating the
maximum operating point of the chipset. I guess it should depend only on
the SoC characteristics as it is a last resort. It may be implemented in
SW (like cooling device for Adreno GPU) or in HW. Probably the LMH
hardware you mentioned offers this functionality for CPU clusters. I
have no clue. :(

I am hoping that if this on-chip mitigation is enabled and wired up
correctly for CPU clusters (probably DDR too), it would reduce the
unnecessary thermal trips on GPU Tsens and help to reach a performance
equilibrium which is reasonably good.

-Akhil.

> 
> Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Konrad Dybcio]

On 1/20/26 9:54 PM, Akhil P Oommen wrote:
> On 1/20/2026 8:13 PM, Konrad Dybcio wrote:
>> On 1/20/26 12:25 PM, Akhil P Oommen wrote:
>>> On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
>>>> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>>>>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>>>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>>>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>>>>
>>>>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>>>>
>>>>> Just curious, does this patch enable thermal mitigation for CPU clusters
>>>>> too?
>>>>
>>>> If nothing changed, we have lets-not-explode type mitigations via LMH,
>>>> but lets-not-burn-the-user would require a skin temp sensor to be
>>>> wired up, which then could be used to enable some cooling action
>>>
>>> In some chipsets, I have noticed that the gpu cooling device throttles
>>> GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
>>> unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
>>> temperature tripping up GPU Tsens.
>>>
>>> So, I am wondering if there are any additional CPU cooling related
>>> changes required to get a reasonable overall performance under thermal
>>> constraints.
>>
>> Yes, something like the aforementioned skin-temp sensor at least..
> 
> I suppose this sensor is off-chip and slow to react.

Yes, this would be placed somewhere on the chassis of the device to
reflect the actual temperature that the user could experience (since
there are regulations about maximum values of that)

>> Today Linux will not throttle the CPUs at all (they're not even declared
>> as cooling devices) and we sorta agreed that in general it's a good thing
>> (tm), because otherwise we'd be coding in a cooling profile into the SoC
>> DTSI without taking into account the cooling capabilities of a given end
>> device (i.e. in an extreme case, a PC with SM8650 with a cooler that's
>> 3kg of aluminium vs a Steam Frame headset where the SoC is centimeters
>> away from your face)
>>
>> Currently, we have cooling policies for devices with fans and the only
>> other action is based on a skin temperature sensor (sc8280xp + x13s).
>> Everything else is left up to the LMH defaults. AFAIK work is ongoing to
>> create a more informed solution, that would have to (quite obviously)
>> live in userland.
> 
> I can understand that the skin-temp based mitigation is influenced by
> various design decision outside of the SoC die. But I think there should
> an on-chip sensor based mitigation which is fast and usually for a short
> duration which helps to avoid extreme temperature or violating the
> maximum operating point of the chipset. I guess it should depend only on
> the SoC characteristics as it is a last resort. It may be implemented in
> SW (like cooling device for Adreno GPU) or in HW. Probably the LMH
> hardware you mentioned offers this functionality for CPU clusters. I
> have no clue. :(

Yes, the CPUs are covered.

> I am hoping that if this on-chip mitigation is enabled and wired up
> correctly for CPU clusters (probably DDR too), it would reduce the
> unnecessary thermal trips on GPU Tsens and help to reach a performance
> equilibrium which is reasonably good.

Today, the OS is unaware that it can throttle anything else than the
GPU, so in its view that's the reasonable step to take. Further, any
device it knows how to throttle, it'll do so in a very jittery fashion
where it crosses the threshold, gets slowed down, cools a bit, gets
unthrottled, heats back up, rinse and repeat (because the cooling
solution of almost any form-factor is not capable of sustaining a
100%usage workload for long)

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Akhil P Oommen]

On 1/21/2026 5:06 PM, Konrad Dybcio wrote:
> On 1/20/26 9:54 PM, Akhil P Oommen wrote:
>> On 1/20/2026 8:13 PM, Konrad Dybcio wrote:
>>> On 1/20/26 12:25 PM, Akhil P Oommen wrote:
>>>> On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
>>>>> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>>>>>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>>>>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>>>>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>>>>>
>>>>>> Just curious, does this patch enable thermal mitigation for CPU clusters
>>>>>> too?
>>>>>
>>>>> If nothing changed, we have lets-not-explode type mitigations via LMH,
>>>>> but lets-not-burn-the-user would require a skin temp sensor to be
>>>>> wired up, which then could be used to enable some cooling action
>>>>
>>>> In some chipsets, I have noticed that the gpu cooling device throttles
>>>> GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
>>>> unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
>>>> temperature tripping up GPU Tsens.
>>>>
>>>> So, I am wondering if there are any additional CPU cooling related
>>>> changes required to get a reasonable overall performance under thermal
>>>> constraints.
>>>
>>> Yes, something like the aforementioned skin-temp sensor at least..
>>
>> I suppose this sensor is off-chip and slow to react.
> 
> Yes, this would be placed somewhere on the chassis of the device to
> reflect the actual temperature that the user could experience (since
> there are regulations about maximum values of that)
> 
>>> Today Linux will not throttle the CPUs at all (they're not even declared
>>> as cooling devices) and we sorta agreed that in general it's a good thing
>>> (tm), because otherwise we'd be coding in a cooling profile into the SoC
>>> DTSI without taking into account the cooling capabilities of a given end
>>> device (i.e. in an extreme case, a PC with SM8650 with a cooler that's
>>> 3kg of aluminium vs a Steam Frame headset where the SoC is centimeters
>>> away from your face)
>>>
>>> Currently, we have cooling policies for devices with fans and the only
>>> other action is based on a skin temperature sensor (sc8280xp + x13s).
>>> Everything else is left up to the LMH defaults. AFAIK work is ongoing to
>>> create a more informed solution, that would have to (quite obviously)
>>> live in userland.
>>
>> I can understand that the skin-temp based mitigation is influenced by
>> various design decision outside of the SoC die. But I think there should
>> an on-chip sensor based mitigation which is fast and usually for a short
>> duration which helps to avoid extreme temperature or violating the
>> maximum operating point of the chipset. I guess it should depend only on
>> the SoC characteristics as it is a last resort. It may be implemented in
>> SW (like cooling device for Adreno GPU) or in HW. Probably the LMH
>> hardware you mentioned offers this functionality for CPU clusters. I
>> have no clue. :(
> 
> Yes, the CPUs are covered.

Does this LMH based thermal migitation require any initialization from
Linux? If yes, could you please share a link to a patch which enables it
for any recent chipset for my reference?

-Akhil.

> 
>> I am hoping that if this on-chip mitigation is enabled and wired up
>> correctly for CPU clusters (probably DDR too), it would reduce the
>> unnecessary thermal trips on GPU Tsens and help to reach a performance
>> equilibrium which is reasonably good.
> 
> Today, the OS is unaware that it can throttle anything else than the
> GPU, so in its view that's the reasonable step to take. Further, any
> device it knows how to throttle, it'll do so in a very jittery fashion
> where it crosses the threshold, gets slowed down, cools a bit, gets
> unthrottled, heats back up, rinse and repeat (because the cooling
> solution of almost any form-factor is not capable of sustaining a
> 100%usage workload for long)
> 
> Konrad

Re: [PATCH 2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support

[Konrad Dybcio]

On 1/21/26 1:47 PM, Akhil P Oommen wrote:
> On 1/21/2026 5:06 PM, Konrad Dybcio wrote:
>> On 1/20/26 9:54 PM, Akhil P Oommen wrote:
>>> On 1/20/2026 8:13 PM, Konrad Dybcio wrote:
>>>> On 1/20/26 12:25 PM, Akhil P Oommen wrote:
>>>>> On 1/20/2026 3:44 PM, Konrad Dybcio wrote:
>>>>>> On 1/19/26 8:00 PM, Akhil P Oommen wrote:
>>>>>>> On 12/11/2025 12:32 AM, Jagadeesh Kona wrote:
>>>>>>>> Add the cpucp mailbox, sram and SCMI nodes required to enable
>>>>>>>> the CPUFreq support using the SCMI perf protocol on SM8750 SoCs.
>>>>>>>>
>>>>>>>> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
>>>>>>>
>>>>>>> Just curious, does this patch enable thermal mitigation for CPU clusters
>>>>>>> too?
>>>>>>
>>>>>> If nothing changed, we have lets-not-explode type mitigations via LMH,
>>>>>> but lets-not-burn-the-user would require a skin temp sensor to be
>>>>>> wired up, which then could be used to enable some cooling action
>>>>>
>>>>> In some chipsets, I have noticed that the gpu cooling device throttles
>>>>> GPU to the lowest OPP even with not-so-heavy GPU workloads, making it
>>>>> unusable-ly slow. My hypothesis was that it was due to unmitigated CPU
>>>>> temperature tripping up GPU Tsens.
>>>>>
>>>>> So, I am wondering if there are any additional CPU cooling related
>>>>> changes required to get a reasonable overall performance under thermal
>>>>> constraints.
>>>>
>>>> Yes, something like the aforementioned skin-temp sensor at least..
>>>
>>> I suppose this sensor is off-chip and slow to react.
>>
>> Yes, this would be placed somewhere on the chassis of the device to
>> reflect the actual temperature that the user could experience (since
>> there are regulations about maximum values of that)
>>
>>>> Today Linux will not throttle the CPUs at all (they're not even declared
>>>> as cooling devices) and we sorta agreed that in general it's a good thing
>>>> (tm), because otherwise we'd be coding in a cooling profile into the SoC
>>>> DTSI without taking into account the cooling capabilities of a given end
>>>> device (i.e. in an extreme case, a PC with SM8650 with a cooler that's
>>>> 3kg of aluminium vs a Steam Frame headset where the SoC is centimeters
>>>> away from your face)
>>>>
>>>> Currently, we have cooling policies for devices with fans and the only
>>>> other action is based on a skin temperature sensor (sc8280xp + x13s).
>>>> Everything else is left up to the LMH defaults. AFAIK work is ongoing to
>>>> create a more informed solution, that would have to (quite obviously)
>>>> live in userland.
>>>
>>> I can understand that the skin-temp based mitigation is influenced by
>>> various design decision outside of the SoC die. But I think there should
>>> an on-chip sensor based mitigation which is fast and usually for a short
>>> duration which helps to avoid extreme temperature or violating the
>>> maximum operating point of the chipset. I guess it should depend only on
>>> the SoC characteristics as it is a last resort. It may be implemented in
>>> SW (like cooling device for Adreno GPU) or in HW. Probably the LMH
>>> hardware you mentioned offers this functionality for CPU clusters. I
>>> have no clue. :(
>>
>> Yes, the CPUs are covered.
> 
> Does this LMH based thermal migitation require any initialization from
> Linux? If yes, could you please share a link to a patch which enables it
> for any recent chipset for my reference?

It used to, see drivers/thermal/qcom/lmh.c

I believe it went away roughly with 8250 where the firmware now takes
care of all that.

FYI I think it first appeared with 8994

Konrad

Re: (subset) [PATCH 0/2] qcom: SM8750: Enable CPUFreq support

[Bjorn Andersson]

On Thu, 11 Dec 2025 00:32:22 +0530, Jagadeesh Kona wrote:
> This series enables CPUFreq support on the SM8750 SoC
> using the SCMI perf protocol.
> 
> 

Applied, thanks!

[1/2] dt-bindings: mailbox: qcom: Document SM8750 CPUCP mailbox controller
      commit: 65ce09d2f164a3d91b5802ecd0783aa2c9a208c0
[2/2] arm64: dts: qcom: SM8750: Enable CPUFreq support
      commit: deed369e067b8406714154a6678a3e3d9b1c1131

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>