From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: cros-qcom-dts-watchers@chromium.org,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Taniya Das <quic_tdas@quicinc.com>,
Matthias Kaehlcke <mka@chromium.org>,
Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFT] arm64: dts: qcom: sc7280: Add missing LMH interrupts
Date: Fri, 25 Aug 2023 23:07:15 +0200 [thread overview]
Message-ID: <d413843f-5187-41ee-89aa-1f4dc0bc729d@linaro.org> (raw)
In-Reply-To: <CAD=FV=XKeE7_ciuvfAic+24kyOF0yaFT7iCJWgN9NaW-zG+vKA@mail.gmail.com>
On 25.08.2023 22:17, Doug Anderson wrote:
> Hi,
>
> On Fri, Aug 11, 2023 at 1:58 PM Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>> Hook up the interrupts that signal the Limits Management Hardware has
>> started some sort of throttling action.
>>
>> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>> test case:
>>
>> - hammer the CPUs (like compile the Linux kernel)
>> - watch -n1 "cat /proc/interrupts | grep dcvsh"
>> - the numbers go up up up up -> good
>
> I'm not doing much on sc7280 these days,
:( I'm really sad it got the boot
but I did try putting your
> patch on a sc7280-hoglin (AKA a CRD). I tried to stress the system out
> a bunch (ran 8 instances of "while true; do true; done" and opened
> something to activate the GPU). I didn't see any LMH interrupts fire.
> Of course, with ChromeOS firmware LMH is _supposed_ to be mostly
> disabled, so maybe that's right? Our policy was always to have Linux
> do as much of the throttling as possible and only use LMH as a last
> resort.
>
> I assume I don't need any specific config option turned on?
>
> I know that on other Qualcomm boards I see LMH nodes in the device
> tree, which we don't have in sc7280. Like "qcom,sdm845-lmh". Is that
> important? I haven't been following what's been going on with LMH in
> Linux since we try not to use it.
It used to be important, but on newer socs it's preconfigured in fw
>
> For giggles, I also tried putting the patch on a sc7280-villager
> device to see if it had different thermals. I even put my jacket over
> it to try to keep it warm. I saw the sensors go up to 109C on the
> medium cores and still no LMH interrupts. Oh, and then the device shut
> itself down. I guess something about thermal throttling in Linux must
> be disabled but then it still handles the critical state? :( That's
> concerning...
>
> I put the same kernel on a trogdor device and that did normal Linux
> throttling OK. So something is definitely wonky with sc7280... I dug
> enough to find that if I used "step_wise" instead of "power_allocator"
> that it works OK, so I guess something is wonky about the config of
> power_allocator on sc7280. In any case, it's not affected by your
> patch and I've already probably spent too much time on it. :-P
Hm, perhaps it would be worth to try this patch on a non-chrome 7280
device.. Would you guys have standard android-y or windows-y firmware
that you could flash on these to try out, or should I try poking
somebody else?
Konrad
next prev parent reply other threads:[~2023-08-25 21:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 20:58 [PATCH RFT] arm64: dts: qcom: sc7280: Add missing LMH interrupts Konrad Dybcio
2023-08-25 20:17 ` Doug Anderson
2023-08-25 21:07 ` Konrad Dybcio [this message]
2023-08-25 22:00 ` Doug Anderson
2023-09-19 23:07 ` Bjorn Andersson
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=d413843f-5187-41ee-89aa-1f4dc0bc729d@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mka@chromium.org \
--cc=quic_tdas@quicinc.com \
--cc=robh+dt@kernel.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).