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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/21/26 10:00 AM, Daniel Lezcano wrote:
> 
> Hi Konrad,
> 
> On 3/19/26 10:51, Konrad Dybcio wrote:
>> On 3/18/26 11:17 AM, Gaurav Kohli wrote:
>>>
>>>
>>> On 3/17/2026 1:27 AM, Daniel Lezcano wrote:
>>>> On Tue, Feb 24, 2026 at 01:17:22PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 24/02/2026 13:09, Gaurav Kohli wrote:
>>>>
>>>> [ ... ]
>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> So you have one device with cooling cells=1+2, no?
>>>>>>>
>>>>>>
>>>>>> This will be a bigger framework change which is not supported, i can see
>>>>>
>>>>> I don't think that changing open source frameworks is "not supported". I
>>>>> am pretty sure that changing is not only supported, but actually desired.
>>>>
>>>> Yes, IMO it could make sense. There are the thermal zones with phandle
>>>> to a sensor and a sensor id. We can have the same with a phandle to a
>>>> cooling device and a cooling device id.
>>>>
>>>> (... or several ids because the thermal sensor can also have multiple
>>>> ids ?)
>>>>
>>>> May be an array of names corresponding to the TMD names at the 'id'
>>>> position ?
>>>>
>>>
>>> I am using dt node like below to use with cooling-cells = <3> approach, will post new patches with that.
>>>
>>> cdsp_tmd: cdsp-tmd {
>>>      compatible = "qcom,qmi-cooling-cdsp";
>>>      tmd-names = "cdsp_sw", "cdsp_hw";
>>>      #cooling-cells = <3>;
>>> };
>>>
>>> please let me know, if you are expecting something like this only.
>>
>> My question about the need of a separate node still remains, i.e.
>> why can't this be:
>>
>> remoteproc_cdsp: remoteproc@cafebabe {
>>     compatible = "qcom,foo-cdsp"
>>
>>     ...
>>
>>     tmd-names = "abc", "xyz";
>>     #cooling-cells = <3>;
>> };
>>
>>
>>
>> foo-thermal {
>>     cooling-maps {
>>         map0 {
>>             cooling-device = <&remoteproc_cdsp CDSP_COOLING_XYZ
>>                       THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>>         };
>>     };
>> };
>>
>> where you'd presumably call something like qmi_cooling_register(...) from
>> the remoteproc driver, making your added code essentially a library, not a
>> separate platform device
> 
> I'm not sure to get your question. My understanding of the 3 cooling-cells is exactly what you described. The second argument of the cooling-device map is an index corresponding to the id of the TMD. BTW I prefer also the compatible name like 'qcom,foo-cdsp'

My specific suggestion is to _not_ spawn an additional node, since all
of this logic relates to the behavior of the (e.g.) CDSP, which already
has its own node

Konrad