Repository navigation
soc: apple: clpc: count how often the GPU floor is released and comes back - #263
Conversation
… back The GPU floor is released while the PMP limits the DCS and comes back APPLE_CLPC_GPU_BACKOFF_MS after it last did. The debugfs status shows when the PMP last limited the DCS, but not how often the floor changed, so a backoff that is too short, letting the floor flap during sustained heavy rendering, is not visible. Count, at each sample that sees GPU work stream, the times the floor went from held to released and back, and show both counts in the status file. Two readings around a heavy run then show whether the floor came back while the PMP was still limiting. Signed-off-by: DjDeveloperr <hey@djdev.me>
|
CI is green on 8945c4c (plan, self-test, compile, commits, device trees, KUnit, package, boot, host tests): https://github.com/omacom/linux-aurora/actions/runs/40691001142. The same change is aurora-silicon/linux#552. |
|
Qualified on the Neo (J700): integration/aurora core with this patch and a matching asahi module, Omarchy desktop, debugfs at
Under heavy load the counter goes up only while the PMP limits the DCS. The floor comes back once the backoff expires. While the SoC is still hot, the light burst after the heavy leg flips the floor on and off many times (36 cycles), and those cycles are exactly what this counter was added to show. The kernel log has no CLPC errors or warnings. The status file reads without problems while the GPU is busy. |
chriskearney
left a comment
chriskearney
left a comment
There was a problem hiding this comment.
Reviewed exact head 8945c4cf22060b38ce0ca1d12adf5d74be380602, the complete one-file delta and current sample/work/reset/debugfs call graph. GPU-floor decisions, error handling, write arguments, backoff and scheduling remain unchanged; counters never feed policy. #245's separate 100 ms timing change is not a dependency or qualified by this review.
Exact-function host controls passed 38,400 old/new sample comparisons and 76,810 checks, with a meaningful missing-counter baseline failure and five compiled semantic mutants caught. These are CPU controls with bounded hardware stubs, not physical PMP executions.
Source/focused-host PASS; no new physical boot is needed for additive diagnostics. The counters describe sampled streaming-policy decisions, not acknowledged hardware transitions, every idle transition or an atomic pair. They persist across halt/resume and wrap as unsigned words. Normal full current-tree MQ remains required; old PR QEMU success is not hardware floor qualification.
Follow-up to the review of #245: a debugfs count of how often the GPU floor is released and comes back, so flapping is visible.
The GPU floor is released while the PMP limits the DCS, and comes back
APPLE_CLPC_GPU_BACKOFF_MSafter it last did. The status file showed when the PMP last limited the DCS, but not how often the floor changed. This adds one line to the status file (/sys/kernel/debug/<clpc device name>/status), under the existinggpu:line:Both are counted at each sample that sees GPU work stream, as the floor goes from held to released and back. Two readings around a sustained heavy run show whether the floor came back while the PMP was still limiting. No behaviour change: the floor decision is the same expression as before, only split so its result can be counted.
Independent of #245 (based on integration/aurora, no overlap with its one-line backoff change).
Testing: W=1 build of
drivers/soc/apple/clpc.owithAPPLE_PMCandAPPLE_CLPCenabled is clean, apart from the existing kernel-doc warning forpmp_agent.check-commits.pyis clean. There is no CLPC KUnit suite; reading the counts needs a Neo run.