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.1On 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.
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
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
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
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
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
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
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
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
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
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>
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
© 2016 - 2026 Red Hat, Inc.