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

[Jesse Casco <jesse.casco@gmail.com>]

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