Re: [PATCH 1/8] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add qcom,tsens
Anvesh Jain P <[email protected]> Wed, 29 Jul 2026 17:43:51 +0530
| Newsgroups | org.kernel.vger.platform-driver-x86,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 7/29/2026 4:43 PM, Konrad Dybcio wrote: > On 7/28/26 7:44 PM, Anvesh Jain P wrote: >> Add the qcom,tsens property so Hamoa-based boards can list the tsens >> providers, and how many leading sensor IDs on each, whose readings the >> driver averages to compute the SoC junction temperature reported to >> the EC for fan control. >> >> The generic thermal-sensors property has no standard semantic for >> selecting a range of sensor IDs from a provider without enumerating >> each one, so a vendor-specific phandle-array with an explicit sensor >> count is used instead. >> >> Signed-off-by: Anvesh Jain P <[email protected]> >> --- >> .../embedded-controller/qcom,hamoa-crd-ec.yaml | 31 ++++++++++++++++++++++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml >> index c07483aa5937..ec809fcd03ab 100644 >> --- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml >> +++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml >> @@ -33,11 +33,40 @@ properties: >> interrupts: >> maxItems: 1 >> >> + # A generic "thermal-sensors" phandle only identifies individual sensor >> + # IDs, and thermal zones are a Linux-side grouping of those sensors, not >> + # a devicetree concept the EC cares about. What the driver actually needs >> + # is raw readings from a contiguous range of leading sensor IDs on each >> + # tsens provider, averaged together, so qcom,tsens pairs each provider >> + # phandle with a count instead of enumerating every sensor cell. >> + qcom,tsens: >> + description: >> + List of tsens providers and, for each, the number of leading sensor >> + IDs on that provider whose readings are averaged to compute the SoC >> + junction temperature reported to the EC for fan control. Only >> + applicable for Hamoa based devices. >> + $ref: /schemas/types.yaml#/definitions/phandle-array >> + minItems: 1 >> + maxItems: 2 >> + items: >> + items: >> + - description: phandle to a tsens thermal-sensor provider >> + - description: number of leading sensor IDs on that provider to average > > Why don't we want to look at all of the TSENS sensors? > > Konrad Each tsens provider has more physical sensors (16) than the count used here. The leading N we take exactly matches the number of sensors already wired to board thermal-zones for other purposes (CPU clusters, GPU, camera, etc.) on that provider — e.g. on hamoa, tsens2 has 11 such zones and tsens3 has 15, matching qcom,tsens = <&tsens2 11>, <&tsens3 15>;. The remaining sensor IDs aren't referenced by any thermal-zone on this platform, so there's no per-purpose reading to include in the SoC Tj average. -- Best Regards, Anvesh