From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Sibi Sankar <quic_sibis@quicinc.com>,
sudeep.holla@arm.com, cristian.marussi@arm.com,
andersson@kernel.org, jassisinghbrar@gmail.com,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org
Cc: 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,
Amir Vajid <avajid@quicinc.com>
Subject: Re: [RFC 3/7] firmware: arm_scmi: Add QCOM vendor protocol
Date: Fri, 9 Feb 2024 23:45:06 +0100 [thread overview]
Message-ID: <34af183c-638a-49f3-b0b3-784f757282b2@linaro.org> (raw)
In-Reply-To: <2b1d9578-39cc-7836-a51b-be698bb50c43@quicinc.com>
On 8.02.2024 12:44, Sibi Sankar wrote:
>
>
> On 1/18/24 01:45, Konrad Dybcio wrote:
>>
>>
>> On 1/17/24 18:34, Sibi Sankar wrote:
>>> From: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>>>
>>> SCMI QCOM vendor protocol provides interface to communicate with SCMI
>>> controller and enable vendor specific features like bus scaling capable
>>> of running on it.
>>
>
> Hey Konrad,
>
>> "QCOM protocol" sounds overly generic, especially given how many
>> different vendor protocols have historically been present in
>> QC firmware..
>
> Here it is specifically mentioned that way to communicate that
> this is the only vendor protocol exposed by Qualcomm. It handles
> all the other protocols which were usually handled separately on
> older SoCs.
I'm no SCMI specialist but that's a rather.. peculiar design decision,
I guess
>
>>
>>>
>>> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>>> Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com>
>>> Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com>
>>> Co-developed-by: Amir Vajid <avajid@quicinc.com>
>>> Signed-off-by: Amir Vajid <avajid@quicinc.com>
>>> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com>
>>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
>>> ---
>>
>> So, this is another 0x80 protocol, different to the one that has
>> been shipping on devices that got released with msm-5.4, msm-5.10
>> and msm-5.15 [1][2]. They're totally incompatible (judging by the
>> msg format), use the same protocol ID and they are (at a glance)
>> providing access to the same HW/FW/tunables.
>
> Thanks for bringing this up but like I already explained the only
> SoC that was actually shipped with ^^ protocol was SC7180 and we
> already have an alternative arrangement for memory dvfs upstreamed
> on it.
Ok, that makes sense.
I took my 8550 phone, enabled some debug prints and it looks like the
only SCMI protocol exposed is 0x19 (which doesn't seem to be defined).
Not sure what other devices would spit out, but I assume what you said
is true.
For completeness, the reported rev is:
arm-scmi firmware:scmi: SCMI Protocol v2.0 'Qualcomm:' Firmware version 0x10000
> Further more it handles only L3 dvfs so it makes zero sense
> to try to upstream the older protocol given that working dvfs solution
> already exists upstream.
We don't have any sort of governor for it though, so I wouldn't go as
far as calling it working :P
> All other SoCs don't have the 0x80 protocol
> enabled for memory dvfs in production.
>
>>
>> I'm not sure if this can be trusted not to change again.. Unless
>> we get a strong commitment that all platforms (compute, mobile,
>> auto, iot, whatever) stick to this one..
>
> This is exactly that consolidation effort from Qualcomm. Here they
> expose just one vendor protocol and implement all the algorithms just
> through it.
And I'm very glad you're taking such consolidation steps.. Just a little
worried that in case this protocol's extensibility is exhausted, the next
one would need to be called.. "Qualcomm2"?
Konrad
next prev parent reply other threads:[~2024-02-09 22:45 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 17:34 [RFC 0/7] firmware: arm_scmi: Qualcomm Vendor Protocol Sibi Sankar
2024-01-17 17:34 ` [RFC 1/7] dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings Sibi Sankar
2024-01-17 19:53 ` Konrad Dybcio
2024-02-08 10:22 ` Sibi Sankar
2024-02-08 23:14 ` Konrad Dybcio
2024-02-12 5:48 ` Sibi Sankar
2024-01-30 17:12 ` Rob Herring
2024-02-08 10:28 ` Sibi Sankar
2024-02-08 15:58 ` Krzysztof Kozlowski
2024-02-28 17:37 ` Konrad Dybcio
2024-01-17 17:34 ` [RFC 2/7] mailbox: Add support for QTI CPUCP mailbox controller Sibi Sankar
2024-01-17 19:03 ` Dmitry Baryshkov
2024-01-17 17:34 ` [RFC 3/7] firmware: arm_scmi: Add QCOM vendor protocol Sibi Sankar
2024-01-17 19:09 ` Dmitry Baryshkov
2024-02-12 8:31 ` Sibi Sankar
2024-01-17 20:15 ` Konrad Dybcio
2024-01-17 20:31 ` Cristian Marussi
2024-02-08 11:44 ` Sibi Sankar
2024-02-09 22:45 ` Konrad Dybcio [this message]
2024-02-12 8:56 ` Sibi Sankar
2024-01-17 20:15 ` Konrad Dybcio
2024-01-18 17:22 ` Sudeep Holla
2024-02-12 9:14 ` Sibi Sankar
2024-02-12 17:39 ` Cristian Marussi
2024-02-29 14:16 ` Sudeep Holla
2024-02-29 14:24 ` Sudeep Holla
2024-01-17 17:34 ` [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs Sibi Sankar
2024-01-17 20:28 ` Konrad Dybcio
2024-02-12 10:33 ` Sibi Sankar
2024-06-18 19:37 ` Konrad Dybcio
2024-07-01 8:44 ` Sibi Sankar
2024-07-12 12:20 ` Konrad Dybcio
2024-01-17 20:41 ` Dmitry Baryshkov
2024-02-12 10:24 ` Sibi Sankar
2024-02-12 13:22 ` Dmitry Baryshkov
2024-02-20 15:07 ` Cristian Marussi
2024-02-28 17:31 ` Sibi Sankar
2024-02-29 14:27 ` Sudeep Holla
2024-02-20 16:19 ` Cristian Marussi
2024-02-29 14:41 ` Sudeep Holla
2024-01-17 17:34 ` [RFC 5/7] arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes Sibi Sankar
2024-01-17 17:34 ` [RFC 6/7] arm64: dts: qcom: x1e80100: Enable cpufreq Sibi Sankar
2024-01-18 15:25 ` Sudeep Holla
2024-02-12 9:28 ` Sibi Sankar
2024-01-17 17:34 ` [RFC 7/7] arm64: dts: qcom: x1e80100: Enable LLCC/DDR dvfs Sibi Sankar
2024-01-17 20:38 ` Konrad Dybcio
2024-02-12 10:05 ` Sibi Sankar
2024-01-17 20:47 ` Dmitry Baryshkov
2024-02-12 9:47 ` Sibi Sankar
2024-02-12 18:11 ` [RFC 0/7] firmware: arm_scmi: Qualcomm Vendor Protocol Cristian Marussi
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=34af183c-638a-49f3-b0b3-784f757282b2@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=andersson@kernel.org \
--cc=avajid@quicinc.com \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--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_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).