Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings

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

On 2/11/2026 1:43 PM, Krzysztof Kozlowski wrote:
> On 11/02/2026 08:37, Gaurav Kohli wrote:
>>
>>
>> On 2/8/2026 3:36 PM, Krzysztof Kozlowski wrote:
>>> On 29/01/2026 13:06, Gaurav Kohli wrote:
>>>>
>>>> On 1/28/2026 4:57 PM, Krzysztof Kozlowski wrote:
>>>>> On Tue, Jan 27, 2026 at 09:27:16PM +0530, Gaurav Kohli wrote:
>>>>>> The cooling subnode of a remoteproc represents a client of the Thermal
>>>>>> Mitigation Device QMI service running on it. Each subnode of the cooling
>>>>>> node represents a single control exposed by the service.
>>>>>>
>>>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>>>> ---
>>>>>>     .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>>>     .../bindings/thermal/qcom,qmi-cooling.yaml    | 72 +++++++++++++++++++
>>>>>>     2 files changed, 78 insertions(+)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>>> index 68c17bf18987..6a736161d5ae 100644
>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>>> @@ -80,6 +80,12 @@ properties:
>>>>>>           and devices related to the ADSP.
>>>>>>         unevaluatedProperties: false
>>>>>>     
>>>>>> +  cooling:
>>>>>> +    $ref: /schemas/thermal/qcom,qmi-cooling.yaml#
>>>>>> +    description:
>>>>>> +      Cooling subnode which represents the cooling devices exposed by the Modem.
>>>>> I do not see the reason why you need 3 (!!!) children here. Everything
>>>>> should be folded here.
>>>>
>>>>
>>>> Thanks Krzysztof for review.
>>>>
>>>> Each subsystem may support multiple thermal mitigation devices through
>>>> remote TMD service.
>>>>
>>>> Because of this multiplicity, introduced separate binding file.
>>>
>>> This explains nothing. Subsystem does not matter for the binding. My
>>> comment stays.
>>>
>>
>> thanks for this suggestion, we will use qcom,pas-common.yaml to define
>> bindings and avoid creating new file.
> 
> I asked not to create any children nodes.
> 

We have multiple cores within a subsystem(cdsp) and each core has its 
own independent DCVS. And also we have dedicated TSENS sensor placed on 
each core within the subsystem.
As a result, each core requires its own cooling device, which must be 
linked to its TSENS thermal zone. Because of this, we introduced 
multiple child nodes—one for each cooling device.

  ------            ----------------------------------------
|      | -------> |  cdsp                                  |
|      |          |                                        |
|      |          | HVX compute(tsens1)    HMX NPU(tsens2) |          |
|      |           ----------------------------------------
| SOC  |
|      |
|      |
|      |           -----------------------------------------
|      | -------> |  Modem                                  |
|      |          |                                         |
  ------           |  (modem Lte)    (modem nr)   (modem pa) | 
  

                    -----------------------------------------

Unfortunately, we don't have target in this series which supports 
multiple cores within the subsystem, but there are targets which 
supports multiple cores. We will post patches for those once upstream 
dependency aligns. If it make sense, we will add superset node examples 
in dt bindings for future targets also.

We can use another approach, we can take this cooling node out of 
remoteproc node and use soc node to define child node. This has it's own 
drawback, here qmi-tmd will probe and wait for remoteproc subsystem to 
be up. For cases where remoteproc won't be up, qmi-tmd will still do
probe and sits indefinitely.

So we need your guidance here.

>>
>>>>
>>>>>> +    unevaluatedProperties: false
>>>>>> +
>>>>>>     required:
>>>>>>       - clocks
>>>>>>       - clock-names
>>>>>> diff --git a/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..0dd3bd84c176
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>>> @@ -0,0 +1,72 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/thermal/qcom,qmi-cooling.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Qualcomm QMI based thermal mitigation (TMD) cooling devices
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>>>> +
>>>>>> +description:
>>>>>> +  Qualcomm QMI-based TMD cooling devices are used to mitigate thermal conditions
>>>>>> +  across multiple remote subsystems. These devices operate based on junction
>>>>>> +  temperature sensors (TSENS) associated with thermal zones for each subsystem.
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    enum:
>>>>>> +      - qcom,qmi-cooling-cdsp
>>>>>> +      - qcom,qmi-cooling-cdsp1
>>>>> What are the differences between them?
>>>>
>>>>
>>>> Some SOcs support multiple CDSP/NSP instances. Each instance requires
>>>> it's own
>>>>
>>>> compatible string to distinguish.
>>>
>>> Why? What are the differences?
>>>
>>> I will not ask third time, but just respond with NAK.
>>>
>>
>> For Leman's, we have multiple NSP subsystem to support compute and each
>> instance has it's own firmware and separate hardware like below for cdsp
>>
>> Below data is from lemans.dtsi for cdsp subsystem:
>> -> remoteproc@26300000 {
>> ->  remoteproc@2a300000 {
>>
>> That's why, we have introduced different compatible to distinguish
>> multiple instance, but we can also solve this with single compatible
> 
> You did not answer the question what are the differences, so I am not
> going to ask third time. NAK.

For exact hw diff, we are checking internally and will update for this. 
Right now we only know that we have two cdsp subsystem in Leman's and 
each has it's own firmware/cores.

  ------            ----------------------------------------
|      | -------> |  cdsp0                                 |
|      |          |                                        |
|      |          | HVX compute(tsens1)    HMX NPU(tsens2) |
|      |           ----------------------------------------
| SOC  |
|      |
|      |
|      |           -----------------------------------------
|      | -------> |  cdsp1                                  |
|      |          |                                         |
  ------           |  tsesn3               tsens4            | 
  

                    -----------------------------------------

> 
>> with new dt property for each subsystem instance id. Please let us know
> 
> Instance IDs are not allowed, either. Please read writing bindings doc
> or slides from talks.
> 
> Best regards,
> Krzysztof