Re: [PATCH v4 01/10] dt-bindings: firmware: qcom: tmd: add TMD device type constants

On 7/9/2026 1:53 PM, Daniel Lezcano wrote:
> 
> 
> Le 09/07/2026 à 09:58, Dmitry Baryshkov a écrit :
>> On Thu, Jul 09, 2026 at 09:42:04AM +0200, Daniel Lezcano wrote:
>>>
>>>
>>> Le 09/07/2026 à 09:37, Dmitry Baryshkov a écrit :
>>>> On Thu, Jul 09, 2026 at 10:54:26AM +0530, Gaurav Kohli wrote:
>>>>>
>>>>>
>>>>> On 7/8/2026 7:55 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, Jul 07, 2026 at 03:55:13PM +0530, Gaurav Kohli wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 7/7/2026 1:04 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Mon, Jul 06, 2026 at 08:11:35PM +0200, Daniel Lezcano wrote:
>>>>>>>>> On 7/6/26 19:47, Dmitry Baryshkov wrote:
>>>>>>>>>> On Mon, Jul 06, 2026 at 07:03:18PM +0200, Daniel Lezcano wrote:
>>>>>>>>>>> On 7/3/26 17:42, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Fri, Jul 03, 2026 at 07:43:39PM +0530, Gaurav Kohli wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/3/2026 1:23 PM, Konrad Dybcio wrote:
>>>>>>>>>>>>>> On 7/3/26 7:03 AM, Gaurav Kohli wrote:
>>>>>>>>>>>>>>> Add Device Tree binding constants for Qualcomm Thermal 
>>>>>>>>>>>>>>> Mitigation
>>>>>>>>>>>>>>> Device (TMD) types used by remoteproc-backed thermal 
>>>>>>>>>>>>>>> cooling devices.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Qualcomm remote processors expose thermal mitigation 
>>>>>>>>>>>>>>> endpoints
>>>>>>>>>>>>>>> through QMI. These endpoints can be registered with the 
>>>>>>>>>>>>>>> thermal
>>>>>>>>>>>>>>> framework via the `#cooling-cells` property on the 
>>>>>>>>>>>>>>> remoteproc node.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The QMI TMD protocol identifies devices using string 
>>>>>>>>>>>>>>> names (for example,
>>>>>>>>>>>>>>> "pa", "modem", and "cdsp_sw"), while the DT cooling- 
>>>>>>>>>>>>>>> device binding with
>>>>>>>>>>>>>>> `#cooling-cells = <3>` requires numeric device id in the 
>>>>>>>>>>>>>>> form:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>          <&phandle device_id min_state max_state>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Define common TMD device index constants shared across 
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>> supported platforms. If a future target requires a 
>>>>>>>>>>>>>>> different mapping,
>>>>>>>>>>>>>>> additional target-specific constants can be introduced 
>>>>>>>>>>>>>>> while preserving
>>>>>>>>>>>>>>> existing DT ABI.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Gaurav Kohli <[email protected]>
>>>>>>>>>
>>>>>>>>> [ ... ]
>>>>>>>>>
>>>>>>>>>>>> Why are you using only those TMD devices?
>>>>>>>>>>>>
>>>>>>>>>>>>> More constants can be added as needed.
>>>>>>>>>>>>
>>>>>>>>>>>> Kodiak is one of the supported platforms.
>>>>>>>>>>>
>>>>>>>>>>> What would be the benefit of having more than thirteen 
>>>>>>>>>>> cooling devices
>>>>>>>>>>> declared in the thermal framework and having only a couple of 
>>>>>>>>>>> them mapped in
>>>>>>>>>>> a thermal zone ?
>>>>>>>>>>>
>>>>>>>>>>> I agree there are more TMDs but if they are unused for the 
>>>>>>>>>>> moment, why do we
>>>>>>>>>>> need to add them ? Can we do that incrementally ?
>>>>>>>>>>
>>>>>>>>>> That's what I am trying to understand: why the implementation 
>>>>>>>>>> uses only
>>>>>>>>>> the selected two devices, if the modem on Kodiak supports 
>>>>>>>>>> others. How
>>>>>>>>>> can we find out, which TMDs to use on other devices.
>>>>>>>>>
>>>>>>>>> My understanding is that is an initial thermal setup. Gaurav 
>>>>>>>>> will add them
>>>>>>>>> step by step while setting up all the thermal zones instead of 
>>>>>>>>> sending a big
>>>>>>>>> patchset. And TBH, that will be much easier to review.
>>>>>>>>
>>>>>>>> In such a case it should be noted in the commit message and/or 
>>>>>>>> cover
>>>>>>>> letter.
>>>>>>>
>>>>>>> Thanks for the review/guidance. Not all TMD endpoints are 
>>>>>>> relevant for
>>>>>>> kernel thermal zone binding — some like BCL and cold temperature 
>>>>>>> are handled
>>>>>>> from userspace when needed. The constants here cover only
>>>>>>
>>>>>> What if there is no userspace? Or the userspace is different from 
>>>>>> what
>>>>>> you expect? I doubt we have TMD-speaking userspace yet.
>>>>>
>>>>> Thanks for mail, The TMD userspace implementation is available 
>>>>> upstream at
>>>>> https://github.com/qualcomm/qmi-framework.
>>>>
>>>> Is it?
>>>>
>>>> lumag@rohan:/tmp/qmi-framework$ git grep -i tmd
>>>> lumag@rohan:/tmp/qmi-framework$
>>>>
>>>> I found no traces of TMD there. Moreover, I don't see why QMI framework
>>>> implementation would react to thermal events.
>>>>
>>>>>>> what is needed for modem and CDSP thermal zones on the currently 
>>>>>>> posted
>>>>>>> targets.
>>>>>>
>>>>>> Again, SLPI, ADSP?
>>>>>
>>>>> Sorry, I should have said "generic subsystems" rather than listing 
>>>>> specific
>>>>> ones. SLPI and ADSP do not require active thermal mitigation on these
>>>>> platforms.
>>>>
>>>> Could you please provide details, then. What is cpuv_restriction_cold
>>>> TMD?
>>>
>>> It warms up the zone when the temperature is too cold
>>
>> So, if we ever get back to supporting warming up, these TMDs would
>> become relevant. Am I right?
> Probably
> 
> Can we do some progress with these TMDs definition ?
> 
> Spending 95% of the effort to discuss 1% of the proposed changes, which 
> is always DT discussion, is quite frustrating :/
> 
> You want to add all defines for existing TMDs for all platforms ?
> 
> We are talking about numerical values right ? Why is it a problem to add 
> their define later ?

Sent a new version. Added a note in the cover letter clarifying that 
only kernel-managed TMDs are included in the DT binding. Please review.
>