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 7/7] arm64: dts: sdm845: wireup the thermal trip points to cpufreq
Date: Fri, 11 Jan 2019 12:36:05 -0800 [thread overview]
Message-ID: <20190111203605.GG261387@google.com> (raw)
In-Reply-To: <CAHLCerP5ZyORkJm9E8kk-+4X6u6f2=vn_0hq7jSewr9O4=RKDw@mail.gmail.com>
On Fri, Jan 11, 2019 at 04:47:15PM +0530, Amit Kucheria wrote:
> On Fri, Jan 11, 2019 at 6:00 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Thu, Jan 10, 2019 at 05:30:56AM +0530, Amit Kucheria wrote:
> > > Since the big and little cpus are in the same frequency domain, use all
> > > of them for mitigation in the cooling-map. At the lower trip points we
> > > restrict ourselves to throttling only a few OPPs. At higher trip
> > > temperatures, allow ourselves to be throttled to any extent.
> > >
> > > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> > > ---
> > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 145 +++++++++++++++++++++++++++
> > > 1 file changed, 145 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index 29e823b0caf4..cd6402a9aa64 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -13,6 +13,7 @@
> > > #include <dt-bindings/reset/qcom,sdm845-aoss.h>
> > > #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> > > #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> > > +#include <dt-bindings/thermal/thermal.h>
> > >
> > > / {
> > > interrupt-parent = <&intc>;
> > > @@ -99,6 +100,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x0>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_0>;
> > > L2_0: l2-cache {
> > > compatible = "cache";
> > > @@ -114,6 +116,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x100>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_100>;
> > > L2_100: l2-cache {
> > > compatible = "cache";
> > > @@ -126,6 +129,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x200>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_200>;
> > > L2_200: l2-cache {
> > > compatible = "cache";
> > > @@ -138,6 +142,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x300>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_300>;
> > > L2_300: l2-cache {
> > > compatible = "cache";
> > > @@ -150,6 +155,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x400>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_400>;
> > > L2_400: l2-cache {
> > > compatible = "cache";
> > > @@ -162,6 +168,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x500>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_500>;
> > > L2_500: l2-cache {
> > > compatible = "cache";
> > > @@ -174,6 +181,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x600>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_600>;
> > > L2_600: l2-cache {
> > > compatible = "cache";
> > > @@ -186,6 +194,7 @@
> > > compatible = "qcom,kryo385";
> > > reg = <0x0 0x700>;
> > > enable-method = "psci";
> > > + #cooling-cells = <2>;
> > > next-level-cache = <&L2_700>;
> > > L2_700: l2-cache {
> > > compatible = "cache";
> > > @@ -1703,6 +1712,23 @@
> > > type = "critical";
> > > };
> > > };
> > > +
> > > + cooling-maps {
> > > + map0 {
> > > + trip = <&cpu_alert0>;
> > > + cooling-device = <&CPU0 THERMAL_NO_LIMIT 4>,
> > > + <&CPU1 THERMAL_NO_LIMIT 4>,
> > > + <&CPU2 THERMAL_NO_LIMIT 4>,
> > > + <&CPU3 THERMAL_NO_LIMIT 4>;
> > > + };
> > > + map1 {
> > > + trip = <&cpu_crit0>;
> > > + cooling-device = <&CPU0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&CPU1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&CPU2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&CPU3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > > + };
> > > + };
> >
> > Slightly off-topic, buy maybe not so much since we are just starting
> > to use the trip points:
> >
> > Currently we use the naming scheme 'cpu_<type>N' for trip points. I
> > anticipate that we're going to add more passive trip points soon, to
> > keep the 'power_allocator' thermal governor happy, which expects a
> > 'switch_on' and a 'desired_temperature' trip point. With the current
> > naming scheme this could become a bit messy. I suggest to change it to
> > 'cpuN_<type>[X]', which would allow for something like 'cpuN_alert0'
> > and 'cpuN_alert1'.
> >
> > If you think the change makes sense you can consider to do it within
> > this series, I can also send a separate patch once it has landed.
>
> Sure, I can change them to cpuN_alertX format.
Great, thanks!
Another concern about adding trip points later could be the node
name. We currently have:
trips {
cpu0_alert0: trip0 {
...
};
cpu0_crit: trip1 {
...
};
};
If we keep increasing enumeration with the node name this would become:
trips {
cpu0_alert0: trip0 {
...
};
cpu0_alert1: trip1 {
...
};
cpu0_crit: trip2 {
...
};
};
i.e. the node name of the critical trip-point changes, which might be
a concern for dtsi's that override a value, though they should
probably use the phandle &cpu0_crit anyway. If this is a concern we
could change the node names to 'alert0' and 'crit'.
I looked around a bit and actually I kinda like the naming scheme used
by hisilicon/hi6220.dtsi, mediatek/mt8173.dtsi and rockchip/rk3328.dtsi
(with minor variations):
trips {
threshold: trip-point@0 {
temperature = <68000>;
hysteresis = <2000>;
type = "passive";
};
target: trip-point@1 {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
cpu_crit: cpu_crit@0 {
temperature = <115000>;
hysteresis = <2000>;
type = "critical";
};
};
If we were to use this we'd have to adapt it slightly since we have
multiple thermal zones. In line with the other scheme this could be
cpuN_threshold, cpuN_target and cpuN_crit.
Up to you, just providing some options ;-)
> > You could also consider to add the additional trip point in this
> > series if you agree that it will be needed.
>
> I expect that we'll end up with at least 2 passive trip points but I
> don't know what temperature to set the next one at. So let's just go
> with 1 passive and 1 critical trip point in this series and you can
> send a patch adding more once we've characterised IPA.
Sounds good
Thanks!
Matthias
next prev parent reply other threads:[~2019-01-11 20:36 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
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 [this message]
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=20190111203605.GG261387@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).