Hi Konrad,
On 12/30/2024 9:05 PM, Konrad Dybcio wrote:
On 29.12.2024 4:23 PM, Wasim Nazir wrote:
From: Manaf Meethalavalappu Pallikunhi <quic_manafm@xxxxxxxxxxx>
In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
does corrective action for each subsystem based on sensor violation
to comply safety standards. But as QCS9075 is non-safe SoC it
requires conventional thermal mitigation to control thermal for
different subsystems.
The cpu frequency throttling for different cpu tsens is enabled in
hardware as first defense for cpu thermal control. But QCS9075 SoC
has higher ambient specification. During high ambient condition, even
lowest frequency with multi cores can slowly build heat over the time
and it can lead to thermal run-away situations. This patch restrict
cpu cores during this scenario helps further thermal control and
avoids thermal critical violation.
Add cpu idle injection cooling bindings for cpu tsens thermal zones
as a mitigation for cpu subsystem prior to thermal shutdown.
Add cpu frequency cooling devices that will be used by userspace
thermal governor to mitigate skin thermal management.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@xxxxxxxxxxx>
---
Does this bring measurable benefits over just making the CPU a cooling
device and pointing the thermal zones to it (and not the idle subnode)?
Konrad
As noted in the commit, CPU frequency mitigation is handled by hardware
as a first level mitigation. The software/scheduler will be updated via
arch_update_hw_pressure API [1] for this mitigation. Adding the same CPU
mitigation in thermal zones is redundant. We are adding idle injection
with a 100% duty cycle as an additional mitigation step at higher trip
to further reduce CPU power consumption. This helps device thermal
stability further, especially in high ambient conditions.
[1].
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cpufreq/qcom-cpufreq-hw.c?h=next-20241220#n352
Best regards,
Manaf
