Re: [PATCH] arm64: dts: qcom: shikra: Drop CPU critical trips

[Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>]

On 10/21/2026 5:36 PM, Abel Vesa wrote:
> On 26-10-21 17:12:11, Gaurav Kohli wrote:
>>
>>
>> On 10/20/2026 6:26 PM, Abel Vesa wrote:
>>> On 26-10-19 20:03:47, Gaurav Kohli wrote:
>>>>
>>>>
>>>> On 10/15/2026 4:43 PM, Konrad Dybcio wrote:
>>>>> On 9/25/26 12:24 PM, Gaurav Kohli wrote:
>>>>>>
>>>>>>
>>>>>> On 9/25/2026 3:13 PM, Abel Vesa wrote:
>>>>>>> On 26-09-24 19:52:32, Gaurav Kohli wrote:
>>>>>>>> Shikra firmware handles CPU thermal mitigation up to 117 C, while
>>>>>>>> Linux CPU critical trips trigger at 115 C. This can shut the system
>>>>>>>> down before firmware reaches the end of its mitigation range.
>>>>>>>>
>>>>>>>> Drop the critical trips from the CPU thermal zones and leave the hot
>>>>>>>> trips, non-CPU critical trips and GPUSS passive cooling map unchanged.
>>>>>>>
>>>>>>> I thought that was the whole point of having the critical trips set to
>>>>>>> 115 C, so that the kernel can gracefully shut down before firmware cuts
>>>>>>> it off.
>>>>>>>
>>>>>>> What happens if CPU gets to 117 C and the critical trips are removed?
>>>>>>> How will firmware thermal mitigation handle it?
>>>>>>
>>>>>> Thanks Abel for review.
>>>>>>
>>>>>> For the CPU thermal zones on this SoC, hardware-side mitigation is already available at 115 C and 117 C, and hardware shutdown is at 120 C. Because of that, a Linux critical trip at 115 C is not very useful. It overlaps with the hardware mitigation range and can trigger shutdown before the firmware thermal sequence has completed.
>>>>>
>>>>> Does the hardware mitigation just pull the plug, or does it signal
>>>>> to the OS that it's about to? We absolutely need the OS to be aware,
>>>>> so that e.g. the filesystem will be synced.
>>>>
>>>> Thanks Konrad for the review.
>>>>
>>>> The OS is not notified before the final HW shutdown at 120 C. There is also
>>>> no useful margin for a Linux critical trip here, firmware/HW mitigation
>>>> starts at 115/117 C and hw shutdown is at 120.
>>>>
>>>> So 115 C overlaps with firmware mitigation, while placing it higher is
>>>> too close to HW shutdown to be useful.
>>>
>>> But having the 115 C one will allow the kernel to take all the necessary
>>> steps to bring the system down gracefully, while relying solely on the
>>> firmware will just kill the system before kernel can do anything.
>>
>> Thanks Abel for the review.
>>
>> On this target, 115/117 C firmware mitigation is throttling/prevention, not
>> shutdown. The final HW shutdown threshold is 120 C.
>>
>> The 115 C Linux critical trip therefore starts shutdown exactly when
>> firmware mitigation begins. Moving it higher also leaves too little margin
>> before 120 C.
>>
>> So this patch drops only the CPU critical trips. Would you prefer keeping a
>> Linux critical trip at 118 C ?
> 
> Yes. Again, we don't want the firmware to crash the system before kernel
> has a chance to bring it down gracefully.

Sure, will add at 118.

> 
> But how does the firmware mitigation (throttling/prevention) is done?
> Shouldn't kernel be aware of such thing ?

LMH hardware handles the CPU frequency throttling. The kernel is aware 
of LMH events through the cpufreq driver’s interrupt/polling
path.


thanks
Gaurav