[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyTQ9QD1tEkhQ9eu@hovoldconsulting.com>
Date: Fri, 1 Nov 2024 14:00:37 +0100
From: Johan Hovold <johan@...nel.org>
To: Sibi Sankar <quic_sibis@...cinc.com>
Cc: sudeep.holla@....com, cristian.marussi@....com, andersson@...nel.org,
konrad.dybcio@...aro.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, dmitry.baryshkov@...aro.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, quic_rgottimu@...cinc.com,
quic_kshivnan@...cinc.com, conor+dt@...nel.org,
quic_nkela@...cinc.com, quic_psodagud@...cinc.com,
abel.vesa@...aro.org, Marc Zyngier <maz@...nel.org>
Subject: Re: [PATCH V7 0/2] qcom: x1e80100: Enable CPUFreq
[ +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
Powered by blists - more mailing lists