base: AxThermal: Apply caps via sysfs when ax_atcm is unavailable

[Zarathos30]

Load the thermal config from system_ext, parse the mid cluster and, when /proc/ax_atcm is missing, write the CPU/GPU caps directly to the cpufreq and kgsl devfreq nodes.

Change-Id: I0cac965d899a839bb0b01d1c73198eb619a50bb8

[Copilot]

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Extends AxThermal configuration with mid-cluster support and adds direct CPU/GPU sysfs fallback when ax_atcm is unavailable.

Changes:

• Adds mid-cluster parsing and policy handling.
• Loads thermal configuration from system_ext.
• Applies and restores CPU/GPU frequency caps through sysfs.

File summaries

File	Description
services/core/java/com/android/server/thermal/AxAdvancedThermalMitigationConfig.java	Updated as part of this pull request.
services/core/java/com/android/server/am/AxThermalBoostPolicy.java	Updated as part of this pull request.
services/core/java/com/android/server/am/AxThermalApplier.java	Updated as part of this pull request.
services/core/java/com/android/server/am/AxPerfConfig.java	Updated as part of this pull request.

Review details

Suppressed comments (9)

services/core/java/com/android/server/am/AxPerfConfig.java:95

• Because these loads are short-circuited, any existing /vendor/etc/ax_perf_thermal.xml prevents the new system_ext file from being parsed. That makes device-specific system_ext mid-cluster settings ineffective; the existing kernel configuration loader gives system_ext precedence over vendor (AxKernelManagerService.java:83-86), so this order should be reversed.

        boolean loaded = loadFrom(VENDOR_THERMAL_CONFIG, ATMC_TAG)
                || loadFrom(SYSTEM_EXT_THERMAL_CONFIG, ATMC_TAG)
                || loadFrom(SYSTEM_THERMAL_CONFIG, ATMC_TAG);

services/core/java/com/android/server/am/AxThermalApplier.java:86

• If the direct sink handled an update while /proc/ax_atcm/state was absent, a later update that sees the file appear switches to writeStateLocked() without restoring the nodes recorded in mSavedValues. The direct CPU/GPU caps then remain active in addition to the kernel-module state; restore the direct sink before switching modes (and handle the reverse transition as well).

            if (new File(ATCM_STATE_PATH).exists()) {
                writeStateLocked(level, cpuCap, gpuCap, boostCap);
            } else {
                applyCpuCapsLocked(cpuCap);
                applyGpuCapsLocked(gpuCap);
            }

services/core/java/com/android/server/am/AxThermalApplier.java:167

• When the applied floor was clamped down to the ceiling above, restoring min_freq before max_freq can violate the cpufreq min<=max constraint (for example, when the user's original minimum exceeds the thermal maximum). Restore the maximum first, just as the apply path does, so the original minimum can be accepted.

                restoreNode(sink.minPath, userMin);
                restoreNode(sink.maxPath, userMax);

services/core/java/com/android/server/am/AxThermalApplier.java:196

• The GPU restore has the same ordering problem: if the thermal floor was clamped to a lower ceiling, writing the saved minimum while the saved maximum is still restricted can fail. Restore max_freq before min_freq here as well.

            restoreNode(minPath, userFrequency(minPath));
            restoreNode(maxPath, userFrequency(maxPath));

services/core/java/com/android/server/am/AxThermalApplier.java:287

• The saved entry is removed before the sysfs write. A transient restore failure therefore makes all later no-cap updates return at the containsKey check, leaving the thermal value in the node permanently; retain the entry until the write succeeds so restoration is retried.

        final String saved = mSavedValues.remove(path);
        mAppliedValues.remove(path);

services/core/java/com/android/server/am/AxThermalApplier.java:194

• CPU cap 0 is treated as inactive in applyCpuCapsLocked(), but GPU cap 0 is treated as an active level here. Since the dispatcher considers every status other than -1 valid, a configuration with a level-0 GPU entry can apply that entry instead of clearing the fallback cap; use the same inactive condition as the CPU path.

        if (gpuCap < 0 || (thermalMin <= 0L && thermalMax <= 0L)) {

services/core/java/com/android/server/am/AxThermalApplier.java:288

• userFrequency() reads a persist.sys.km.<hash> property, but AxKernelManagerService.setControlValue() records frequency changes in Settings.Secure and never writes that property. A user change made while this cap is active is therefore not seen here, so removing the cap restores the old snapshot over the user's selection. Persist and read the user target through one shared source before restoring.

        final long value = userValue > 0L ? userValue : parseLong(saved);

services/core/java/com/android/server/am/AxThermalApplier.java:179

• When a later CPU level supplies only one bound (or the discovered sink has no base bound), the other computed bound is 0 and no write occurs. That leaves the value written by the previous thermal level in sysfs, so a removed max/min cap remains active; restore the corresponding node when its computed bound is absent.

            if (ceiling > 0L) {
                writeNode(sink.maxPath, ceiling);
            }
            if (floor > 0L) {
                writeNode(sink.minPath, floor);

services/core/java/com/android/server/am/AxThermalApplier.java:208

• The same missing-bound case exists for GPU caps: if a subsequent GPU level omits max or min, this code does not restore the value previously written by an earlier level. The old devfreq limit can therefore remain in force after the configuration removes it; restore each node when its computed bound is non-positive.

        if (ceiling > 0L) {
            writeNode(maxPath, ceiling);
        }
        if (floor > 0L) {
            writeNode(minPath, floor);

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.