Re: [PATCH 1/8] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add qcom,tsens
Konrad Dybcio <[email protected]>
| 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/31/26 7:55 AM, Anvesh Jain P wrote: > > > On 7/30/2026 10:41 PM, Konrad Dybcio wrote: >> On 7/29/26 2:13 PM, Anvesh Jain P wrote: >>> >>> >>> 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. >> >> [...] >> >>>>> + 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. >> >> What you said is true >> >> It also doesn't answer the question why that isn't the case >> >> Konrad > > What I meant is, the driver looks up a thermal zone for each sensor id, > and skips the ones that don't have a zone in DT. Sensor ids past 11/15 > on this board don't have a zone assigned, so there's nothing to read there. You can keep repeating what you said and I can keep repeating you're not answering the question "why do we only choose to read the data from certain sensors and ignore others" Konrad