[PATCH V4 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal

Eduardo Valentin edubezval at gmail.com
Sat Apr 1 21:13:40 PDT 2017


Hey,

On Sat, Apr 01, 2017 at 11:50:26PM +0200, Rafał Miłecki wrote:
> On 04/01/2017 09:51 PM, Eduardo Valentin wrote:
> >On Fri, Mar 31, 2017 at 10:11:23PM +0200, Rafał Miłecki wrote:
> >>From: Rafał Miłecki <rafal at milecki.pl>
> >>
> >>This commit documents binding for thermal used in Northstar family SoCs.
> >>
> >>Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
> >>---
> >>V3: Add thermal-zones to the example
> >>    Rob: Because of this update, I didn't include Acked-by I got for V2
> >>---
> >> .../devicetree/bindings/thermal/brcm,ns-thermal    | 26 ++++++++++++++++++++++
> >> 1 file changed, 26 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/thermal/brcm,ns-thermal
> >>
> >>diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
> >>new file mode 100644
> >>index 000000000000..c561c7349f17
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
> >>@@ -0,0 +1,26 @@
> >>+* Broadcom Northstar Thermal
> >>+
> >>+This binding describes thermal sensor that is part of Northstar's DMU (Device
> >>+Management Unit).
> >>+
> >>+Required properties:
> >>+- compatible : Must be "brcm,ns-thermal"
> >>+- reg : iomem address range of PVTMON registers
> >>+- #thermal-sensor-cells : Should be <0>
> >>+
> >>+Example:
> >>+
> >>+thermal: thermal at 1800c2c0 {
> >>+	compatible = "brcm,ns-thermal";
> >>+	reg = <0x1800c2c0 0x10>;
> >>+	#thermal-sensor-cells = <0>;
> >>+};
> >>+
> >>+thermal-zones {
> >>+	cpu_thermal: cpu-thermal {
> >>+		polling-delay-passive = <0>;
> >>+		polling-delay = <1000>;
> >>+		coefficients = <(-556) 418000>;
> >>+		thermal-sensors = <&thermal>;
> >
> >You need to define trips and cooling devices here. Otherwise, makes
> >little sense to have this device in thermal subsystem. Here is an
> >example of minimal set:
> >https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=1e2ac9821de6a85d3e8358f238436708d1d46869
> >
> >The above has no passive action. It is just gonna shutdown the system if
> >temperature crosses a threshold.
> >
> >But, a typical cooling device would be CPU frequency throttling. Do you have
> >that up and running in your routers?
> 
> I don't have CPU freq throttling, so shutdown will be the only solution for
> critical temp right now.

OK. Is there any plans to get cpu cooling / DVFS working on your boards?

> 
> I know I should have at least a trip for critical temperature, but the problem
> is I don't know what value to use. There isn't any info about this in public

And that is enough justification to block this to go upstream. We need
the correct shutdown threshold value to put as example. If we don't,
users of this drivers will be pretty much guessing.

> datasheets. Broadcom's SDK doesn't mention it. Vendors share only the max
> environment temp, not the max CPU temp.

Silicon goes bad typically at 125C. But that also typically requires a
good extrapolation of hotspot(s). Some drivers prefer to play safer and
use lower numbers (100C).

> 
> So for now I only meant to provide user space access to reading current CPU
> temperature. I could do some stress tests and ask other users to do it as well.
> 

I see..


> Or maybe I could just put in Documentation some round value that makes more or
> less sense and then work on a proper content of real DTS files?
> 

The problem with the above is that I see very commonly examples being
copied into DTS. So, better to have a good binding
example/documentation. That is what they are for anyway.

> Unless we can get some hint from Broadcom people. Jon? Florian? Anyone?
> 

Yeah, that would be probably best.




More information about the linux-rpi-kernel mailing list