I’m syncing the post with the github issue: FW16 7040 BIOS 4.03 - CPU power locked at 35W (45W with 240w PSU) max when dGPU is asleep · Issue #146 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
I discovered that the AMD SMU completely ignores the EC-adjusted SPL cap by default. It just applies its own caps, that are a lot more conservative.
To force the SMU to take into account the EC-driven settings:
Set [AMD CBS] / [SMU Common Options] / [STAPM Control] to ( by default)
Then set below:
[System Temperature Tracking] to <0> (the default). This is mandatory to prevent the SMU from overriding custom SPL values (EC or manual).
[STAPM Boost Override] to <1> so that changes to [STAPM Boost] will have an effect.
[STAPM Boost] to <0> (the default). IIRC setting it to <1> will allow the CPU to run at 45W anytime (with annoying spurious throttle during power transitions), which is probably not what you want…
[Tskin Time Constant (STAPM)] to <0> (I don’t remember if changing it makes a difference tho).
EDIT:
I identified the root cause of this issue.
When System Temperature Tracking is enabled, the AMD SMU uses the temperature sensors to dynamically adjust the STAPM LIMIT to control power consumption. By default, the sensors count STT_PCB_SENSOR_COUNT is set to 3, with the 3rd one attached to the dGPU (if you set STT_PCB_SENSOR_COUNT to 2, then the dGPU temp is ignored and the issue disappears).
However, when the dGPU is off, the temperature limit for the dGPU skin temperature sensor STT LIMIT dGPU is set to 0°C, while the measured value STT VALUE dGPU continues to stay at ambient 30-35°C. So the AMD SMU believes that the dGPU is overheating, and reduces the STAPM LIMIT accordingly, thus limiting the APU to 35W.
When the dGPU turns on, STT LIMIT dGPU is set to 51°C, which clears the overheating signal as STT VALUE dGPU becomes lower than STT LIMIT dGPU, so the AMD SMU is able to rise the STAPM LIMIT to reach the rated 54W for the APU.
To test if i could replicate it even when the dGPU is off, I first reverted back to default bios settings (to be sure that there were no interference from my specific settings), then i launched a CPU+iGPU stress test and compared the APU power limit/consumption while STT LIMIT dGPU is set to the default 0°C VS 51°C via ryzen_adj, and the results are pretty clear: STT LIMIT dGPU == 0°C => 35W /VS/ STT LIMIT dGPU == 51°C => 54W.
Then i wanted to identify which part of the firmware is responsible for controlling the STT LIMIT dGPU parameter of the AMD SMU PM table.
So i tried to see if the EC was able to alter STT LIMIT dGPU, however no AMD PMF command with the current AMD SMU firmware allows the EC to perform this specific operation (and i tested all the possible commands).
The next target is the ACPI firmware. Using acpi_call to call the method \_SB.PCI0.GP17.VGA.PX02 with a parameter 0/1 to turn the dGPU off/on, results in the STT LIMIT dGPU value changing accordingly (e.g. # echo '\_SB.PCI0.GP17.VGA.PX02 0' >/proc/acpi/call; cat /proc/acpi/call).
So far I’ve been able to track it down to a single method call, nicknamed KER-ASL-CpmWriteGpio, which presumably changes a Gpio pin:
# echo '\M010 9 1' >/proc/acpi/call => STT LIMIT dGPU = 51°C
# echo '\M010 9 0' >/proc/acpi/call => STT LIMIT dGPU = 0°C
This write seems to trigger logs in the EC, so maybe there is something else to look for in there…