From: Adam Ford <aford173@gmail.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"Tony Lindgren" <tony@atomide.com>,
"André Roth" <neolynx@gmail.com>,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Andreas Kemnade" <andreas@kemnade.info>,
"Nishanth Menon" <nm@ti.com>, "Adam Ford" <adam.ford@logicpd.com>,
kernel@pyra-handheld.com
Subject: Re: [RFC] ARM: dts: omap36xx: Enable thermal throttling
Date: Fri, 13 Sep 2019 13:46:41 -0500 [thread overview]
Message-ID: <CAHCN7xLcCO-QrYTm0jzS64P6o5t8cfudJfYELDSz-_OPV5JO5w@mail.gmail.com> (raw)
In-Reply-To: <81d6cd33-4930-6753-d5ed-678cb1d2038d@linaro.org>
On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
>
> [ ... ]
>
> >> Good news (I think)
> >>
> >> With cooling-device = <&cpu 1 2> setup, I was able to ask the max
> >> frequency and it returned 600MHz.
> >>
> >> # cat /sys/devices/virtual/thermal/thermal_zone0/temp
> >> 58500
> >> # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
> >> 300000 600000 800000
> >> # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m
> >> scaling_max_freq scaling_min_freq
> >> # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
> >> 600000
> >
> > looks good!
> > But we have to understand what the <&cpu 1 2> exactly means...
> >
> > Hopefully someone reading your RFCv2 can answer...
>
Daniel,
Thank you for replying.
> I may have missed the question :)
>
> These are the states allowed for the cooling device (the one you can see
> in the /sys/class/thermal/cooling_device0/max_state. As the logic is
> inverted for cpufreq, that can be confusing.
I think that's what has be confused.
>
> If it was a fan with, let's say 5 speeds, you would use <&fan 0 5>, so
> when the mitigation begins the cooling device state is 0 and then the
> thermal governor increase the state until it sees a cooling effect.
>
> If <&fan 0 2> is set, the governor won't set a state above 2 even if the
> temperature increases.
I am not sure I know what you mean by 'state' in this context.
>
> When the cooling driver is able to return the number of states it
> supports, it is safe to set the states to THERMAL_NO_LIMIT and let the
> governor to find the balance point.
If the cooling driver is using cpufreq, is the number of supported
states equal to the number of operating points given to cpufreq?
>
> Now if the cooling device is cpufreq, the state order is inverted,
> because the cooling effects happens when decreasing the OPP.
>
> If the boards support 7 OPPs, the state 0 is 7 - 0, so no mitigation, if
> the state is 1, the cpufreq is throttle to the 6th OPP, 2 to the 5th OPP
> etc.
I am not sure how the state would be set to 2.
>
> Now the different combinations:
>
> <&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT> the governor will use the state
> 0 to 7.
>
> <&cpu THERMAL_NO_LIMIT 2> the governor will use the state 0 to 2
What would be the difference between <&cpu THERMAL_NO_LIMIT 2> and
<&cpu 0 2> ?
(if there is any)
>
> <&cpu 1 2> the governor will use the state 1 and 2. That means there is
> always the cooling effect as the governor won't set it to zero thus
> stopping the mitigation.
For the purposes of the board in question, we have 4 operating points,
300MHz, 600MHz, 800MHz and 1GHz. Once the board reaches 90C, we need
them to cease operation at 800MHz and 1GHz and only permit operation
at 300MHz and 600MHz. I am going under the assumption that the cpu
index[0] would be for 300MHz, index[1] = 600MHz, etc.
If I am interpreting your comment correctly, I should set <&cpu
THERMAL_NO_LIMIT 2> which would allow it to either not cool and run up
to 600MHz and not exceed, is that correct?
>
>
> Does it clarify the DT spec?
>
I think your reply to my inquiry might. If possible, it would be nice
to get this documented into the bindings doc for others in the future.
I can do it, but someone with a better understanding of the concept
maybe more qualified. I can totally understand why some may want to
integrate this into their SoC device trees to slow the processor when
hot.
Thank you for taking the time to review this. I appreciate it.
adam
>
>
>
> > What happens with trip point 60000?
> > (unfortunately one has to reboot in between or can you kexec between two kernel/dtb versions?)
> >
> > BR,
> > Nikolaus
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
next prev parent reply other threads:[~2019-09-13 18:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 18:30 [RFC] ARM: dts: omap36xx: Enable thermal throttling Adam Ford
2019-09-12 21:12 ` Daniel Lezcano
2019-09-12 21:19 ` Adam Ford
2019-09-12 22:33 ` Daniel Lezcano
2019-09-18 9:24 ` Viresh Kumar
2019-09-18 9:36 ` H. Nikolaus Schaller
2019-09-18 9:37 ` Daniel Lezcano
2019-09-13 6:55 ` H. Nikolaus Schaller
2019-09-13 11:07 ` Adam Ford
2019-09-13 13:28 ` Adam Ford
2019-09-13 13:32 ` H. Nikolaus Schaller
2019-09-13 14:05 ` Adam Ford
2019-09-13 14:24 ` H. Nikolaus Schaller
2019-09-13 15:01 ` Adam Ford
2019-09-13 15:09 ` H. Nikolaus Schaller
2019-09-13 16:35 ` Adam Ford
2019-09-13 16:42 ` Adam Ford
2019-09-13 16:51 ` H. Nikolaus Schaller
2019-09-13 17:18 ` Daniel Lezcano
2019-09-13 18:46 ` Adam Ford [this message]
2019-09-13 20:01 ` Adam Ford
2019-09-13 20:11 ` Daniel Lezcano
2019-09-13 20:34 ` H. Nikolaus Schaller
2019-09-13 21:01 ` Adam Ford
2019-09-14 9:53 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHCN7xLcCO-QrYTm0jzS64P6o5t8cfudJfYELDSz-_OPV5JO5w@mail.gmail.com \
--to=aford173@gmail.com \
--cc=adam.ford@logicpd.com \
--cc=andreas@kemnade.info \
--cc=daniel.lezcano@linaro.org \
--cc=hns@goldelico.com \
--cc=kernel@pyra-handheld.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=neolynx@gmail.com \
--cc=nm@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).