arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows
PATCH 1/1 arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows
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.
--- arch/arm64/boot/dts/qcom/hamoa.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/qcom/hamoa.dtsi +4 -4
@@ -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>; }; }; };
Signature · 1 line
2.53.0
[email protected]
AI reviewThank 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…
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 <[email protected]>
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.
Quoted 2 lines
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.
Quoted 20 lines
F-state EXIT package:
"FSTATE",
Zero,
Package (...){ "EXIT", Package (0x02) { "NPARESOURCE", Package (0x03) { One, "/arc/client/rail_mmcx", 0x40 } }, ... },
Quoted 1 line
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?
arch/arm64/boot/dts/qcom/hamoa.dtsi opp-200000000 { · line 5661
Quoted 10 lines
arch/arm64/boot/dts/qcom/hamoa.dtsi +1
-1@@ -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?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Quoted 22 lines · 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 } }, ... },
Quoted 3 lines
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