summaryrefslogtreecommitdiff
path: root/rust
diff options
context:
space:
mode:
authorJie Zhan <zhanjie9@hisilicon.com>2025-12-23 15:21:19 +0800
committerViresh Kumar <viresh.kumar@linaro.org>2026-01-27 11:21:23 +0530
commit997c021abc6eb9cf7df39fa77fa5e666ad55e3a3 (patch)
tree25bf71226c37eb0f221b31df37e9a3af24e190a5 /rust
parent206b6612556398e717b1e293d96992d5ab2b8f32 (diff)
cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs
Currently, the CPPC Frequency Invariance Engine (FIE) is invoked from the scheduler tick but defers the update of arch_freq_scale to a separate thread because cppc_get_perf_ctrs() would sleep if the CPC regs are in PCC. However, this deferred update mechanism is unnecessary and introduces extra overhead for non-PCC register spaces (e.g. System Memory or FFH), where accessing the regs won't sleep and can be safely performed from the tick context. Furthermore, with the CPPC FIE registered, it throws repeated warnings of "cppc_scale_freq_workfn: failed to read perf counters" on our platform with the CPC regs in System Memory and a power-down idle state enabled. That's because the remote CPU can be in a power-down idle state, and reading its perf counters returns 0. Moving the FIE handling back to the scheduler tick process makes the CPU handle its own perf counters, so it won't be idle and the issue would be inherently solved. To address the above issues, update arch_freq_scale directly in ticks for non-PCC regs and keep the deferred update mechanism for PCC regs. Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'rust')
0 files changed, 0 insertions, 0 deletions