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,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
quic_rgottimu@quicinc.com, quic_kshivnan@quicinc.com,
conor+dt@kernel.org, arm-scmi@vger.kernel.org
Subject: Re: [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions
Date: Wed, 6 Nov 2024 13:55:33 +0100 [thread overview]
Message-ID: <ZytnRc94iKUfMYH0@hovoldconsulting.com> (raw)
In-Reply-To: <20241007061023.1978380-1-quic_sibis@quicinc.com>
On Mon, Oct 07, 2024 at 11:40:18AM +0530, Sibi Sankar wrote:
> The QCOM SCMI vendor protocol provides a generic way of exposing a
> number of Qualcomm SoC specific features (like memory bus scaling)
> through a mixture of pre-determined algorithm strings and param_id
> pairs hosted on the SCMI controller. Introduce a client driver that
> uses the memlat algorithm string hosted on QCOM SCMI Vendor Protocol
> to detect memory latency workloads and control frequency/level of
> the various memory buses (DDR/LLCC/DDR_QOS).
>
> QCOM SCMI Generic Vendor protocol background:
> It was found that a lot of the vendor protocol used internally was
> for debug/internal development purposes that would either be super
> SoC specific or had to be disabled because of some features being
> fused out during production. This lead to a large number of vendor
> protocol numbers being quickly consumed and were never released
> either. Using a generic vendor protocol with functionality abstracted
> behind algorithm strings gave us the flexibility of allowing such
> functionality exist during initial development/debugging while
> still being able to expose functionality like memlat once they have
> matured enough. The param-ids are certainly expected to act as ABI
> for algorithms strings like MEMLAT.
I wanted to give this series a quick spin on the x1e80100 CRD, but ran
into some issues.
First, I expected the drivers to be loaded automatically when built as
modules, but that did not happen so something appears to be missing.
Second, after loading the protocol and client drivers manually (in that
order, shouldn't the client driver pull in the protocol?), I got:
scmi_module: Loaded SCMI Vendor Protocol 0x80 - Qualcomm 20000
arm-scmi arm-scmi.0.auto: QCOM Generic Vendor Version 1.0
scmi-qcom-generic-ext-memlat scmi_dev.5: error -EOPNOTSUPP: failed to configure common events
scmi-qcom-generic-ext-memlat scmi_dev.5: probe with driver scmi-qcom-generic-ext-memlat failed with error -95
which seems to suggest that the firmware on my CRD does not support this
feature. Is that the way this should be interpreted? And does that mean
that non of the commercial laptops supports this either?
Johan
next prev parent reply other threads:[~2024-11-06 12:55 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 6:10 [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar
2024-10-07 6:10 ` [PATCH V4 1/5] dt-bindings: firmware: Document bindings for QCOM SCMI Generic Extension Sibi Sankar
2024-10-07 18:06 ` Dmitry Baryshkov
2024-10-22 7:13 ` Sibi Sankar
2024-10-24 19:54 ` Dmitry Baryshkov
2024-10-08 6:47 ` Krzysztof Kozlowski
2024-10-08 6:49 ` Krzysztof Kozlowski
2024-10-08 12:10 ` Dmitry Baryshkov
2024-10-08 12:11 ` Krzysztof Kozlowski
2024-10-22 7:25 ` Sibi Sankar
2024-10-24 13:29 ` Krzysztof Kozlowski
2024-10-24 19:46 ` Dmitry Baryshkov
2024-10-24 19:48 ` Dmitry Baryshkov
2024-11-06 22:18 ` Jeffrey Hugo
2024-11-14 4:17 ` Sibi Sankar
2024-12-05 15:27 ` Sudeep Holla
2024-12-17 11:45 ` Sibi Sankar
2024-10-07 6:10 ` [PATCH V4 2/5] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar
2024-10-22 10:22 ` Cristian Marussi
2024-11-14 4:32 ` Sibi Sankar
2024-10-07 6:10 ` [PATCH V4 3/5] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar
2024-10-07 18:13 ` Dmitry Baryshkov
2024-10-22 7:18 ` Sibi Sankar
2024-10-07 6:10 ` [PATCH V4 4/5] soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor Sibi Sankar
2024-10-07 17:57 ` Dmitry Baryshkov
2024-10-22 8:18 ` Sibi Sankar
2024-10-26 18:16 ` Dmitry Baryshkov
2024-11-14 4:13 ` Sibi Sankar
2024-11-14 12:32 ` Dmitry Baryshkov
2024-12-05 10:52 ` Sibi Sankar
2024-12-05 11:30 ` Dmitry Baryshkov
2024-12-17 10:16 ` Sibi Sankar
2024-12-17 10:46 ` Dmitry Baryshkov
2024-12-17 11:05 ` Sibi Sankar
2024-12-17 12:10 ` Dmitry Baryshkov
[not found] ` <CGME20241114041419epcas1p3b52bb9795ffd9efa568bb106ba268e02@epcms1p5>
2024-11-15 0:38 ` MyungJoo Ham
2024-12-05 10:17 ` Sibi Sankar
2024-10-28 8:30 ` Cristian Marussi
2024-10-10 12:18 ` Jonathan Cameron
2024-10-22 7:31 ` Sibi Sankar
2024-10-22 12:00 ` Cristian Marussi
2024-11-29 9:57 ` Shivnandan Kumar
2024-12-05 11:03 ` Sibi Sankar
2024-12-05 12:39 ` Cristian Marussi
2024-12-23 13:57 ` Sibi Sankar
2024-10-07 6:10 ` [PATCH V4 5/5] arm64: dts: qcom: x1e80100: Enable LLCC/DDR/DDR_QOS dvfs Sibi Sankar
2024-10-08 6:52 ` [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Krzysztof Kozlowski
2024-10-22 8:24 ` Sibi Sankar
2024-11-06 12:55 ` Johan Hovold [this message]
2024-11-06 20:03 ` Cristian Marussi
2024-11-08 15:14 ` Johan Hovold
2024-11-14 4:22 ` Sibi Sankar
2024-11-22 8:37 ` Johan Hovold
2024-12-05 10:56 ` Sibi Sankar
2024-12-05 15:52 ` Johan Hovold
2024-12-17 11:49 ` Sibi Sankar
2024-12-19 10:37 ` Johan Hovold
2024-12-23 14:00 ` Sibi Sankar
2024-12-05 17:01 ` Sudeep Holla
2024-12-17 12:25 ` Sibi Sankar
2024-12-17 14:45 ` Cristian Marussi
2024-12-23 14:09 ` Sibi Sankar
2024-12-17 17:59 ` Sudeep Holla
2024-12-23 14:14 ` Sibi Sankar
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=ZytnRc94iKUfMYH0@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=andersson@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_kshivnan@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).