The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
depending on commercial or industrial temperature ratings.
This patch expands the thermal information to include the limits of 90
and 105C for alert and critical. It sets the coolings-cells for the
34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
For boards who never use industrial temperatures, these can be
changed on their respective device trees with something like:
&cpu_alert0 {
temperature = <85000>; /* millicelsius */
};
&cpu_crit {
temperature = <90000>; /* millicelsius */
};
OMAP3_THERMAL will need to be enabled. It is off by default.
Signed-off-by: Adam Ford <[email protected]>
Tested-by: H. Nikolaus Schaller <[email protected]> # on GTA04A5 with dm3730cbp100
---
V2: Rebase on Linux 5.9-rc1
diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
index aee46fa8c055..99858eb0d7f6 100644
--- a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
@@ -17,4 +17,25 @@ cpu_thermal: cpu_thermal {
/* sensor ID */
thermal-sensors = <&bandgap 0>;
+
+ cpu_trips: trips {
+ cpu_alert0: cpu_alert {
+ temperature = <90000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <105000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cpu_cooling_maps: cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 9c3ee4ac8165..c0dcc75833a8 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -20,6 +20,7 @@
operating-points-v2 = <&cpu0_opp_table>;
clock-latency = <300000>; /* From legacy driver */
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 9c3beefc0fe0..fadbf308feff 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -25,6 +25,7 @@
vbb-supply = <&abb_mpu_iva>;
clock-latency = <300000>; /* From omap-cpufreq driver */
+ #cooling-cells = <2>;
};
};
--
2.17.1
On Mon, 17 Aug 2020 08:39:31 -0500
Adam Ford <[email protected]> wrote:
> The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> depending on commercial or industrial temperature ratings.
>
> This patch expands the thermal information to include the limits of 90
> and 105C for alert and critical. It sets the coolings-cells for the
> 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
>
> For boards who never use industrial temperatures, these can be
> changed on their respective device trees with something like:
>
> &cpu_alert0 {
> temperature = <85000>; /* millicelsius */
> };
>
> &cpu_crit {
> temperature = <90000>; /* millicelsius */
> };
>
> OMAP3_THERMAL will need to be enabled. It is off by default.
>
hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
got stuck somewhere. It still seems not to work. Shouldn't that patch
be applied first?
Regards,
Andreas
On Mon, Aug 17, 2020 at 2:59 PM Andreas Kemnade <[email protected]> wrote:
>
> On Mon, 17 Aug 2020 08:39:31 -0500
> Adam Ford <[email protected]> wrote:
>
> > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> > depending on commercial or industrial temperature ratings.
> >
> > This patch expands the thermal information to include the limits of 90
> > and 105C for alert and critical. It sets the coolings-cells for the
> > 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
> >
> > For boards who never use industrial temperatures, these can be
> > changed on their respective device trees with something like:
> >
> > &cpu_alert0 {
> > temperature = <85000>; /* millicelsius */
> > };
> >
> > &cpu_crit {
> > temperature = <90000>; /* millicelsius */
> > };
> >
> > OMAP3_THERMAL will need to be enabled. It is off by default.
> >
> hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
> got stuck somewhere. It still seems not to work. Shouldn't that patch
> be applied first?
I rebased the idle stuff, and now I get errors, so I haven't pushed it
yet. I put a note that OMAP3_THERMAL is off by default, but this
patch would at least get the framing in there. I know at least two of
us that use 1GHZ processors which are not supposed to run at that
speed above 90MHz, so the idea was to tolerate the higher current for
now, and when the idle stuff works, we'll enable the OMAP3_THERMAL by
default.
adam
>
> Regards,
> Andreas
On Mon, 17 Aug 2020 15:02:27 -0500
Adam Ford <[email protected]> wrote:
> On Mon, Aug 17, 2020 at 2:59 PM Andreas Kemnade <[email protected]> wrote:
> >
> > On Mon, 17 Aug 2020 08:39:31 -0500
> > Adam Ford <[email protected]> wrote:
> >
> > > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> > > depending on commercial or industrial temperature ratings.
> > >
> > > This patch expands the thermal information to include the limits of 90
> > > and 105C for alert and critical. It sets the coolings-cells for the
> > > 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
> > >
> > > For boards who never use industrial temperatures, these can be
> > > changed on their respective device trees with something like:
> > >
> > > &cpu_alert0 {
> > > temperature = <85000>; /* millicelsius */
> > > };
> > >
> > > &cpu_crit {
> > > temperature = <90000>; /* millicelsius */
> > > };
> > >
> > > OMAP3_THERMAL will need to be enabled. It is off by default.
> > >
> > hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
> > got stuck somewhere. It still seems not to work. Shouldn't that patch
> > be applied first?
>
> I rebased the idle stuff, and now I get errors, so I haven't pushed it
> yet. I put a note that OMAP3_THERMAL is off by default, but this
> patch would at least get the framing in there. I know at least two of
> us that use 1GHZ processors which are not supposed to run at that
> speed above 90MHz, so the idea was to tolerate the higher current for
> now, and when the idle stuff works, we'll enable the OMAP3_THERMAL by
> default.
>
yes, makes sense, so with this patch we have the choice to either
optimize for low speeds and currents (by disabling OMAP3_THERMAL and
1GHz) or high speeds (by enabling OMAP3_THERMAL and 1 Ghz).
Regards,
Andreas
* Andreas Kemnade <[email protected]> [200817 20:15]:
> On Mon, 17 Aug 2020 15:02:27 -0500
> Adam Ford <[email protected]> wrote:
>
> > On Mon, Aug 17, 2020 at 2:59 PM Andreas Kemnade <[email protected]> wrote:
> > >
> > > On Mon, 17 Aug 2020 08:39:31 -0500
> > > Adam Ford <[email protected]> wrote:
> > >
> > > > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> > > > depending on commercial or industrial temperature ratings.
> > > >
> > > > This patch expands the thermal information to include the limits of 90
> > > > and 105C for alert and critical. It sets the coolings-cells for the
> > > > 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
> > > >
> > > > For boards who never use industrial temperatures, these can be
> > > > changed on their respective device trees with something like:
> > > >
> > > > &cpu_alert0 {
> > > > temperature = <85000>; /* millicelsius */
> > > > };
> > > >
> > > > &cpu_crit {
> > > > temperature = <90000>; /* millicelsius */
> > > > };
I think you should set the lower temperatures by default and have
only the boards known to work with higher values configure them as
needed.
> > > > OMAP3_THERMAL will need to be enabled. It is off by default.
> > > >
> > > hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
> > > got stuck somewhere. It still seems not to work. Shouldn't that patch
> > > be applied first?
> >
> > I rebased the idle stuff, and now I get errors, so I haven't pushed it
> > yet. I put a note that OMAP3_THERMAL is off by default, but this
> > patch would at least get the framing in there. I know at least two of
> > us that use 1GHZ processors which are not supposed to run at that
> > speed above 90MHz, so the idea was to tolerate the higher current for
> > now, and when the idle stuff works, we'll enable the OMAP3_THERMAL by
> > default.
> >
> yes, makes sense, so with this patch we have the choice to either
> optimize for low speeds and currents (by disabling OMAP3_THERMAL and
> 1GHz) or high speeds (by enabling OMAP3_THERMAL and 1 Ghz).
Maybe add something like that to the patch description too?
Regards,
Tony
On Mon 2020-08-17 08:39:31, Adam Ford wrote:
> The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> depending on commercial or industrial temperature ratings.
>
> This patch expands the thermal information to include the limits of 90
> and 105C for alert and critical. It sets the coolings-cells for the
> 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
>
> For boards who never use industrial temperatures, these can be
> changed on their respective device trees with something like:
>
> &cpu_alert0 {
> temperature = <85000>; /* millicelsius */
> };
>
> &cpu_crit {
> temperature = <90000>; /* millicelsius */
> };
That should be the other way around. Provide safe values by default.
Pavel