[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260128-whispering-caracal-of-respect-a26638@quoll>
Date: Wed, 28 Jan 2026 12:27:43 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
Cc: andersson@...nel.org, mathieu.poirier@...aro.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, rui.zhang@...el.com, lukasz.luba@....com,
konradybcio@...nel.org, mani@...nel.org, casey.connolly@...aro.org,
amit.kucheria@....qualcomm.com, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, manaf.pallikunhi@....qualcomm.com
Subject: Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml
bindings
On Tue, Jan 27, 2026 at 09:27:16PM +0530, Gaurav Kohli wrote:
> The cooling subnode of a remoteproc represents a client of the Thermal
> Mitigation Device QMI service running on it. Each subnode of the cooling
> node represents a single control exposed by the service.
>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
> ---
> .../bindings/remoteproc/qcom,pas-common.yaml | 6 ++
> .../bindings/thermal/qcom,qmi-cooling.yaml | 72 +++++++++++++++++++
> 2 files changed, 78 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> index 68c17bf18987..6a736161d5ae 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -80,6 +80,12 @@ properties:
> and devices related to the ADSP.
> unevaluatedProperties: false
>
> + cooling:
> + $ref: /schemas/thermal/qcom,qmi-cooling.yaml#
> + description:
> + Cooling subnode which represents the cooling devices exposed by the Modem.
I do not see the reason why you need 3 (!!!) children here. Everything
should be folded here.
> + unevaluatedProperties: false
> +
> required:
> - clocks
> - clock-names
> diff --git a/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> new file mode 100644
> index 000000000000..0dd3bd84c176
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/qcom,qmi-cooling.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QMI based thermal mitigation (TMD) cooling devices
> +
> +maintainers:
> + - Gaurav Kohli <gaurav.kohli@....qualcomm.com>
> +
> +description:
> + Qualcomm QMI-based TMD cooling devices are used to mitigate thermal conditions
> + across multiple remote subsystems. These devices operate based on junction
> + temperature sensors (TSENS) associated with thermal zones for each subsystem.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,qmi-cooling-cdsp
> + - qcom,qmi-cooling-cdsp1
What are the differences between them?
Why these are not SoC specific?
> +
> +patternProperties:
> + "cdsp-tmd[0-9]*$":
> + type: object
No, you do not need childnode. See writing bindings (covers exactly this
case).
> +
> + description:
> + Each subnode which represents qmi communication to CDSP.
> +
> + properties:
> + label:
> + maxItems: 1
> +
> + "#cooling-cells":
> + $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
> +
> + required:
> + - label
> + - "#cooling-cells"
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + remoteproc-cdsp {
> + cooling {
> + compatible = "qcom,qmi-cooling-cdsp";
> +
> + cdsp_tmd0: cdsp-tmd0 {
> + label = "cdsp_sw";
> + #cooling-cells = <2>;
> + };
> + };
> + };
> +
> + - |
> + remoteproc-cdsp1 {
No, don't create unnecessary examples. Please read some slides from
earlier talks so you won't need 10 iterations.
Best regards,
Krzysztof
Powered by blists - more mailing lists