fix: cpu stuck in performance mode on fresh install - #733
Merged
Conversation
This fixes a bug where on fresh install i.e. when the CPU speed for minarch has not otherwise been changed, the CPU Speed stays stuck in Performance mode even though the UI shows Auto. This is because minarch calls setOverclock(1) to upgrade to performance mode, but this overwrites the "overclock" variable. If a subsequent "Config_readoptions()" call does not reset it back to something else, the cpu will silently stay in performance mode while the UI shows the default option of Auto. The fix is to set Auto cpu mode explicitly when minarch starts. At present this selects schedutil from min to one less than the max frequency. On TG5040 this is 10% slower clock, so startup time of every game will be 10% slower. But this is of the order of 100-200 ms, while the power and thermal savings are massive. Closes LoveRetro#732
frysee
reviewed
May 20, 2026
Avoid clobbering the cpu speed by using PWR_setCPUSpeed() directly. Also move the reset of cpu speed to the last possible place before the gfx loop starts. This fixes the bug without any performance regression, but infact a minor performance gain during load (about 5% faster loading).
frysee
approved these changes
May 20, 2026
Author
|
Thanks! |
carroarmato0
pushed a commit
to carroarmato0/NextUI
that referenced
this pull request
May 23, 2026
* fix: cpu stuck in performance mode on fresh install This fixes a bug where on fresh install i.e. when the CPU speed for minarch has not otherwise been changed, the CPU Speed stays stuck in Performance mode even though the UI shows Auto. This is because minarch calls setOverclock(1) to upgrade to performance mode, but this overwrites the "overclock" variable. If a subsequent "Config_readoptions()" call does not reset it back to something else, the cpu will silently stay in performance mode while the UI shows the default option of Auto. The fix is to set Auto cpu mode explicitly when minarch starts. At present this selects schedutil from min to one less than the max frequency. On TG5040 this is 10% slower clock, so startup time of every game will be 10% slower. But this is of the order of 100-200 ms, while the power and thermal savings are massive. Closes LoveRetro#732 * fix: revert cpu speed to performance during load Avoid clobbering the cpu speed by using PWR_setCPUSpeed() directly. Also move the reset of cpu speed to the last possible place before the gfx loop starts. This fixes the bug without any performance regression, but infact a minor performance gain during load (about 5% faster loading).
ArjunKdaf
pushed a commit
to ArjunKdaf/kUI-Cold
that referenced
this pull request
Jun 24, 2026
* fix: cpu stuck in performance mode on fresh install This fixes a bug where on fresh install i.e. when the CPU speed for minarch has not otherwise been changed, the CPU Speed stays stuck in Performance mode even though the UI shows Auto. This is because minarch calls setOverclock(1) to upgrade to performance mode, but this overwrites the "overclock" variable. If a subsequent "Config_readoptions()" call does not reset it back to something else, the cpu will silently stay in performance mode while the UI shows the default option of Auto. The fix is to set Auto cpu mode explicitly when minarch starts. At present this selects schedutil from min to one less than the max frequency. On TG5040 this is 10% slower clock, so startup time of every game will be 10% slower. But this is of the order of 100-200 ms, while the power and thermal savings are massive. Closes LoveRetro#732 * fix: revert cpu speed to performance during load Avoid clobbering the cpu speed by using PWR_setCPUSpeed() directly. Also move the reset of cpu speed to the last possible place before the gfx loop starts. This fixes the bug without any performance regression, but infact a minor performance gain during load (about 5% faster loading).
carroarmato0
added a commit
to carroarmato0/NextUI
that referenced
this pull request
Jul 2, 2026
Brings the migration branch current with upstream (LoveRetro/NextUI). New upstream work pulled in: white-point colour correction + displaycal for tg5040 (LoveRetro#760), configurable font style and custom system fonts (LoveRetro#748/LoveRetro#729), usb-c card detection before boot (LoveRetro#750), the game-switcher label fix for entries without a save state (LoveRetro#751), readyResume on Quick Menu directory nav (LoveRetro#739). Two upstream commits (LoveRetro#733 cpu governor, LoveRetro#728 Rewind_init) are the same PRs our fork already carried under different SHAs; git merged them cleanly with no duplicated logic. Conflict resolution: - nextui.cpp: upstream still edits the old nextui.c, which we renamed to .cpp. Git followed the rename. The one real conflict was the recent-game preview button hints -- upstream's LoveRetro#751 changed the logic (group 0 always BACK; group 1 shows "A OPEN" when there's no save state instead of RESUME/REMOVE). Took upstream's logic, kept our C++-friendly cast style. - nextui.cpp: LoveRetro#739 added a readyResume call site into nextui.c using the old Array API (->count / ->items[]); rewrote it against std::vector to match the migrated container (top->entries[top->selected]). Also fixes a latent const-correctness bug the full clean build surfaced: the tg5040 device descriptor stores sysfs paths as const char*, but getInt/putInt/putFile took char* -- so libbatmondb (which compiles platform.c with -Werror=discarded-qualifiers) failed once its cached header forced a platform.c recompile. Those helpers only read the path string, so const-ifying the parameter is the correct fix. Verified: full clean build green for both desktop and tg5040 (nextui, minarch, settings).
carroarmato0
added a commit
to carroarmato0/NextUI
that referenced
this pull request
Jul 5, 2026
Brings the migration branch current with upstream (LoveRetro/NextUI). New upstream work pulled in: white-point colour correction + displaycal for tg5040 (LoveRetro#760), configurable font style and custom system fonts (LoveRetro#748/LoveRetro#729), usb-c card detection before boot (LoveRetro#750), the game-switcher label fix for entries without a save state (LoveRetro#751), readyResume on Quick Menu directory nav (LoveRetro#739). Two upstream commits (LoveRetro#733 cpu governor, LoveRetro#728 Rewind_init) are the same PRs our fork already carried under different SHAs; git merged them cleanly with no duplicated logic. Conflict resolution: - nextui.cpp: upstream still edits the old nextui.c, which we renamed to .cpp. Git followed the rename. The one real conflict was the recent-game preview button hints -- upstream's LoveRetro#751 changed the logic (group 0 always BACK; group 1 shows "A OPEN" when there's no save state instead of RESUME/REMOVE). Took upstream's logic, kept our C++-friendly cast style. - nextui.cpp: LoveRetro#739 added a readyResume call site into nextui.c using the old Array API (->count / ->items[]); rewrote it against std::vector to match the migrated container (top->entries[top->selected]). Also fixes a latent const-correctness bug the full clean build surfaced: the tg5040 device descriptor stores sysfs paths as const char*, but getInt/putInt/putFile took char* -- so libbatmondb (which compiles platform.c with -Werror=discarded-qualifiers) failed once its cached header forced a platform.c recompile. Those helpers only read the path string, so const-ifying the parameter is the correct fix. Verified: full clean build green for both desktop and tg5040 (nextui, minarch, settings).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes a bug where on fresh install i.e. when the CPU speed for minarch has not otherwise been changed, the CPU Speed stays stuck in Performance mode even though the UI shows Auto.
This is because minarch calls setOverclock(1) to upgrade to performance mode, but this overwrites the "overclock" variable. If a subsequent "Config_readoptions()" call does not reset it back to something else, the cpu will silently stay in performance mode while the UI shows the default option of Auto.
The fix is to set Auto cpu mode explicitly when minarch starts. At present this selects schedutil from min to one less than the max frequency. On TG5040 this is 10% slower clock, so startup time of every game will be 10% slower. But this is of the order of 100-200 ms, while the power and thermal savings are massive.
Closes #732