On 10.05.2024 2:47 PM, Bryan O'Donoghue wrote:
> On 10/05/2024 12:59, Konrad Dybcio wrote:
>> All of the thermal zone suppliers are interrupt-driven, remove the
>> bogus and unnecessary polling that only wastes CPU time.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
>> ---
>> arch/arm64/boot/dts/qcom/sm8650.dtsi | 88 +++++++-----------------------------
>> 1 file changed, 16 insertions(+), 72 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> index 62a6e77730bc..39e789b21acc 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> @@ -5328,8 +5328,6 @@ compute-cb@12 {
>> thermal-zones {
>> aoss0-thermal {
>> - polling-delay-passive = <0>;
>> - polling-delay = <0>;
>
> Commit log doesn't really match the values being subtracted
>
> polling-delay:
> $ref: /schemas/types.yaml#/definitions/uint32
> description:
> The maximum number of milliseconds to wait between polls when
> checking this thermal zone. Setting this to 0 disables the polling
> timers setup by the thermal framework and assumes that the thermal
> sensors in this zone support interrupts.
>
OK I suppose there are 3 things at play:
1) for devices with polling-delay = <non_zero> without this patchset, the
polling is removed and threshold crossings are defered to the PMIC periph
or TSENS interrupts
2) for devices with polling-delay = <0>, this is a NOP cleanup, saving LoC
3) for devices with polling-delay-passive = <0>, this is a NOP, however in 99%
of cases, this was a misconfiguration in the first place. I can leave such
entries so that somebody has an easier time spotting it down the line. I'm not
however willing to go over each one of them and assess what the value should be,
as that requires significant effort across tens of platforms
Konrad
