[ +CC: Marc, who I think I saw reporting something similar even if I can seem to find where right now ] On Wed, Oct 30, 2024 at 06:38:38PM +0530, Sibi Sankar wrote: > This series enables CPUFreq support on the X1E SoC using the SCMI perf > protocol. This was originally part of the RFC: firmware: arm_scmi: > Qualcomm Vendor Protocol [1]. I've split it up so that this part can > land earlier. Warnings Introduced by the series are fixed by [2] Sibi Sankar (2): > arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes > arm64: dts: qcom: x1e80100: Enable cpufreq I've been running with v6 of these for a while now, without noticing any issues, and just updated to v7 to be able to provide a Tested-by tag. I wanted to run a compilation and see how the frequencies varied, but before I got around to that I just grepped the cpufreq sysfs attributes for CPU0 four times. And this triggered a reset of the machine (x1e80100 CRD). The last values output were: affected_cpus:0 1 2 3 cpuinfo_cur_freq:<unknown> cpuinfo_max_freq:3417600 cpuinfo_min_freq:710400 cpuinfo_transition_latency:30000 related_cpus:0 1 2 3 scaling_available_frequencies:710400 806400 998400 1190400 1440000 1670400 1920000 2188800 2515200 2707200 2976000 320 scaling_available_governors:ondemand userspace performance schedutil scaling_cur_freq:806400 scaling_driver:scmi scaling_governor:schedutil scaling_max_freq:3417600 scaling_min_freq:710400 scaling_setspeed:<unsupported> Notice the <unknown> current frequency (the previous greps said 710400 and 2515200). The last thing I see on the serial console, presumably just before the reset, is: [ 196.268025] arm-scmi arm-scmi.0.auto: timed out in resp(caller: do_xfer+0x164/0x564) I just rebooted and grepped again and it triggered on the first attempt (cur_freq also said '<unknown>'). Same error in the log, printed when grepping. Johan
