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 <[email protected]> > > > > > > [ ... ] > > > > > > > > > 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
