From: Matthias Kaehlcke <mka@chromium.org>
To: Amit Kucheria <amit.kucheria@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
bjorn.andersson@linaro.org, viresh.kumar@linaro.org,
edubezval@gmail.com, andy.gross@linaro.org, tdas@codeaurora.org,
swboyd@chromium.org, 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 v2 8/9] arm64: dts: sdm845: wireup the thermal trip points to cpufreq
Date: Mon, 14 Jan 2019 14:01:01 -0800 [thread overview]
Message-ID: <20190114220101.GN261387@google.com> (raw)
In-Reply-To: <7f94696460848a6bcfe5aee5ffda7fe556240736.1547458732.git.amit.kucheria@linaro.org>
On Mon, Jan 14, 2019 at 03:51:10PM +0530, Amit Kucheria wrote:
> Since all cpus in the big and little clusters, respectively, are in the
> same frequency domain, use all of them for mitigation in the
> cooling-map. We end up with two cooling devices - one each for the big
> and little clusters.
>
> 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 | 177 ++++++++++++++++++++++++---
> 1 file changed, 161 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fb7da678b116..7973e88bdf94 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>
> ...
>
> @@ -1719,18 +1728,35 @@
> thermal-sensors = <&tsens0 1>;
>
> trips {
> - cpu_alert0: trip0 {
> + cpu0_alert0: trip-point@0 {
Thanks for adapting the trip point names and labels in anticipation of
further additions!
Seems you aren't overly convinced about the 'target/threshold'
terminology used by some other arm64 platforms ;-)
> temperature = <95000>;
> hysteresis = <2000>;
> type = "passive";
> };
I realized that we still have the potential problem of a name change
in the trip point node name if a 'threshold' node for IPA is added,
since this node will have a lower temperature than 95°. If this is
something to be concerned about it might be worth to add that extra
trip point already to avoid headaches or funky trip point enumeration,
even if we know that the value might not be the final one.
(I'm aware that we are also changing the node names and labels right
now, it seems less problematic at this point since the SDM845 thermal
zones are a fairly recent addition)
> - cpu_crit0: trip1 {
> + cpu0_crit: cpu_crit@0 {
nit: does the @0 add any value here? IIUC there can be only one
critical trip point, hence there will never be a cpu_crit@1 or
higher.
> temperature = <110000>;
> hysteresis = <1000>;
> type = "critical";
> };
> };
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu0_alert0>;
> + cooling-device = <&CPU0 THERMAL_NO_LIMIT 4>,
> + <&CPU1 THERMAL_NO_LIMIT 4>,
> + <&CPU2 THERMAL_NO_LIMIT 4>,
> + <&CPU3 THERMAL_NO_LIMIT 4>;
> + };
Out of curiosity: how did you determing the max cooling state of 4?
Cheers
Matthias
next prev parent reply other threads:[~2019-01-14 22:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 10:21 [PATCH v2 0/9] Thermal throttling for SDM845 Amit Kucheria
2019-01-14 10:21 ` [PATCH v2 7/9] arm64: dts: sdm845: Increase alert trip point to 95 degrees Amit Kucheria
2019-01-14 10:21 ` [PATCH v2 8/9] arm64: dts: sdm845: wireup the thermal trip points to cpufreq Amit Kucheria
2019-01-14 22:01 ` Matthias Kaehlcke [this message]
2019-01-21 18:10 ` Amit Kucheria
2019-01-22 18:18 ` Matthias Kaehlcke
2019-01-14 10:27 ` [PATCH v2 0/9] Thermal throttling for SDM845 Rafael J. Wysocki
2019-01-14 10:34 ` Amit Kucheria
2019-01-14 16:52 ` 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=20190114220101.GN261387@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).