Re: [PATCH v4 1/3] dt-bindings: thermal: Add binding document for SR thermal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 18-09-27 11:59 AM, Rob Herring wrote:
On Thu, Sep 27, 2018 at 11:00:33AM -0700, Scott Branden wrote:

On 18-09-27 10:31 AM, Florian Fainelli wrote:
On 09/27/2018 10:27 AM, Rob Herring wrote:
On Thu, Sep 27, 2018 at 09:06:41PM +0530, Srinath Mannam wrote:
From: Pramod Kumar <pramod.kumar@xxxxxxxxxxxx>

Add binding document for supported thermal implementation
in Stingray.

Signed-off-by: Pramod Kumar <pramod.kumar@xxxxxxxxxxxx>
Signed-off-by: Srinath Mannam <srinath.mannam@xxxxxxxxxxxx>
Reviewed-by: Ray Jui <ray.jui@xxxxxxxxxxxx>
Reviewed-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
---
   .../bindings/thermal/brcm,sr-thermal.txt           | 25 ++++++++++++++++++++++
   1 file changed, 25 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
new file mode 100644
index 0000000..717617b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
@@ -0,0 +1,25 @@
+* Broadcom Stingray Thermal
+
+This binding describes thermal sensors that is part of Stingray SoCs.
+
+Required properties:
+- compatible : Must be "brcm,sr-thermal"
+- reg : memory where tmon data will be available.
+- brcm,tmon-mask: A one cell bit mask of valid TMON sources.
+                  Each bit represents single TMON source.
+- brcm,max-crit-temp: Maximum supported critical temperature.
We already have a defined binding for setting trip points.
Indeed, and if you have multiple TMONs, they would in premise possibly
each have a different critical trip point.
Which may be a good reason to go back to our original bindings which were
generic and had each sensor in its own node?
Perhaps. I wouldn't call it going back to your original, but rather
defining a complete binding. Of course, if you don't need different trip
points, then again that is just unnecessary bloat. But I can't argue
whether you do or don't.
We currently do not need different trip points as detailed analysis of each sensor's trip point has not been needed.  If we do add different trip points per sensor the node per sensor approach looks very flexible.  Call it what you like: Srinath's original driver.

Rob




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux