From: Jesse Casco <jesse.casco@gmail.com>
To: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers
Date: Sat, 8 Aug 2026 13:22:11 -0400 [thread overview]
Message-ID: <20260808172211.137577-1-jesse.casco@gmail.com> (raw)
On glymur the CPUCP firmware writes correct SCMI replies into the shared
memory but never rings the mailbox doorbell for them. Every transfer that
waits for the completion interrupt therefore times out, scmi-cpufreq
fails to probe with -110, and the machine ends up with no cpufreq at all
-- all CPUs pinned at their boot OPP.
Measured on an ASUS Zenbook A16 (UX3607OA) through the SCMI RAW debugfs
interface: a Performance protocol (0x13) PROTOCOL_ATTRIBUTES request
returns status 0 and reports three performance domains when the transport
polls for completion, and never completes when it waits for the doorbell.
The mailbox interrupt count stays at zero throughout, so the reply is
being produced but never signalled.
Mark the transport arm,no-completion-irq so it polls. With this applied
scmi-cpufreq probes, three performance domains appear, and
cpu0/cpufreq/scaling_driver reads "scmi".
The property is documented in
Documentation/devicetree/bindings/firmware/arm,scmi.yaml, is consumed by
drivers/firmware/arm_scmi/driver.c, and is already used in-tree by
renesas/r8a78000-ironhide.
Assisted-by: Anthropic:Claude-Opus-5
Signed-off-by: Jesse Casco <jesse.casco@gmail.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f04058d2e..b9db81a19 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -412,6 +412,12 @@ scmi {
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri1>, <&cpu_scp_lpri0>;
+ /*
+ * The CPUCP writes SCMI replies into the shmem but
+ * never rings the completion doorbell, so poll.
+ */
+ arm,no-completion-irq;
+
#address-cells = <1>;
#size-cells = <0>;
base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727
--
2.55.0
reply other threads:[~2026-08-08 17:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260808172211.137577-1-jesse.casco@gmail.com \
--to=jesse.casco@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
/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