[PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers

[PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers

[Jesse Casco]

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

Re: [PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers

[Konrad Dybcio]

On 8/8/26 7:22 PM, Jesse Casco wrote:
> 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.

I'm not seeing this issue, but I heard others hit it, possibly due to some
timing bug. If you set your kernel config to build all drivers in (i.e.
change =m to =y), do you still face this?

Konrad

Re: [PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers

[Jesse Casco]

Tested. Everything SCMI-related was already =y except the mailbox
controller itself, qcom_cpucp_mbox, which was =m. Built that in,
pulled arm,no-completion-irq back out...No CMD timeout, no -110,
cpufreq comes up fine.  Looks like exactly the timing bug you
mentioned.

Keeping arm,no-completion-irq for daily use since it doesn't depend on
build config, but happy to test more if useful.


Jesse


On Tue, Aug 18, 2026 at 5:29 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 8/8/26 7:22 PM, Jesse Casco wrote:
> > 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.
>
> I'm not seeing this issue, but I heard others hit it, possibly due to some
> timing bug. If you set your kernel config to build all drivers in (i.e.
> change =m to =y), do you still face this?
>
> Konrad



-- 
Jesse Casco

Re: [PATCH] arm64: dts: qcom: glymur: use polling mode for SCMI transfers

[Jesse Casco]

Hi Konrad, Sibi,

I tracked down the timing issue on the ASUS Zenbook A16 (7.4-rc1 based,
arm,no-completion-irq removed). It depends on whether PSCI cpuidle is
already running when SCMI sends its first PERF (0x13) message:

- CPUCP_MBOX=y: first PERF message at 0.37 s, before cpuidle starts.
  PERF works for the whole boot, cpuidle included.
- CPUCP_MBOX=m (arm64 defconfig): first PERF message at 1.1-1.4 s,
  after cpuidle starts. No PERF reply ever gets a doorbell, so
  scmi-cpufreq and scmi-perf-domain fail with -110. BASE replies still
  ring.
- CPUCP_MBOX=m with cpuidle.off=1: PERF works.

In the failing case the firmware still writes the PERF replies (the
same request through SCMI RAW message_poll returns status 0), but
RX_MBOX_STAT never gets a bit, with EN=0x3 and MAP=~0, the same as in
the working case. So it looks like the CPUCP decides at the first PERF
exchange whether to ring for PERF, rather than a mailbox driver bug.

Please consider the DT patch withdrawn. Sibi, is this a known CPUCP
firmware behavior? In the meantime I could send an arm64 defconfig
change building QCOM_CPUCP_MBOX in, so defconfig kernels get cpufreq on
this machine, if that's acceptable.

Jesse