-
Notifications
You must be signed in to change notification settings - Fork 123
Supported Models
- ✅ Supported
- ☑ Supported, but not tested, help needed
- ⚠ Supported, but no effect (some does at least change the PM Table reading)
- ⛔ Not Supported
Raven | Picasso | Dali | Renoir | Lucienne | Cezanne | Rembrandt | |
---|---|---|---|---|---|---|---|
stapm-limit | ✅ | ✅ | ☑ | ⚠ | ⚠ | ⚠ | ☑ |
fast-limit | ✅ | ✅ | ☑ | ✅ | ✅ | ✅ | ☑ |
slow-limit | ✅ | ✅ | ☑ | ✅ | ✅ | ✅ | ☑ |
slow-time | ✅ | ✅ | ☑ | ✅ | ✅ | ✅ | ☑ |
stapm-time | ✅ | ✅ | ☑ | ⚠ | ⚠ | ⚠ | ☑ |
tctl-temp | ✅ | ✅ | ☑ | ✅ | ✅ | ✅ | ☑ |
vrm-current | ✅ | ☑ | ☑ | ✅ | ✅ | ✅ | ☑ |
vrmsoc-current | ✅ | ☑ | ☑ | ✅ | ✅ | ✅ | ☑ |
vrmmax-current | ✅ | ☑ | ☑ | ✅ | ✅ | ✅ | ☑ |
vrmsocmax-current | ✅ | ☑ | ☑ | ✅ | ✅ | ✅ | ☑ |
psi0-current | ✅ | ☑ | ☑ | ⚠ | ☑ | ☑ | ☑ |
psi0soc-current | ✅ | ☑ | ☑ | ⚠ | ☑ | ☑ | ☑ |
max-socclk-frequency | ☑ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
min-socclk-frequency | ☑ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
max-fclk-frequency | ✅ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
min-fclk-frequency | ✅ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
max-vcn | ☑ | ⛔ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
min-vcn | ☑ | ⛔ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
max-lclk | ☑ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
min-lclk | ☑ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
max-gfxclk | ⚠ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
min-gfxclk | ⚠ | ☑ | ☑ | ⛔ | ⛔ | ⛔ | ⛔ |
prochot-deassertion-ramp | ☑ | ☑ | ☑ | ✅ | ☑ | ✅ | ☑ |
apu-skin-temp | ⛔ | ⛔ | ⛔ | ⚠ | ☑ | ⚠ | ☑ |
dgpu-skin-temp | ⛔ | ⛔ | ⛔ | ⚠ | ☑ | ⚠ | ☑ |
apu-slow-limit | ⛔ | ⛔ | ⛔ | ⚠ | ☑ | ⚠ | ☑ |
skin-temp-limit | ⛔ | ⛔ | ⛔ | ⚠ | ☑ | ⚠ | ☑ |
power-saving | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ☑ |
max-performance | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ☑ |
- command is accepted
- no value change can be found or measured on 2500U
- on some devices it will work if you avoid using frequencies multiple of 10. Play around with values like 917, and it may work.
Only usable if STTv2 is disabled, if STTv2 is enabled:
- command is accepted
- value does change, but gets directly overwritten by STTv2 (fast-limit or skin-temp-limit)
Only usable if STTv2 is disabled, if STTv2 is enabled:
- command is accepted
- no value change
Only usable if STTv2 is enabled, If STTv2 is disabled:
- command is accepted
- limit does change, but has no effect because usage value is not reported
- command is accepted
- value does change, default limit is 0 and the psi0 usage does always report 0 on PRO 4750U
-
command is accepted
-
value does change, but we cannot see any difference on PRO 4750U
*if there is no limit from 'apu-skin-temp' and stapm/fast/slow/skin power setting, it will take effect.
tested on Lenovo XiaoXin Pro 13ARE 2020 4800U (BIOS:F0CN30WW)
With Zen3 AMD did add a new way to prevent adjustments beyond a definable point. Vendors can now apply upper limits to all PM Table values.
For Example: if the Manufacture decide to limit your device to VRM Current of 60A or SLOW Limit of 35W the following things will happen:
- All adjustments return success, even if value did not get set
- only values below the limit get applied
- values above the value range like 70A and 40W get changed to 60.001 mA and 35.001 mW
Luicenne don't have this new feature because it is Zen2. For example, HP does ship Luicenne and Cezanne in the same product line but only the Cezanne APUs do have this new value range cap.
We are not sure which parameters can capped by the new limit. So far, we did see this feature in action for these parameters:
- fast-limit (30W HP Probook 455 G8 with 5600U)
- slow-limit (25W HP Probook 455 G8 with 5600U)
- vrm-current (60A Lenovo Legion 7 with 5900HX)
We have found at least one workaround. A clever combination of Limit and Time change commands in the correct order with the correct delay can reset the STAPM time. Resetting the timer allows to never reach the STAPM limit. It does only help if you have a Zen3 device with disabled SSTv2 (STAPM will be used in this case) and if your vendor did limit the range of allowed value to an insufficient maximum.
- Reduce STAPM limit by 5W
- set STAPM duration to 0
- wait 10ms until the 0 did clear the calculated power usage history
- set STAPM duration back to max time
- set STAPM limit back to max
The whole process takes around 15-25ms. If you set the STAPM duration to max possible value (usually 500) you improve the trick because you need to reset the usage less often.
You can automate it based on STAPM measurements. For example, we did include it in the readjustService.ps1
example, where it does execute this workaround every ~2-3 minutes. Just enable the feature by setting it to true.
# some Zen3 devices have a locked STAPM limit, this workarround resets the stapm timer to have unlimited stapm.
$resetSTAPMUsage = $true
There is an untested adjustment which may makes this workaround unnecessary. But you cannot automate it, and it takes some time to set it up. It is the way of changing the limits, but we don't know if this does help.
- https://github.com/sibradzic/stapmlifier
- or if you want to do it on Windows: https://www.reddit.com/r/Amd/comments/gzd96u/for_anyone_having_problems_getting_ryzen/
If you want to try it out, let us know if this does help to extend this documentation.
The following processors was used to create the support matrix
Raven Ridge (Zen)
- R3 2300U
- R5 2500U
- R7 2700U
- Ryzen Embedded V1000
- 2400G
Picasso (Zen+)
Dali (Zen)
Renoir (Zen 2)
- PRO 4750U
- R7 4800U
Lucienne (Zen 2)
- 5500U
- Aerith (Steam Deck)
Cezanne (Zen 3)
- 5800HS
- 5600U
- 6800U
- HP db-series
- HP T740 thin client
- ThinkPad A485
- ThinkPad E485/E585
- ThinkPad T14s
- Lenovo Yoga14s ARE 2020 (Chinese Edition)
- Lenovo XiaoXin Pro 13ARE 2020 4800U (BIOS:F0CN30WW)
- ASUS ROG Flow X13
- Steam Deck