On Mon, Jun 15, 2026 at 05:33:15PM +0200, Daniel Lezcano wrote:
>
>
> Le 15/06/2026 à 17:14, Dmitry Baryshkov a écrit :
> > On Mon, Jun 15, 2026 at 04:33:38PM +0200, Daniel Lezcano wrote:
> > >
> > >
> > > Le 15/06/2026 à 16:11, Dmitry Baryshkov a écrit :
> > > > On Mon, Jun 15, 2026 at 02:30:49PM +0200, Daniel Lezcano wrote:
> > > > > Hi Gaurav,
> > > > >
> > > > > Le 15/06/2026 à 14:12, Gaurav Kohli a écrit :
> > > > > >
> > > > > >
> > > > > > On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
> > > > > > > On 6/13/26 13:05, Gaurav Kohli wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
> > > > > > > > > On 12/06/2026 15:52, Gaurav Kohli wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
> > > > > > > > > > > On 11/06/2026 13:12, Gaurav Kohli wrote:
> > > > > > > > > > > > > Why? And where is this generic property defined? You
> > > > > > > > > > > > > cannot just
> > > > > > > > > > > > > sprinkle generic properties in random bindings.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Ack, will add why part.
> > > > > > > > > > > > These names are matched with the thermal
> > > > > > > > > > > > mitigation device identifiers
> > > > > > > > > > > > populated by remote firmware over QMI and define
> > > > > > > > > > > > mitigation devices are
> > > > > > > > > > > > exposed as cooling devices.
> > > > > > > > > > >
> > > > > > > > > > > No, -names correspond to values passed via DT, not
> > > > > > > > > > > some remote firmware.
> > > > > > > > > > > The remote firmware should give you interface which
> > > > > > > > > > > is explicit and does
> > > > > > > > > > > not need such properties.
> > > > > > > > > >
> > > > > > > > > > thanks Krzysztof for review, We need tmd-names because
> > > > > > > > > > of following reasons:
> > > > > > > > > >
> > > > > > > > > > Following Daniel's series [1], the thermal framework
> > > > > > > > > > supports
> > > > > > > > > > mapping multiple cooling devices per remoteproc/device via
> > > > > > > > > > indexed
> > > > > > > > > > cooling-cells.
> > > > > > > > > >
> > > > > > > > > > 1) The thermal framework's cooling-maps reference
> > > > > > > > > > cooling devices by index (for #cooling-cells = <3>).
> > > > > > > > > > Without tmd- names,
> > > > > > > > > > there's no way to know which index corresponds to which
> > > > > > > > > > TMD, as firmware
> > > > > > > > > > may return tmd-names in any order.
> > > > > > > > > >
> > > > > > > > > > below are the changes post new thermal mapping changes:
> > > > > > > > > > DT: tmd-names = "cdsp_sw", "xyz";
> > > > > > > > > > Firmware: ["cdsp_sw", "xyz1", "xyz2",]
> > > > > > > > > > Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index
> > > > > > > > > > 1)
> > > > > > > > >
> > > > > > > > > names property are not to instruct drivers to register or not
> > > > > > > > > to
> > > > > > > > > register something.
> > > > > > > > >
> > > > > > > > > I don't understand the problem and explanation in the binding
> > > > > > > > > is
> > > > > > > > > basically non-existing.
> > > > > > > > >
> > > > > > > > > Remember that all lists and indices ARE FIXED, so driver
> > > > > > > > > knows exactly
> > > > > > > > > which index means what.
> > > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > >
> > > > Would it be better if we define standard indices for the standard names?
> > > > This way we decouple the actual firmware strings from the DT.
> > >
> > > I don't think so, it seems to me too fragile and prone to error.
> > >
> > > It is a remote proc, an external subsystem. The contract between the
> > > client
> > > and the server is the protocol. The protocol specifies the identifier as
> > > named strings, the TMD names, not numerical identifiers.
> > >
> > > When asking for the list of TMDs, we get a list of strings. But as it is
> > > an
> > > external subsystems, may be tomorrow someone decide to send list ordered
> > > alphabetically, or per number of states, or whatever.
> > >
> > > With hardcoded id the QMI TMD clients break
> >
> > I was thinking about something like:
> >
> > #define QCOM_TMD_DSP 0
> > #define QCOM_TMD_PA 1
>
> Ah ok, it is correct if:
>
> tmd-names = "dsp", "pa"
>
> Or
>
> #define QCOM_TMD_PA 0
> #define QCOM_TMD_DSP 1
>
> tmd-names = "pa", "dsp"
I was more inclined about having the standard indices for the standard
mitigations.
BTW, I checked, which mitigations are being returned by the DSPs. Few
examples, just to provide some context.
SC8280XP, X13s:
TMD service: instance=0x01 (adsp) node=5 port=9
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x53 (slpi) node=9 port=9
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x43 (cdsp) node=10 port=8
3 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
[ 1] cdsp_hw max_mitigation_level=1
[ 2] cdsp_sw max_mitigation_level=7
SM6115, RB2:
TMD service: instance=0x00 (modem) node=0 port=20
9 mitigation device(s):
[ 0] pa max_mitigation_level=3
[ 1] modem max_mitigation_level=3
[ 2] cpuv_restriction_cold max_mitigation_level=1
[ 3] modem_current max_mitigation_level=3
[ 4] vbatt_low max_mitigation_level=3
[ 5] modem_skin max_mitigation_level=3
[ 6] modem_bw max_mitigation_level=5
[ 7] wlan max_mitigation_level=1
[ 8] wlan_bw max_mitigation_level=1
TMD service: instance=0x01 (adsp) node=5 port=8
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x43 (cdsp) node=10 port=8
3 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
[ 1] cdsp_hw max_mitigation_level=1
[ 2] cdsp_sw max_mitigation_level=5
SM8350, HDK:
TMD service: instance=0x00 (modem) node=0 port=22
28 mitigation device(s):
[ 0] pa max_mitigation_level=3
[ 1] pa_fr1 max_mitigation_level=3
[ 2] modem max_mitigation_level=3
[ 3] cpuv_restriction_cold max_mitigation_level=1
[ 4] modem_current max_mitigation_level=3
[ 5] vbatt_low max_mitigation_level=3
[ 6] charge_state max_mitigation_level=3
[ 7] modem_skin max_mitigation_level=3
[ 8] modem_bw max_mitigation_level=5
[ 9] mmw0 max_mitigation_level=3
[10] mmw1 max_mitigation_level=3
[11] mmw2 max_mitigation_level=3
[12] mmw3 max_mitigation_level=3
[13] mmw_skin0 max_mitigation_level=3
[14] mmw_skin1 max_mitigation_level=3
[15] mmw_skin2 max_mitigation_level=3
[16] mmw_skin3 max_mitigation_level=3
[17] mmw_skin0_dsc max_mitigation_level=15
[18] mmw_skin1_dsc max_mitigation_level=15
[19] mmw_skin2_dsc max_mitigation_level=15
[20] mmw_skin3_dsc max_mitigation_level=15
[21] wlan max_mitigation_level=4
[22] wlan_bw max_mitigation_level=1
[23] modem_skin_lte_dsc max_mitigation_level=255
[24] modem_skin_nr_dsc max_mitigation_level=255
[25] pa_dsc max_mitigation_level=255
[26] pa_fr1_dsc max_mitigation_level=255
[27] cpr_cold max_mitigation_level=3
TMD service: instance=0x01 (adsp) node=5 port=9
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x43 (cdsp) node=10 port=9
3 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
[ 1] cdsp_hw max_mitigation_level=1
[ 2] cdsp_sw max_mitigation_level=7
SM8150, HDK:
TMD service: instance=0x00 (modem) node=0 port=21
6 mitigation device(s):
[ 0] pa max_mitigation_level=3
[ 1] modem max_mitigation_level=3
[ 2] cpuv_restriction_cold max_mitigation_level=1
[ 3] modem_current max_mitigation_level=3
[ 4] vbatt_low max_mitigation_level=3
[ 5] modem_skin max_mitigation_level=3
TMD service: instance=0x01 node=5 port=8
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x53 node=9 port=8
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
TMD service: instance=0x43 (cdsp) node=10 port=8
1 mitigation device(s):
[ 0] cpuv_restriction_cold max_mitigation_level=1
--
With best wishes
Dmitry
