[PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows

[PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows

[Daniel J Blueman]

On the Lenovo Slim 7x with Qualcomm X1 E80100, the current Windows ACPI
DSDT votes LOW_SVS (0x40) for all 7 MMCX OPP packages in the _SB.PEP0.G0MD
F-state EXIT package:

"FSTATE",
Zero,
Package (...)
{
   "EXIT",
   Package (0x02)
   {
       "NPARESOURCE",
       Package (0x03)
       {
           One,
           "/arc/client/rail_mmcx",
           0x40
       }
   },
   ...
},

Apply the same in Linux for power saving opportunity. Validated on Lenovo
Slim7x across daily workloads over 2 weeks with the internal 2944x1840
panel @ 90Hz and a 3840x2160 @ 60Hz monitor over USB-C MST DP alt.

Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..bdd9e7e0768c 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5657,22 +5657,22 @@ opp-200000000 {
 
 					opp-325000000 {
 						opp-hz = /bits/ 64 <325000000>;
-						required-opps = <&rpmhpd_opp_svs>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-375000000 {
 						opp-hz = /bits/ 64 <375000000>;
-						required-opps = <&rpmhpd_opp_svs_l1>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-514000000 {
 						opp-hz = /bits/ 64 <514000000>;
-						required-opps = <&rpmhpd_opp_nom>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-575000000 {
 						opp-hz = /bits/ 64 <575000000>;
-						required-opps = <&rpmhpd_opp_nom_l1>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 				};
 			};
-- 
2.53.0

Re: [PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The commit incorrectly applies a Windows ACPI sleep/idle-state voltage vote as the active-state voltage requirement for all MDP MMCX operating frequencies, severely breaking the DVFS curve and risking hardware instability.
- [Medium] Board-specific power optimizations derived from a single device's ACPI tables are inappropriately applied globally to the SoC base device tree.
- [Low] The commit message claims to update 7 MMCX OPP packages, but the implementation differs.
--

commit 4a04fd599f313f3ace74e7b33f9120e9295f92fa
Author: Daniel J Blueman <daniel@quora.org>
arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows

This commit updates the MDP MMCX operating performance points to use the
LOW_SVS voltage corner based on Windows ACPI DSDT F-state tables.

> On the Lenovo Slim 7x with Qualcomm X1 E80100, the current Windows ACPI
> DSDT votes LOW_SVS (0x40) for all 7 MMCX OPP packages in the _SB.PEP0.G0MD

[Severity: Low]
Is this description accurate? The commit message states it updates 7 MMCX OPP
packages, but the mdp_opp_table in hamoa.dtsi only contains 5 OPP entries and
this patch modifies 4 of them.

> F-state EXIT package:
> 
> "FSTATE",
> Zero,
> Package (...)
> {
>    "EXIT",
>    Package (0x02)
>    {
>        "NPARESOURCE",
>        Package (0x03)
>        {
>            One,
>            "/arc/client/rail_mmcx",
>            0x40
>        }
>    },
>    ...
> },
> 
> Apply the same in Linux for power saving opportunity.

[Severity: High]
Does this apply an idle state voltage requirement to active operating
performance points?

The F-state EXIT package defines the power requirements when a device
transitions out of a functional state into idle. By mapping this low power
state to active OPPs up to 575MHz, could this regression severely undervolt the
MDP?

During the multi-monitor high-resolution validation, the DisplayPort
controllers may have independently cast high voltage votes on the shared
RPMHPD_MMCX power domain, masking the MDP's lower vote. Would a user
connecting a low-resolution display experience regressions like hard lockups or
visual artifacts due to this voltage drop?

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -5657,22 +5657,22 @@ opp-200000000 {
>  
>  					opp-325000000 {
>  						opp-hz = /bits/ 64 <325000000>;
> -						required-opps = <&rpmhpd_opp_svs>;
> +						required-opps = <&rpmhpd_opp_low_svs>;
>  					};

[Severity: Medium]
Since this voltage optimization was derived from the ACPI tables of the Lenovo
Slim 7x, should it be applied as an override in the board-specific .dts file
rather than globally in the SoC base device tree?

Could applying this to the base hamoa.dtsi cause regressions across all
Snapdragon X Elite/Plus devices, which might have different power delivery
designs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524115704.9442-1-daniel@quora.org?part=1

Re: [PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows

[Konrad Dybcio]

On 5/24/26 1:57 PM, Daniel J Blueman wrote:
> On the Lenovo Slim 7x with Qualcomm X1 E80100, the current Windows ACPI
> DSDT votes LOW_SVS (0x40) for all 7 MMCX OPP packages in the _SB.PEP0.G0MD
> F-state EXIT package:
> 
> "FSTATE",
> Zero,
> Package (...)
> {
>    "EXIT",
>    Package (0x02)
>    {
>        "NPARESOURCE",
>        Package (0x03)
>        {
>            One,
>            "/arc/client/rail_mmcx",
>            0x40
>        }
>    },
>    ...
> },
> 
> Apply the same in Linux for power saving opportunity. Validated on Lenovo
> Slim7x across daily workloads over 2 weeks with the internal 2944x1840
> panel @ 90Hz and a 3840x2160 @ 60Hz monitor over USB-C MST DP alt.

This ""works"" because the DP host holds a higher vote on the same rail

The max frequency for the MDP core clock at LOWSVS is 200 MHz, so this
patch is incorrect

Konrad