Re: [PATCH v6 6/7] dt: thermal: tsens: Document the fallback DT property for v2 of TSENS IP
From: Doug Anderson <dianders@chromium.org>
Date: 2018-07-11 18:42:24
Also in:
linux-arm-msm, linux-pm, lkml
Hi, On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria [off-list ref] wrote:
We want to create common code for v2 of the TSENS IP block that is used in a large number of Qualcomm SoCs. "qcom,tsens-v2" should be able to handle most of the common functionality start with a common get_temp() function. It is also necessary to split out the memory regions for the TM and SROT register banks because their offsets are not constant across SoC families.
nit that bindings should be earlier in the patch series than the code implementing the bindings.
quoted hunk ↗ jump to hunk
Signed-off-by: Amit Kucheria <redacted> --- .../devicetree/bindings/thermal/qcom-tsens.txt | 25 +++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt index 06195e8..8f963b1 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt@@ -1,10 +1,16 @@ * QCOM SoC Temperature Sensor (TSENS) Required properties: -- compatible : - - "qcom,msm8916-tsens" : For 8916 Family of SoCs - - "qcom,msm8974-tsens" : For 8974 Family of SoCs - - "qcom,msm8996-tsens" : For 8996 Family of SoCs +- compatible: + Must be one of the following: + - "qcom,msm8916-tsens" (MSM8916) + - "qcom,msm8974-tsens" (MSM8974) + - "qcom,msm8996-tsens" (MSM8996) + - "qcom,msm8998-tsens", "qcom,tsens-v2" (MSM8998) + - "qcom,sdm845-tsens", "qcom,tsens-v2" (SDM845) + The generic "qcom,tsens-v2" property must be used as a fallback for any SoC with + version 2 of the TSENS IP. MSM8996 is the only exception beacause the generic + property did not exist when support was added. - reg: Address range of the thermal registers
You need to document that for old SoCs where TM / SROT were 0x1000 apart (SROT first) that one "reg" field was OK. ...and that for new SoCs you specify two reg ranges: the first for TM and the second for SROT.
quoted hunk ↗ jump to hunk
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.@@ -12,7 +18,7 @@ Required properties: - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to specify nvmem cells -Example: +Example 1 (legacy support before a fallback tsens-v2 propoerty was introduced): tsens: thermal-sensor@900000 { compatible = "qcom,msm8916-tsens"; reg = <0x4a8000 0x2000>;@@ -20,3 +26,12 @@ tsens: thermal-sensor@900000 { nvmem-cell-names = "caldata", "calsel"; #thermal-sensor-cells = <1>; }; + +Example 2 (for any platform containing v2 of the TSENS IP): +tsens0: tsens@c222000 {
A) Use a generic name for the node, not a specific one. Thus the node
should be "thermal-sensor", not "tsens".
B) This unit address needs to match the _first_ reg address listed.
Give your reg below, this should be @c263000
Thus your node name should be:
tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sdm845-tsens", "qcom,tsens-v2"; + reg = <0xc263000 0x1ff>, /* TM */ + <0xc222000 0x1ff>; /* SROT */ + #qcom,sensors = <13>;
The "#qcom,sensors" property seems wrong in a few ways: A) I wouldn't have expected it to start with a "#". I only expect to see that on things specifying sizes / lengths. Rob can feel free to override me, though. B) It's not documented above. Just putting something in an example doesn't document it--it needs to be listed in the "Optional properties".