On 18/06/2026 09:17, Daniel Lezcano wrote:
> On 6/16/26 06:21, Krzysztof Kozlowski wrote:
>> On 15/06/2026 14:30, Daniel Lezcano wrote:
>>> Hi Gaurav,
>>>>>> thanks for review, shall i use driver data, which is basically pas
>>>>>> data structure like below:
>>>>>>
>>>>>> static const struct qcom_pas_data {
>>>>>> .crash_reason_smem = 601,
>>>>>> .firmware_name = "cdsp.mdt",
>>>>>> .tmd_names = (const char *[]){"xyz", NULL},
>>>>>> .num_tmds = 1,
>>>>>>
>>>>>> Is something like above acceptable? and this will also help to filter
>>>>>> tmd names as well?
>>>>>
>>>>>
>>>>> How the thermal framework will bind the thermal zone with the TMD ?
>>>>> (node pointer, id) ?
>>>>>
>>>>
>>>> Hi Daniel,
>>>>
>>>> thanks for review.
>>>>
>>>> With id only, in this case instead of taking tmd names from device tree,
>>>> qmi_tmd will take tmd name from pas_data(driver) and register with the
>>>> cooling framework with id only. Please let us know if this looks fine.
>>> May be I'm missing something but:
>>>
>>> - The QMI TMD returns a list of names, not ids
>>> - The QMI TMD may return the list in different order than assumed
>>> - The cooling map index points to the name of the TMD in the DT
>>> - This name is used to match the name in the aformentionned list
>>> - The index in the list and the id in the DT can differ
>>>
>>> Krzysztof , I don't get why having the TMD names as properties is wrong,
>>> they describes the existing TMDs on the system and the cooling maps
>>> index points to the one to be connected with thermal zone.
>>
>>
>> 'xxx-names' have a fixed meaning in DT by convention - assign
>> identifiable strings to the 'xxx'. I miss the property 'tmd' in such
>> case - its definition and meaning. Where is it?
>>
>> But maybe you just want list of strings, so I am open to discuss it - I
>> don't understand the need for this property and commit and property
>> description tell me nothing.
>>
>> Really, this commit message is basically non-existing. It explains what
>> it did and provides that much explanation WHY:
>>
>> "- tmd-names (thermal mitigation device names)"
>>
>> Really? This is the explanation why this change is being made, why this
>> property is needed?
>>
>> So sure, describe the problem being solved and WHY this problem is being
>> solved that way. Maybe it will fit DT.
>
> Ok, I understand
>
> Let me try to clarify.
>
> When the QMI TMD protocol is initialized, the list of available TMDs
> provided by the service is requested. They are identified by a *string*
> not a numerical id.
>
> We can not assume the list is always in the same order because the QMI
> TMD is a separate subsystem and the interface is the protocol. The
> protocol does not refer to any TMD with an index but its name.
> Hardcoding an index here is not possible.
Still given device (remoteproc) will provide a fixed, one name for TMD.
That name is fully deducible from the compatible.
>
> The name identifies the TMD we connect to and in return we receive a
> handler to use when sending the QMI messages.
>
> That is for the driver part.
>
> I understand for the DT, it is possible to not give the tmd-names
> because the it can go into the driver's data structure.
>
> But the thermal framework won't be able to associate a cooling device
> (one TMD) with a thermal zone because the cooling mapping must point to
> a cooling device in the DT.
>
> Initially, Gaurav sent a description where each TMD was a child node of
> the remote proc node. And you rightfully told us it is no longer the way
> to go as stated in the documentation. And you suggested to replace the
> child nodes with an array with the tmd-names and add an index in the
> cooling map pointing to this array.
There was only one child node. It was one-to-one mapping, thus I don't
think I suggested using any tmd-names.
Here is the code:
https://lore.kernel.org/linux-devicetree/[email protected]/
and I clearly see one cooling only:
+ cooling:
+ $ref: /schemas/thermal/qcom,qmi-cooling.yaml#
Therefore I still do not see the need of tmd-names. You know the name of
cooling device, because you have strict one-to-one mapping.
>
> The thermal framework has been extended to support this new format and
> associate the cooling device with the thermal zone. This change is now
> upstream for v7.2 [1]
>
> The resulting implementation is the driver gets the tmd-names array
> property. For each name, it connects to the QMI TMD and register the
> cooling device with the index corresponding to the name position on the
> tmd-names array.
>
> On the other side, the thermal framework parses the cooling-map, gets
> the index and do the association (binding).
>
> The tmd-names array property replaces the child nodes and allows to do
> the mapping between the string based identifier with a numerical id.
>
> I hope that clarifies the approach.
>
> -- Daniel
>
> [1]
> https://lore.kernel.org/all/[email protected]/
Best regards,
Krzysztof
