On Thu 28 Oct 00:16 PDT 2021, Lukasz Luba wrote: > > > On 10/27/21 7:43 PM, Bjorn Andersson wrote: > > On Fri 15 Oct 07:45 PDT 2021, Lukasz Luba wrote: > > > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h > > [..] > > > +/** > > > + * topology_thermal_pressure_update() - Update thermal pressure for CPUs > > > + * @cpus : The related CPUs for which capacity has been reduced > > > + * @capped_freq : The maximum allowed frequency that CPUs can run at > > > > I know this matches what I see in e.g. the Qualcomm cpufreq hw driver, > > but in what cases will @capped_freq differ from > > cpufreq_get_hw_max_freq(cpumask_first(cpus))? > > The @capped_freq is the maximum allowed frequency value due to > thermal reasons, which will always be lower or equal to the value > returned by cpufreq_get_hw_max_freq() > (effectively: 'policy->cpuinfo.max_freq'). > Read patch 3 and 4 again and now this makes sense to me. Thanks, Bjorn > We limit the frequency (and voltage) of CPU to reduce power (and heat) > in the passive cooling system. That information is important to us, > because scheduler needs to know how fast the CPU can go. It cannot > assume that the speed is always 'policy->cpuinfo.max_freq'. Often > it's less then that at heavy load or GPU heavy load (the same SoC). > > Regards, > Lukasz
