Overclocking support is extremely sensitive to sleep/wake #87
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Please confirm
Expected Behaviour
After sleep/wake the Deck should be able to clock up to the settings defined in BIOS/Smokeless UMAF.
Actual Behaviour
Sometimes the APU will be locked to very low clocks, and other times it'll "cap out" at stock speeds.
Steps To Reproduce
OR
Anything else?
This is very similar to #80 , but I found additional information.
Uninstalling PT completely fixes this issue, and allows for the Deck to fully clock up as it did before sleep. However, we don't have the ability to disable SMT or tune TDP.
I believe that it may be enough to prevent setting frequencies when non-stock clocks are present in pt_oc.json, but still allowing SMT/Governor/TDP changes, as those are still fully functional. I'm not sure if this is something you're interested in, but it would reduce the "bug surface" of PowerTools since you wouldn't need to deal with
amdgpu
disallowing higher-than-stock frequencies.Please let me know if you have any questions!
Version
1.2.0 (Latest stable)
Platform
Steam Deck
OS
SteamOS 3 (Stable)
This is due to a kernel/hardware bug (when kernel stuff is in "manual" mode, clocks get locked to minimum on wake) that I only sort of half-assed a fix for. Its been bothering me for a while so I as actually planning on working on a proper fix tonight.
Interesting, I'd have expected it to have the same behavior when PT was uninstalled in that case. Is that because PT is setting the kernel to manual mode regardless of settings?
Thank you for looking into it!
PT always sets it to manual mode because it was easier that having the CPU and GPU driver parts negotiate whether they can turn it off or not without affecting the other. I've gotten away with it so far because there's no difference between auto mode and manual mode with the clocks min/maxed. But the sysfs interface for clocks doesn't allow me to apply most OC values, so the current solution of re-applying settings upon wakeup fails and leaves the clocks locked to minimums.