From: Matthias Kaehlcke <mka@chromium.org>
To: Amit Kucheria <amit.kucheria@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Eduardo Valentin <edubezval@gmail.com>,
Andy Gross <andy.gross@linaro.org>,
Taniya Das <tdas@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>,
Douglas Anderson <dianders@chromium.org>,
David Brown <david.brown@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v1 6/7] arm64: dts: sdm845: Increase alert trip point to 95 degrees
Date: Fri, 11 Jan 2019 10:30:23 -0800 [thread overview]
Message-ID: <20190111183023.GE261387@google.com> (raw)
In-Reply-To: <CAHLCerPN3dxd=XBEkU2cMacFDkZjNhXEw7BDYNTEyfSUszSUzg@mail.gmail.com>
On Fri, Jan 11, 2019 at 03:54:23PM +0530, Amit Kucheria wrote:
> On Thu, Jan 10, 2019 at 6:45 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Hi Amit,
> >
> > On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > > Qualcomm engineers, increase it to 95 degrees.
> > >
> > > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> > > ---
> > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 ++++++++--------
> > > 1 file changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index c27cbd3bcb0a..29e823b0caf4 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -1692,7 +1692,7 @@
> > >
> > > trips {
> > > cpu_alert0: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1713,7 +1713,7 @@
> > >
> > > trips {
> > > cpu_alert1: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1734,7 +1734,7 @@
> > >
> > > trips {
> > > cpu_alert2: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1755,7 +1755,7 @@
> > >
> > > trips {
> > > cpu_alert3: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1776,7 +1776,7 @@
> > >
> > > trips {
> > > cpu_alert4: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1797,7 +1797,7 @@
> > >
> > > trips {
> > > cpu_alert5: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1818,7 +1818,7 @@
> > >
> > > trips {
> > > cpu_alert6: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > > @@ -1839,7 +1839,7 @@
> > >
> > > trips {
> > > cpu_alert7: trip0 {
> > > - temperature = <75000>;
> > > + temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> >
> > The change itself looks good to me, however I wonder if it would be
> > worth to eliminate redundancy and merge the current 8 thermal zones
> > into 2, one for the Silver and one for the Gold cluster (as done by
> > http://crrev.com/c/1381752). There is a single cooling device for
> > each cluster, so it's not clear to me if there is any gain from having
> > a separate thermal zone for each CPU. If it is important to monitor
> > the temperatures of the individual cores this can still be done by
> > configuring the thermal zone of the cluster with multiple thermal
> > sensors.
>
> Reducing the number of thermal zones to 2 (by grouping 4 sensors per
> zone) is not possible due a limitation of the thermal framework[1]. It
> is something that we want to address. Previous attempts to fix this
> were rejected for various reasons. Eduardo was going to share a way to
> have more flexible mapping between sensors and zones after discussions
> at LPC.
I wasn't aware of this limitation, thanks for the clarification! With
this I understand that for now we indeed need the 8 thermal zones with
all the redundant information :(
> <nag> Eduardo, do you have anything we can review? </nag> :-)
>
> Having said that, we'll need some aggregation functions when we add
> multiple sensors to a zone (e.g. max, mean) to reflect the zone. This
> will lose information about hotspots and prevent things like idle
> injection on a particular CPU that is causing most of the heat in the
> aggregated zone. So IMHO, it might be useful to have information about
> the hotspots (i.e TZ per sensor) and aggregated values (ambient
> temperature) that can be fed to the thermal policy.
Ok, it seems for now we need the 8 thermal zones in any case, when
support for multiple sensors becomes available we can evaluate whether
it's worth to change that or not.
Cheers
Matthias
next prev parent reply other threads:[~2019-01-11 18:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 0:00 [PATCH v1 0/7] Thermal throttling for SDM845 Amit Kucheria
2019-01-10 0:00 ` [PATCH v1 1/7] drivers: thermal: of-thermal: Print name of device node with error Amit Kucheria
2019-01-10 0:15 ` Stephen Boyd
2019-01-10 0:00 ` [PATCH v1 2/7] drivers: cpufreq: Add thermal_cooling_device pointer to struct cpufreq_policy Amit Kucheria
2019-01-10 1:01 ` Matthias Kaehlcke
2019-01-10 0:00 ` [PATCH v1 3/7] cpu_cooling: Add generic driver ready callback Amit Kucheria
2019-01-10 6:14 ` Viresh Kumar
2019-01-10 0:00 ` [PATCH v1 4/7] cpufreq: qcom-hw: Move to device_initcall Amit Kucheria
2019-01-10 6:44 ` Viresh Kumar
2019-01-10 0:00 ` [PATCH v1 5/7] cpufreq: qcom-hw: Register as a cpufreq cooling device Amit Kucheria
2019-01-10 6:12 ` Viresh Kumar
2019-01-10 9:03 ` Amit Kucheria
2019-01-10 9:32 ` Rafael J. Wysocki
2019-01-10 0:00 ` [PATCH v1 6/7] arm64: dts: sdm845: Increase alert trip point to 95 degrees Amit Kucheria
2019-01-10 0:29 ` Stephen Boyd
2019-01-10 17:14 ` Doug Anderson
2019-01-10 20:06 ` Amit Kucheria
2019-01-10 1:15 ` Matthias Kaehlcke
2019-01-10 2:15 ` Matthias Kaehlcke
2019-01-10 19:45 ` Amit Kucheria
2019-01-10 20:00 ` Matthias Kaehlcke
2019-01-11 3:32 ` Viresh Kumar
2019-01-11 10:24 ` Amit Kucheria
2019-01-11 18:30 ` Matthias Kaehlcke [this message]
2019-01-10 0:00 ` [PATCH v1 7/7] arm64: dts: sdm845: wireup the thermal trip points to cpufreq Amit Kucheria
2019-01-10 0:28 ` Stephen Boyd
2019-01-10 12:28 ` Amit Kucheria
2019-01-10 2:22 ` Matthias Kaehlcke
2019-01-10 6:23 ` Viresh Kumar
2019-01-10 18:42 ` Matthias Kaehlcke
2019-01-11 3:46 ` Viresh Kumar
2019-01-11 19:58 ` Matthias Kaehlcke
2019-01-14 5:59 ` Viresh Kumar
2019-01-11 0:30 ` Matthias Kaehlcke
2019-01-11 11:17 ` Amit Kucheria
2019-01-11 20:36 ` Matthias Kaehlcke
2019-01-14 8:22 ` Amit Kucheria
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=20190111183023.GE261387@google.com \
--to=mka@chromium.org \
--cc=amit.kucheria@linaro.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=edubezval@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.org \
--cc=tdas@codeaurora.org \
--cc=viresh.kumar@linaro.org \
/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).