Am 13.09.2019 um 17:01 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
> + cpu_cooling_maps: cooling-maps { > + map0 { > + trip = <&cpu_alert0>; > + /* Only allow OPP50 and OPP100 */ > + cooling-device = <&cpu 0 1>;
omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
Good idea. I have looked over them and they seem to be ok.
adam
BR and thanks, Nikolaus