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: 47+ 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 ` 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:00 ` 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 0:00 ` 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 0:00 ` 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 0:00 ` 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 0:00 ` 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:00 ` Amit Kucheria
2019-01-10 0:29 ` Stephen Boyd
2019-01-10 17:14 ` Doug Anderson
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:00 ` 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-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.