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.
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.
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]/
