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@xxxxxxxxxxxxxxxx> 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