From: Johan Hovold <johan@kernel.org>
To: Sibi Sankar <quic_sibis@quicinc.com>
Cc: sudeep.holla@arm.com, cristian.marussi@arm.com,
andersson@kernel.org, konrad.dybcio@linaro.org,
jassisinghbrar@gmail.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, dmitry.baryshkov@linaro.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, quic_rgottimu@quicinc.com,
quic_kshivnan@quicinc.com, conor+dt@kernel.org,
quic_nkela@quicinc.com, quic_psodagud@quicinc.com,
abel.vesa@linaro.org
Subject: Re: [PATCH V6 5/5] arm64: dts: qcom: x1e80100: Enable cpufreq
Date: Tue, 9 Jul 2024 11:13:54 +0200 [thread overview]
Message-ID: <Zoz_UmPBWKHA37Kq@hovoldconsulting.com> (raw)
In-Reply-To: <f53bc00f-8217-1dc8-5203-1a83c24d353d@quicinc.com>
Hi Sibi,
On Wed, Jul 03, 2024 at 01:29:11AM +0530, Sibi Sankar wrote:
> On 7/2/24 21:25, Johan Hovold wrote:
> > On Wed, Jun 12, 2024 at 06:10:56PM +0530, Sibi Sankar wrote:
> >> Enable cpufreq on X1E80100 SoCs through the SCMI perf protocol node.
> > This series gives a nice performance boost on the x1e80100 CRD, but I'm
> > seeing a bunch of warnings and errors that need to be addressed:
> >
> > [ 9.533053] arm-scmi firmware:scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging.
> > [ 9.549458] arm-scmi firmware:scmi: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16
> > [ 9.563925] arm-scmi firmware:scmi: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16
> > [ 9.572835] arm-scmi firmware:scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging.
> > [ 9.609471] arm-scmi firmware:scmi: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16
> > [ 9.633341] arm-scmi firmware:scmi: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16
> > [ 9.650000] arm-scmi firmware:scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging.
>
> X1E uses fast channels only for message-id: 7 (level set) and regular
> channels for all the other messages. The spec doesn't mandate fast
> channels for any of the supported message ids for the perf protocol.
> So nothing to fix here.
I didn't look at this in any detail, but if the firmware is spec
compliant you should not be spamming the logs with warnings. Not sure
how best to address that, but you could, for example, add a quirk for
qcom fw or at a minimum demote this mess to info level.
Also the failure to add oops_by_lvl appears to be a separate issue (e.g.
related to the duplicate entries).
> > [ 9.727098] cpu cpu4: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
> > [ 9.737157] cpu cpu4: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
> > [ 9.875039] cpu cpu8: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
> > [ 9.888428] cpu cpu8: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
>
> The duplicate entries reported by the perf protocol come directly from
> the speed bins. I was told the duplicate entry with volt 0 is meant to
> indicate a lower power way of achieving the said frequency at a lower
> core count. We have no way of using it in the kernel and it gets safely
> discarded. So again nothing to fix in the kernel.
Again, you should not be spamming the logs with warnings for things are
benign (e.g. as it may prevent people from noticing real issues).
Also these duplicate entries do not seem to get safely discarded as they
result in a bunch of operations failing loudly at boot (e.g. the
oops_by_lvl warning above) and similarly at resume as I recently
noticed:
[ 42.690569] CPU4: Booted secondary processor 0x0000010000 [0x511f0011]
[ 42.704360] cpu cpu4: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
[ 42.737865] cpu cpu4: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
[ 42.752943] debugfs: File 'cpu5' in directory 'opp' already present!
[ 42.759956] debugfs: File 'cpu6' in directory 'opp' already present!
[ 42.766641] debugfs: File 'cpu7' in directory 'opp' already present!
...
[ 42.855520] CPU8: Booted secondary processor 0x0000020000 [0x511f0011]
[ 42.865188] cpu cpu8: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
[ 42.898494] cpu cpu8: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 3417600000, volt: 0, enabled: 1. New: freq: 3417600000, volt: 0, enabled: 1
[ 42.913559] debugfs: File 'cpu9' in directory 'opp' already present!
[ 42.920265] debugfs: File 'cpu10' in directory 'opp' already present!
[ 42.927029] debugfs: File 'cpu11' in directory 'opp' already present!
Perhaps you can find some way to filter out the unused, duplicate
entries for qualcomm fw so that all of these issues go away.
> > [ 9.913506] debugfs: Directory 'NCC' with parent 'pm_genpd' already present!
> > [ 9.922198] debugfs: Directory 'NCC' with parent 'pm_genpd' already present!
>
> Yeah I did notice ^^ during dev, the series isn't the one introducing it
> so it shouldn't block the series acceptance. Meanwhile I'll spend some
> cycles to get this warn fixed.
I didn't try to track down where this comes from, but figured it could
be related to the duplicate entries. Either way, these are actually
errors (not just warnings) that need to be addressed in some way.
Johan
next prev parent reply other threads:[~2024-07-09 9:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 12:40 [PATCH V6 0/5] qcom: x1e80100: Enable CPUFreq Sibi Sankar
2024-06-12 12:40 ` [PATCH V6 1/5] dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings Sibi Sankar
2024-06-12 12:40 ` [PATCH V6 2/5] mailbox: Add support for QTI CPUCP mailbox controller Sibi Sankar
2024-06-26 3:32 ` Bjorn Andersson
2024-06-26 9:43 ` Konrad Dybcio
2024-07-15 3:14 ` Nathan Chancellor
2024-06-12 12:40 ` [PATCH V6 3/5] arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region Sibi Sankar
2024-06-12 12:40 ` [PATCH V6 4/5] arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes Sibi Sankar
2024-06-12 12:40 ` [PATCH V6 5/5] arm64: dts: qcom: x1e80100: Enable cpufreq Sibi Sankar
2024-07-02 15:55 ` Johan Hovold
2024-07-02 19:59 ` Sibi Sankar
2024-07-02 20:13 ` Nikunj Kela
2024-07-03 11:23 ` Sibi Sankar
2024-07-03 14:05 ` Nikunj Kela
2024-07-04 10:22 ` Sibi Sankar
2024-07-09 9:13 ` Johan Hovold [this message]
2024-07-09 9:39 ` Konrad Dybcio
2024-07-16 10:45 ` Konrad Dybcio
2024-07-22 12:12 ` Konrad Dybcio
2024-10-16 20:38 ` (subset) [PATCH V6 0/5] qcom: x1e80100: Enable CPUFreq Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zoz_UmPBWKHA37Kq@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=abel.vesa@linaro.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=jassisinghbrar@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_kshivnan@quicinc.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_psodagud@quicinc.com \
--cc=quic_rgottimu@quicinc.com \
--cc=quic_sibis@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).