feat: default to schedutil governor instead of fixed clock speed

[frysee]

As a result of this discussion⁠, I'm currently testing the following:

• NextUI will now default to schedutil instead of userspace + fixed 2000Mhz when initially launching into paks.
• All of the base paks then overwite as needed, i.e.:
  • nextui/minarch with auto scaling (or whatever the user set as preference)
  • basic menu paks with lower fixed clock (CPU_SPEED_MENU).
• New cpufreq.sh helper for third-party paks that might want to control CPU clock speed without directly interacting with low-level system specifics:

Usage: ./cpufreq.sh -p <profile> [-f <freq>]
Profiles:
   performance   - max speed
   powersave     - min speed
   ondemand      - ondemand governor
   schedutil     - schedutil governor (if supported)
   interactive   - interactive governor (if supported)
   conservative  - conservative governor (if supported)
   reset         - restore defaults (all cores online, default min/max, default governor)
   status        - show current governor, freq, active profile, and CPU online status
   list          - list supported governors
   freq          - set exact frequency (requires -f <Hz>, userspace governor)

[pvaibhav]

Adding some notes on my version of this.

I did not try this specific PR because I don't think paks should be able to configure this. In the spirit of MinUI everything should be Auto by default and just work.

Anyway, I've been experimenting with a branch of nextUI locally that removes user space CPU freq scaling entirely (as discussed on discord before). The user space scaling causes overheating and unnecessary CPU usage by polling at 50 Hz, immediately increasing core temp to 62°C and up when e.g. playing PS1 titles.

After disabling and removing that entire 'feature' I modified the CPU Speed option to instead call one of 3 shell scripts to configure the scaling governor for Auto, Powersave and Performance (removed the "Normal" mode as I think Auto should take its place). The shell scripts get installed as part of NextUI under /mnt/SDCARD/.system/{tg5040, tg5050}/etc/auto_governor.sh, powersave_governor.sh and performance_governor.sh.

Then, I can experiment with which governor, min/max frequency and other parameters each of these 3 user-facing CPU speeds will apply.

So far I've found the following:

1. Kernel-mode governor in any case offers better performance and lower core temps, around 5-10°C lower depending on workload, when compared with the current user space model.
2. schedutil consistently prefers higher clock speeds than necessary, and spikier switching. The problem has been well documented among linux community. In theory it sounds like the ideal choice but in practice for our workloads, I've not found any advantage compared to other governors.
3. By default the 2000 MHz overclock speed is not really necessary for anything, and only causes heat build up. Should the user want it, the performance governor will enable it, but I've found a better trade-off is to lower tha max frequency to 1800 MHz or even 1600 MHz. For comparison, H700 based devices can run the same workloads at 1.5GHz clock speeds and lower core temps.
4. PS1 with 2x scaling does not really run well even after locking frequency to 2 GHz. On the other hand TrimUI's own code, in performance mode, disables 2 cores when locking to 2 GHz. I've tried this as well in an effort to maintain overclocked emulation thread but with better core temp and battery. I did not notice any real benefit but needs more testing.
5. Everything else runs perfectly when ondemand is used. I've currently configured the 3 scripts as follows: (a) Auto uses ondemand governor with min/max freq set to 408 MHz - 1.8GHz, all cores online. (b) Powersave uses conservative governor with freq range set to 408-1200 MHz, all cores online. (It's not hardcoded, the script chooses the lowest freq up to mid point frequency.) and (c) Performance uses ondemand but with min frequency set to midpoint (so 1200 MHz) up to 2 GHz overclocked, however with 2 cores disabled.

I've experienced significantly better thermal performance with these settings. I never use Performance mode, that needs more investigation. I almost always use Auto or sometimes Powersave.

Most of the time in the menus the CPU sits at 408 MHz, ramping up to 1-1.2 GHz when scrolling text animation needs to be shown or if I scroll fast within game lists. In-game, depending on the system the freq scales well, mostly settling in at 800 MHz for GB/GBC and going up to 1-1.2GHz for GBA etc. For SNES, Genesis etc. also mostly stays at or below 1.4 GHz.

I will send a PR shortly for the above.

Overall I now find the current default user space govenor practically unusable and my kernel space governor scripts to finally make the device enjoyable. The only issue is I have not yet found why PS1 at 2X scaling doesn't run smoothly for all games. I believe other parts of minarch are responsible for this, particularly the audio resampling (which has memory leaks etc.). Furthermore, I believe threaded video implementation will also help as Stage 2 optimisation of minarch.