On 31.12.2024 12:05 PM, Manaf Meethalavalappu Pallikunhi wrote: > > 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. I understood this much from the commit message. What I'm asking is, whether your solution actually works better than just letting Linux software-throttle the CPUs, preferably backed by some numbers. I'm also unsure how this is supposed to reduce power consumption. If the CPUs aren't busy, they should idle, and if they are not fully utilized, a lower frequency would likely be scheduled. Konrad > > [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 >
