Re: [PATCH v4 01/10] dt-bindings: firmware: qcom: tmd: add TMD device type constants

[Dmitry Baryshkov]

On Tue, Jul 07, 2026 at 03:55:13PM +0530, Gaurav Kohli wrote:
> 
> 
> On 7/7/2026 1:04 AM, Dmitry Baryshkov wrote:
> > On Mon, Jul 06, 2026 at 08:11:35PM +0200, Daniel Lezcano wrote:
> > > On 7/6/26 19:47, Dmitry Baryshkov wrote:
> > > > On Mon, Jul 06, 2026 at 07:03:18PM +0200, Daniel Lezcano wrote:
> > > > > On 7/3/26 17:42, Dmitry Baryshkov wrote:
> > > > > > On Fri, Jul 03, 2026 at 07:43:39PM +0530, Gaurav Kohli wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 7/3/2026 1:23 PM, Konrad Dybcio wrote:
> > > > > > > > On 7/3/26 7:03 AM, Gaurav Kohli wrote:
> > > > > > > > > Add Device Tree binding constants for Qualcomm Thermal Mitigation
> > > > > > > > > Device (TMD) types used by remoteproc-backed thermal cooling devices.
> > > > > > > > > 
> > > > > > > > > Qualcomm remote processors expose thermal mitigation endpoints
> > > > > > > > > through QMI. These endpoints can be registered with the thermal
> > > > > > > > > framework via the `#cooling-cells` property on the remoteproc node.
> > > > > > > > > 
> > > > > > > > > The QMI TMD protocol identifies devices using string names (for example,
> > > > > > > > > "pa", "modem", and "cdsp_sw"), while the DT cooling-device binding with
> > > > > > > > > `#cooling-cells = <3>` requires numeric device id in the form:
> > > > > > > > > 
> > > > > > > > >       <&phandle device_id min_state max_state>
> > > > > > > > > 
> > > > > > > > > Define common TMD device index constants shared across currently
> > > > > > > > > supported platforms. If a future target requires a different mapping,
> > > > > > > > > additional target-specific constants can be introduced while preserving
> > > > > > > > > existing DT ABI.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Gaurav Kohli <gaurav.kohli@xxxxxxxxxxxxxxxx>
> > > 
> > > [ ... ]
> > > 
> > > > > > Why are you using only those TMD devices?
> > > > > > 
> > > > > > > More constants can be added as needed.
> > > > > > 
> > > > > > Kodiak is one of the supported platforms.
> > > > > 
> > > > > What would be the benefit of having more than thirteen cooling devices
> > > > > declared in the thermal framework and having only a couple of them mapped in
> > > > > a thermal zone ?
> > > > > 
> > > > > I agree there are more TMDs but if they are unused for the moment, why do we
> > > > > need to add them ? Can we do that incrementally ?
> > > > 
> > > > That's what I am trying to understand: why the implementation uses only
> > > > the selected two devices, if the modem on Kodiak supports others. How
> > > > can we find out, which TMDs to use on other devices.
> > > 
> > > My understanding is that is an initial thermal setup. Gaurav will add them
> > > step by step while setting up all the thermal zones instead of sending a big
> > > patchset. And TBH, that will be much easier to review.
> > 
> > In such a case it should be noted in the commit message and/or cover
> > letter.
> 
> Thanks for the review/guidance. Not all TMD endpoints are relevant for
> kernel thermal zone binding — some like BCL and cold temperature are handled
> from userspace when needed. The constants here cover only

What if there is no userspace? Or the userspace is different from what
you expect? I doubt we have TMD-speaking userspace yet.

> what is needed for modem and CDSP thermal zones on the currently posted
> targets.

Again, SLPI, ADSP?

> 
> Will add a note in the cover letter clarifying for current tmd's.
> Please let me if this is fine.
> 
> > 
> > 
> 

-- 
With best wishes
Dmitry