Repository navigation
cpufreq: apple: keep T8140 policy->cur in step with the cluster - #471
Merged
DjDeveloperr merged 1 commit intoOct 27, 2026
Merged
Conversation
The fast die-temperature limit moves a lazy_verify cluster without a scheduler request. It lowers a request above a new limit, and it restores the scheduler's request when the limit rises again before the QoS request was updated. policy->cur kept the value the last fast-switch request returned. If that was a capped frequency equal to the suspend frequency, cpufreq_generic_suspend() skipped the driver after the limit rose, and the cluster suspended at the restored, higher state. The suspend step now records the state it settles the cluster in as policy->cur before the generic suspend, so the suspend frequency is written whenever the cluster is elsewhere. When the limit moves the cluster, policy->cur is updated too, for scaling_cur_freq and the statistics, until the next fast-switch request sets it. Checked on T8140 with a diagnostic build. The limit was set to the suspend frequency under load, then restored before the QoS request changed, and policy->cur was left at the suspend frequency. A pm_test=devices suspend then left the cluster at 3336 MHz, because the generic suspend skipped the driver. With this change, policy->cur followed the restored state, and the suspend frequency was written and verified.
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
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.
Summary
This is a follow-up to #443 and omacom/linux-aurora#227, for the hole maralcbr found in its last review.
The fast die-temperature limit moves a lazy_verify cluster without a scheduler request. It lowers a request above a new limit, and it restores the scheduler's request when the limit rises again before the QoS request was updated.
policy->curkept the value the last fast-switch request returned. If that was a capped frequency equal to the suspend frequency,cpufreq_generic_suspend()skipped the driver after the limit rose, and the cluster suspended at the restored, higher state.policy->curbefore the generic suspend, so the suspend frequency is written whenever the cluster is elsewhere.policy->curfollows, forscaling_cur_freqand the statistics, until the next fast-switch request sets it.Only lazy_verify SoCs (T8140) run either path.
Testing
On Neo (7.3), with a diagnostic build that sets the cap without touching the QoS request and prints the cluster's state at suspend. Each case set the cap to
suspend_freq(744000 kHz) while a spinner ran, restored it, then ran apm_test=devicessuspend.policy->curstill 744000policy->cur3924000 / 4044000 / 3648000policy->cur==suspend_freqThe E-cluster wrote its suspend frequency in every run. There were no DVFS errors and no driver suspend errors.
Under real load the stale
policy->currarely survives to suspend, because the real fast die limit changes the QoS request within about 0.3 s and schedutil asks again. The diagnostic therefore restores that state at suspend entry, to exercise the case.Builds with W=1. checkpatch --strict is clean.