* [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions
@ 2024-11-15 1:15 Sibi Sankar
2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Sibi Sankar @ 2024-11-15 1:15 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio
Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu,
quic_kshivnan, quic_sibis, arm-scmi
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.
Thanks in advance for taking time to review the series.
V4:
* Splitting the series into vendor protocol and memlat client.
Also the move the memlat client implementation back to RFC
due to multiple opens.
* Use common xfer helper to avoid code duplication [Dmitry]
* Update enum documentation without duplicate enum info [Dmitry]
* Update the protol attributes doc with more information. [Cristian]
V3:
* Restructure the bindings to mimic IMX [Christian]
* Add documentation for the qcom generic vendor protocol [Christian/Sudeep]
* Pick up Rb tag and fixup/re-order elements of the vendor ops [Christian]
* Follow naming convention and folder structure used by IMX
* Add missing enum in the vendor protocol and fix documentation [Konrad]
* Add missing enum in the scmi memlat driver and fix documentation [Konrad]
* Add checks for max memory and monitor [Shivnandan]
* Fix typo from START_TIMER -> STOP_TIMER [Shivnandan]
* Make populate_physical_mask func to void [Shivnandan]
* Remove unecessary zero set [Shivnandan]
* Use __free(device node) in init_cpufreq-memfreqmap [Christian/Konrad]
* Use sdev->dev.of_node directly [Christian]
* use return dev_err_probe in multiple places [Christian]
V2:
* Drop container dvfs memlat container node. [Rob]
* Move scmi-memlat.yaml to protocol level given that a lot of vendors might end up
* using the same protocol number. [Rob]
* Replace qcom,cpulist with the standard "cpus" property. [Rob]
* Fix up compute-type/ipm-ceil required. [Rob]
* Make driver changes to the accommodate bindings changes. [Rob]
* Minor fixups in subjects/coverletter.
* Minor style fixes in dts.
V1:
* Add missing bindings for the protocol. [Konrad/Dmitry]
* Use alternate bindings. [Dmitry/Konrad]
* Rebase on top of Cristian's "SCMI multiple vendor protocol support" series. [Cristian]
* Add more documentation wherever possible. [Sudeep]
* Replace pr_err/info with it's dev equivalents.
* Mixed tabs and initialization cleanups in the memlat driver. [Konrad]
* Commit message update for the memlat driver. [Dmitry]
* Cleanups/Fixes suggested for the client driver. [Dmitry/Konrad/Cristian]
* Use opp-tables instead of memfreq-tbl. [Dmitry/Konrad]
* Detect physical cpu to deal with variants with reduced cpu count.
* Add support for DDR_QOS mem_type.
Sibi Sankar (2):
firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation
firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
drivers/firmware/arm_scmi/Kconfig | 1 +
drivers/firmware/arm_scmi/Makefile | 1 +
.../firmware/arm_scmi/vendors/qcom/Kconfig | 15 ++
.../firmware/arm_scmi/vendors/qcom/Makefile | 2 +
.../arm_scmi/vendors/qcom/qcom-generic-ext.c | 139 ++++++++++++
.../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++
include/linux/scmi_qcom_protocol.h | 37 +++
7 files changed, 406 insertions(+)
create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Kconfig
create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Makefile
create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c
create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst
create mode 100644 include/linux/scmi_qcom_protocol.h
--
2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-11-15 1:15 [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar @ 2024-11-15 1:15 ` Sibi Sankar 2024-12-04 11:48 ` Cristian Marussi 2024-12-05 15:53 ` Sudeep Holla 2024-11-15 1:15 ` [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar 2024-12-05 16:35 ` [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sudeep Holla 2 siblings, 2 replies; 10+ messages in thread From: Sibi Sankar @ 2024-11-15 1:15 UTC (permalink / raw) To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, quic_sibis, arm-scmi Add QCOM System Control Management Interface (SCMI) Generic Vendor Extensions Protocol documentation. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> --- v4: * Update the protol attributes doc with more information. [Cristian] .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst new file mode 100644 index 000000000000..141bc932e30f --- /dev/null +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst @@ -0,0 +1,211 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=============================================================================== +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension +=============================================================================== + +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. + +:Author: Sibi Sankar <quic_sibis@quicinc.com> + +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol +================================================================================== + +This protocol is intended as a generic way of exposing a number of Qualcomm +SoC specific features through a mixture of pre-determined algorithm string and +param_id pairs hosted on the SCMI controller. It implements an interface compliant +with the Arm SCMI Specification with additional vendor specific commands as +detailed below. + +Commands: +_________ + +PROTOCOL_VERSION +~~~~~~~~~~~~~~~~ + +message_id: 0x0 +protocol_id: 0x80 + ++---------------+--------------------------------------------------------------+ +|Return values | ++---------------+--------------------------------------------------------------+ +|Name |Description | ++---------------+--------------------------------------------------------------+ +|int32 status |See ARM SCMI Specification for status code definitions. | ++---------------+--------------------------------------------------------------+ +|uint32 version |For this revision of the specification, this value must be | +| |0x10000. | ++---------------+--------------------------------------------------------------+ + +PROTOCOL_ATTRIBUTES +~~~~~~~~~~~~~~~~~~~ + +message_id: 0x1 +protocol_id: 0x80 + ++---------------+--------------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |See ARM SCMI Specification for status code definitions. | ++------------------+-----------------------------------------------------------+ +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | +| |Bits[15:8] Number of agents in the system | +| |Bits[7:0] Number of vendor protocols in the system | ++------------------+-----------------------------------------------------------+ + +PROTOCOL_MESSAGE_ATTRIBUTES +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +message_id: 0x2 +protocol_id: 0x80 + ++---------------+--------------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |See ARM SCMI Specification for status code definitions. | ++------------------+-----------------------------------------------------------+ +|uint32 attributes |For all message id's the parameter has a value of 0. | ++------------------+-----------------------------------------------------------+ + +QCOM_SCMI_SET_PARAM +~~~~~~~~~~~~~~~~~~~ + +message_id: 0x10 +protocol_id: 0x80 + ++------------------+-----------------------------------------------------------+ +|Parameters | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|uint32 ext_id |Reserved, must be zero. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_low |Lower 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_high |Upper 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 param_id |Serves as the token message id for the algorithm string | +| |and is used to set various parameters supported by it. | ++------------------+-----------------------------------------------------------+ +|uint32 buf[] |Serves as the payload for the specified param_id and | +| |algorithm string pair. | ++------------------+-----------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | +| |by the chosen algorithm string. | +| |NOT_SUPPORTED: if the algorithm string does not have any | +| |matches. | +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | +| |is rejected by the algorithm string. | ++------------------+-----------------------------------------------------------+ + +QCOM_SCMI_GET_PARAM +~~~~~~~~~~~~~~~~~~~ + +message_id: 0x11 +protocol_id: 0x80 + ++------------------+-----------------------------------------------------------+ +|Parameters | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|uint32 ext_id |Reserved, must be zero. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_low |Lower 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_high |Upper 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 param_id |Serves as the token message id for the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 buf[] |Serves as the payload and store of value for the specified | +| |param_id and algorithm string pair. | ++------------------+-----------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | +| |by the chosen algorithm string and the result is copied | +| |into buf[]. | +| |NOT_SUPPORTED: if the algorithm string does not have any | +| |matches. | +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | +| |is rejected by the algorithm string. | ++------------------+-----------------------------------------------------------+ + +QCOM_SCMI_START_ACTIVITY +~~~~~~~~~~~~~~~~~~~~~~~~ + +message_id: 0x12 +protocol_id: 0x80 + ++------------------+-----------------------------------------------------------+ +|Parameters | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|uint32 ext_id |Reserved, must be zero. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_low |Lower 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_high |Upper 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 param_id |Serves as the token message id for the algorithm string | +| |and is generally used to start the activity performed by | +| |the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 buf[] |Serves as the payload for the specified param_id and | +| |algorithm string pair. | ++------------------+-----------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |SUCCESS: if the activity performed by the algorithm string | +| |starts successfully. | +| |NOT_SUPPORTED: if the algorithm string does not have any. | +| |matches or if the activity is already running. | ++------------------+-----------------------------------------------------------+ + +QCOM_SCMI_STOP_ACTIVITY +~~~~~~~~~~~~~~~~~~~~~~~ + +message_id: 0x13 +protocol_id: 0x80 + ++------------------+-----------------------------------------------------------+ +|Parameters | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|uint32 ext_id |Reserved, must be zero. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_low |Lower 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 algo_high |Upper 32-bit value of the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 param_id |Serves as the token message id for the algorithm string | +| |and is generally used to stop the activity performed by | +| |the algorithm string. | ++------------------+-----------------------------------------------------------+ +|uint32 buf[] |Serves as the payload for the specified param_id and | +| |algorithm string pair. | ++------------------+-----------------------------------------------------------+ +|Return values | ++------------------+-----------------------------------------------------------+ +|Name |Description | ++------------------+-----------------------------------------------------------+ +|int32 status |SUCCESS: if the activity performed by the algorithm string | +| |stops successfully. | +| |NOT_SUPPORTED: if the algorithm string does not have any | +| |matches or if the activity isn't running. | ++------------------+-----------------------------------------------------------+ -- 2.34.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar @ 2024-12-04 11:48 ` Cristian Marussi 2024-12-05 11:07 ` Sibi Sankar 2024-12-05 15:53 ` Sudeep Holla 1 sibling, 1 reply; 10+ messages in thread From: Cristian Marussi @ 2024-12-04 11:48 UTC (permalink / raw) To: Sibi Sankar Cc: sudeep.holla, cristian.marussi, andersson, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On Fri, Nov 15, 2024 at 06:45:14AM +0530, Sibi Sankar wrote: > Add QCOM System Control Management Interface (SCMI) Generic Vendor > Extensions Protocol documentation. > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > --- > > v4: > * Update the protol attributes doc with more information. [Cristian] > > .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ > 1 file changed, 211 insertions(+) > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > new file mode 100644 > index 000000000000..141bc932e30f > --- /dev/null > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > @@ -0,0 +1,211 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. include:: <isonum.txt> > + > +=============================================================================== > +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension > +=============================================================================== > + > +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + > +:Author: Sibi Sankar <quic_sibis@quicinc.com> > + > +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol > +================================================================================== > + > +This protocol is intended as a generic way of exposing a number of Qualcomm > +SoC specific features through a mixture of pre-determined algorithm string and > +param_id pairs hosted on the SCMI controller. It implements an interface compliant > +with the Arm SCMI Specification with additional vendor specific commands as > +detailed below. > + > +Commands: > +_________ > + > +PROTOCOL_VERSION > +~~~~~~~~~~~~~~~~ > + > +message_id: 0x0 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++---------------+--------------------------------------------------------------+ > +|Name |Description | > ++---------------+--------------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++---------------+--------------------------------------------------------------+ > +|uint32 version |For this revision of the specification, this value must be | > +| |0x10000. | > ++---------------+--------------------------------------------------------------+ > + > +PROTOCOL_ATTRIBUTES > +~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x1 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++------------------+-----------------------------------------------------------+ > +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | > +| |Bits[15:8] Number of agents in the system | > +| |Bits[7:0] Number of vendor protocols in the system | > ++------------------+-----------------------------------------------------------+ Thanks of clarifing this....may I ask why number of agents is reported here too given that it is already exposed by Base protocol ? Not really arguing about this so much, but you will end up having to maintain this on 2 different protocols fw side...or are they not 'agents' in the SCMI meaning ? Anyway, I'm fine with it, even though you dont seem to use this anywhere. > + > +PROTOCOL_MESSAGE_ATTRIBUTES > +~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x2 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++------------------+-----------------------------------------------------------+ > +|uint32 attributes |For all message id's the parameter has a value of 0. | > ++------------------+-----------------------------------------------------------+ > + > +QCOM_SCMI_SET_PARAM > +~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x10 > +protocol_id: 0x80 > + > ++------------------+-----------------------------------------------------------+ > +|Parameters | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|uint32 ext_id |Reserved, must be zero. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_low |Lower 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_high |Upper 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 param_id |Serves as the token message id for the algorithm string | > +| |and is used to set various parameters supported by it. | > ++------------------+-----------------------------------------------------------+ > +|uint32 buf[] |Serves as the payload for the specified param_id and | > +| |algorithm string pair. | > ++------------------+-----------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | > +| |by the chosen algorithm string. | > +| |NOT_SUPPORTED: if the algorithm string does not have any | > +| |matches. | > +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | > +| |is rejected by the algorithm string. | > ++------------------+-----------------------------------------------------------+ > + > +QCOM_SCMI_GET_PARAM > +~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x11 > +protocol_id: 0x80 > + > ++------------------+-----------------------------------------------------------+ > +|Parameters | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|uint32 ext_id |Reserved, must be zero. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_low |Lower 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_high |Upper 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 param_id |Serves as the token message id for the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 buf[] |Serves as the payload and store of value for the specified | > +| |param_id and algorithm string pair. | > ++------------------+-----------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | > +| |by the chosen algorithm string and the result is copied | > +| |into buf[]. | > +| |NOT_SUPPORTED: if the algorithm string does not have any | > +| |matches. | > +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | > +| |is rejected by the algorithm string. | > ++------------------+-----------------------------------------------------------+ ..missed this last time...so you should add here also a field describing the reply buf right ? (as it happenns really in your code) something like: ++------------------+-----------------------------------------------------------+ +|uint32 buf[] |Holds the payload of the result of the query. | +| | | ++------------------+-----------------------------------------------------------+ Thanks, Cristian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-12-04 11:48 ` Cristian Marussi @ 2024-12-05 11:07 ` Sibi Sankar 2024-12-05 11:37 ` Cristian Marussi 2024-12-05 15:32 ` Sudeep Holla 0 siblings, 2 replies; 10+ messages in thread From: Sibi Sankar @ 2024-12-05 11:07 UTC (permalink / raw) To: Cristian Marussi Cc: sudeep.holla, andersson, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On 12/4/24 17:18, Cristian Marussi wrote: > On Fri, Nov 15, 2024 at 06:45:14AM +0530, Sibi Sankar wrote: >> Add QCOM System Control Management Interface (SCMI) Generic Vendor >> Extensions Protocol documentation. >> >> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >> --- >> >> v4: >> * Update the protol attributes doc with more information. [Cristian] >> >> .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ >> 1 file changed, 211 insertions(+) >> create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst >> >> diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst >> new file mode 100644 >> index 000000000000..141bc932e30f >> --- /dev/null >> +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst >> @@ -0,0 +1,211 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> +.. include:: <isonum.txt> >> + >> +=============================================================================== >> +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension >> +=============================================================================== >> + >> +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. >> + >> +:Author: Sibi Sankar <quic_sibis@quicinc.com> >> + >> +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol >> +================================================================================== >> + >> +This protocol is intended as a generic way of exposing a number of Qualcomm >> +SoC specific features through a mixture of pre-determined algorithm string and >> +param_id pairs hosted on the SCMI controller. It implements an interface compliant >> +with the Arm SCMI Specification with additional vendor specific commands as >> +detailed below. >> + >> +Commands: >> +_________ >> + >> +PROTOCOL_VERSION >> +~~~~~~~~~~~~~~~~ >> + >> +message_id: 0x0 >> +protocol_id: 0x80 >> + >> ++---------------+--------------------------------------------------------------+ >> +|Return values | >> ++---------------+--------------------------------------------------------------+ >> +|Name |Description | >> ++---------------+--------------------------------------------------------------+ >> +|int32 status |See ARM SCMI Specification for status code definitions. | >> ++---------------+--------------------------------------------------------------+ >> +|uint32 version |For this revision of the specification, this value must be | >> +| |0x10000. | >> ++---------------+--------------------------------------------------------------+ >> + >> +PROTOCOL_ATTRIBUTES >> +~~~~~~~~~~~~~~~~~~~ >> + >> +message_id: 0x1 >> +protocol_id: 0x80 >> + >> ++---------------+--------------------------------------------------------------+ >> +|Return values | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|int32 status |See ARM SCMI Specification for status code definitions. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | >> +| |Bits[15:8] Number of agents in the system | >> +| |Bits[7:0] Number of vendor protocols in the system | >> ++------------------+-----------------------------------------------------------+ > > Thanks of clarifing this....may I ask why number of agents is reported > here too given that it is already exposed by Base protocol ? > > Not really arguing about this so much, but you will end up having to maintain this > on 2 different protocols fw side...or are they not 'agents' in the SCMI meaning ? > > Anyway, I'm fine with it, even though you dont seem to use this > anywhere. We don't use it anywhere and it looks like it was just put together so that this protocol is compliant to the spec :| > >> + >> +PROTOCOL_MESSAGE_ATTRIBUTES >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +message_id: 0x2 >> +protocol_id: 0x80 >> + >> ++---------------+--------------------------------------------------------------+ >> +|Return values | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|int32 status |See ARM SCMI Specification for status code definitions. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 attributes |For all message id's the parameter has a value of 0. | >> ++------------------+-----------------------------------------------------------+ >> + >> +QCOM_SCMI_SET_PARAM >> +~~~~~~~~~~~~~~~~~~~ >> + >> +message_id: 0x10 >> +protocol_id: 0x80 >> + >> ++------------------+-----------------------------------------------------------+ >> +|Parameters | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 ext_id |Reserved, must be zero. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 algo_low |Lower 32-bit value of the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 algo_high |Upper 32-bit value of the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 param_id |Serves as the token message id for the algorithm string | >> +| |and is used to set various parameters supported by it. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 buf[] |Serves as the payload for the specified param_id and | >> +| |algorithm string pair. | >> ++------------------+-----------------------------------------------------------+ >> +|Return values | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | >> +| |by the chosen algorithm string. | >> +| |NOT_SUPPORTED: if the algorithm string does not have any | >> +| |matches. | >> +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | >> +| |is rejected by the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> + >> +QCOM_SCMI_GET_PARAM >> +~~~~~~~~~~~~~~~~~~~ >> + >> +message_id: 0x11 >> +protocol_id: 0x80 >> + >> ++------------------+-----------------------------------------------------------+ >> +|Parameters | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 ext_id |Reserved, must be zero. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 algo_low |Lower 32-bit value of the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 algo_high |Upper 32-bit value of the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 param_id |Serves as the token message id for the algorithm string. | >> ++------------------+-----------------------------------------------------------+ >> +|uint32 buf[] |Serves as the payload and store of value for the specified | >> +| |param_id and algorithm string pair. | >> ++------------------+-----------------------------------------------------------+ >> +|Return values | >> ++------------------+-----------------------------------------------------------+ >> +|Name |Description | >> ++------------------+-----------------------------------------------------------+ >> +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | >> +| |by the chosen algorithm string and the result is copied | >> +| |into buf[]. | >> +| |NOT_SUPPORTED: if the algorithm string does not have any | >> +| |matches. | >> +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | >> +| |is rejected by the algorithm string. | >> ++------------------+-----------------------------------------------------------+ > > ..missed this last time...so you should add here also a field describing > the reply buf right ? (as it happenns really in your code) something > like: > > ++------------------+-----------------------------------------------------------+ > +|uint32 buf[] |Holds the payload of the result of the query. | > +| | | > ++------------------+-----------------------------------------------------------+ Thanks will get this added in the next re-spin. -Sibi > > Thanks, > Cristian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-12-05 11:07 ` Sibi Sankar @ 2024-12-05 11:37 ` Cristian Marussi 2024-12-05 15:32 ` Sudeep Holla 1 sibling, 0 replies; 10+ messages in thread From: Cristian Marussi @ 2024-12-05 11:37 UTC (permalink / raw) To: Sibi Sankar Cc: Cristian Marussi, sudeep.holla, andersson, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On Thu, Dec 05, 2024 at 04:37:28PM +0530, Sibi Sankar wrote: > > > On 12/4/24 17:18, Cristian Marussi wrote: > > On Fri, Nov 15, 2024 at 06:45:14AM +0530, Sibi Sankar wrote: > > > Add QCOM System Control Management Interface (SCMI) Generic Vendor > > > Extensions Protocol documentation. > > > > > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > > > --- > > > > > > v4: > > > * Update the protol attributes doc with more information. [Cristian] > > > > > > .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ > > > 1 file changed, 211 insertions(+) > > > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > > > > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > new file mode 100644 > > > index 000000000000..141bc932e30f > > > --- /dev/null > > > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > @@ -0,0 +1,211 @@ > > > +.. SPDX-License-Identifier: GPL-2.0 > > > +.. include:: <isonum.txt> > > > + > > > +=============================================================================== > > > +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension > > > +=============================================================================== > > > + > > > +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. > > > + > > > +:Author: Sibi Sankar <quic_sibis@quicinc.com> > > > + > > > +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol > > > +================================================================================== > > > + > > > +This protocol is intended as a generic way of exposing a number of Qualcomm > > > +SoC specific features through a mixture of pre-determined algorithm string and > > > +param_id pairs hosted on the SCMI controller. It implements an interface compliant > > > +with the Arm SCMI Specification with additional vendor specific commands as > > > +detailed below. > > > + > > > +Commands: > > > +_________ > > > + > > > +PROTOCOL_VERSION > > > +~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x0 > > > +protocol_id: 0x80 > > > + > > > ++---------------+--------------------------------------------------------------+ > > > +|Return values | > > > ++---------------+--------------------------------------------------------------+ > > > +|Name |Description | > > > ++---------------+--------------------------------------------------------------+ > > > +|int32 status |See ARM SCMI Specification for status code definitions. | > > > ++---------------+--------------------------------------------------------------+ > > > +|uint32 version |For this revision of the specification, this value must be | > > > +| |0x10000. | > > > ++---------------+--------------------------------------------------------------+ > > > + > > > +PROTOCOL_ATTRIBUTES > > > +~~~~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x1 > > > +protocol_id: 0x80 > > > + > > > ++---------------+--------------------------------------------------------------+ > > > +|Return values | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|int32 status |See ARM SCMI Specification for status code definitions. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | > > > +| |Bits[15:8] Number of agents in the system | > > > +| |Bits[7:0] Number of vendor protocols in the system | > > > ++------------------+-----------------------------------------------------------+ > > > > Thanks of clarifing this....may I ask why number of agents is reported > > here too given that it is already exposed by Base protocol ? > > > > Not really arguing about this so much, but you will end up having to maintain this > > on 2 different protocols fw side...or are they not 'agents' in the SCMI meaning ? > > > > Anyway, I'm fine with it, even though you dont seem to use this > > anywhere. > > We don't use it anywhere and it looks like it was just put together > so that this protocol is compliant to the spec :| > mmm...you mean the vendor protocol is compliant with this vendor doc ? ...because while PROTOCOL_ATTRIBUTES(0x1) is a mandatory command for each protocols (including vendors) there isn't any expectation from the spec to expose such info like agents and vendors protos....it is expected to expose attributes specific to the protocol itself...or nothing if you dont need anything. > > > > > + > > > +PROTOCOL_MESSAGE_ATTRIBUTES > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x2 > > > +protocol_id: 0x80 > > > + > > > ++---------------+--------------------------------------------------------------+ > > > +|Return values | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|int32 status |See ARM SCMI Specification for status code definitions. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 attributes |For all message id's the parameter has a value of 0. | > > > ++------------------+-----------------------------------------------------------+ > > > + > > > +QCOM_SCMI_SET_PARAM > > > +~~~~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x10 > > > +protocol_id: 0x80 > > > + > > > ++------------------+-----------------------------------------------------------+ > > > +|Parameters | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 ext_id |Reserved, must be zero. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 algo_low |Lower 32-bit value of the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 algo_high |Upper 32-bit value of the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 param_id |Serves as the token message id for the algorithm string | > > > +| |and is used to set various parameters supported by it. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 buf[] |Serves as the payload for the specified param_id and | > > > +| |algorithm string pair. | > > > ++------------------+-----------------------------------------------------------+ > > > +|Return values | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | > > > +| |by the chosen algorithm string. | > > > +| |NOT_SUPPORTED: if the algorithm string does not have any | > > > +| |matches. | > > > +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | > > > +| |is rejected by the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > + > > > +QCOM_SCMI_GET_PARAM > > > +~~~~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x11 > > > +protocol_id: 0x80 > > > + > > > ++------------------+-----------------------------------------------------------+ > > > +|Parameters | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 ext_id |Reserved, must be zero. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 algo_low |Lower 32-bit value of the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 algo_high |Upper 32-bit value of the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 param_id |Serves as the token message id for the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 buf[] |Serves as the payload and store of value for the specified | > > > +| |param_id and algorithm string pair. | > > > ++------------------+-----------------------------------------------------------+ > > > +|Return values | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | > > > +| |by the chosen algorithm string and the result is copied | > > > +| |into buf[]. | > > > +| |NOT_SUPPORTED: if the algorithm string does not have any | > > > +| |matches. | > > > +| |INVALID_PARAMETERS: if the param_id and the buf[] passed | > > > +| |is rejected by the algorithm string. | > > > ++------------------+-----------------------------------------------------------+ > > > > ..missed this last time...so you should add here also a field describing > > the reply buf right ? (as it happenns really in your code) something > > like: > > > > ++------------------+-----------------------------------------------------------+ > > +|uint32 buf[] |Holds the payload of the result of the query. | > > +| | | > > ++------------------+-----------------------------------------------------------+ > > Thanks will get this added in the next re-spin. > Ok. Thanks, Cristian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-12-05 11:07 ` Sibi Sankar 2024-12-05 11:37 ` Cristian Marussi @ 2024-12-05 15:32 ` Sudeep Holla 1 sibling, 0 replies; 10+ messages in thread From: Sudeep Holla @ 2024-12-05 15:32 UTC (permalink / raw) To: Sibi Sankar Cc: Cristian Marussi, andersson, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On Thu, Dec 05, 2024 at 04:37:28PM +0530, Sibi Sankar wrote: > > > On 12/4/24 17:18, Cristian Marussi wrote: > > On Fri, Nov 15, 2024 at 06:45:14AM +0530, Sibi Sankar wrote: > > > Add QCOM System Control Management Interface (SCMI) Generic Vendor > > > Extensions Protocol documentation. > > > > > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > > > --- > > > > > > v4: > > > * Update the protol attributes doc with more information. [Cristian] > > > > > > .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ > > > 1 file changed, 211 insertions(+) > > > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > > > > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > new file mode 100644 > > > index 000000000000..141bc932e30f > > > --- /dev/null > > > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > > @@ -0,0 +1,211 @@ > > > +.. SPDX-License-Identifier: GPL-2.0 > > > +.. include:: <isonum.txt> > > > + > > > +=============================================================================== > > > +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension > > > +=============================================================================== > > > + > > > +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. > > > + > > > +:Author: Sibi Sankar <quic_sibis@quicinc.com> > > > + > > > +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol > > > +================================================================================== > > > + > > > +This protocol is intended as a generic way of exposing a number of Qualcomm > > > +SoC specific features through a mixture of pre-determined algorithm string and > > > +param_id pairs hosted on the SCMI controller. It implements an interface compliant > > > +with the Arm SCMI Specification with additional vendor specific commands as > > > +detailed below. > > > + > > > +Commands: > > > +_________ > > > + > > > +PROTOCOL_VERSION > > > +~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x0 > > > +protocol_id: 0x80 > > > + > > > ++---------------+--------------------------------------------------------------+ > > > +|Return values | > > > ++---------------+--------------------------------------------------------------+ > > > +|Name |Description | > > > ++---------------+--------------------------------------------------------------+ > > > +|int32 status |See ARM SCMI Specification for status code definitions. | > > > ++---------------+--------------------------------------------------------------+ > > > +|uint32 version |For this revision of the specification, this value must be | > > > +| |0x10000. | > > > ++---------------+--------------------------------------------------------------+ > > > + > > > +PROTOCOL_ATTRIBUTES > > > +~~~~~~~~~~~~~~~~~~~ > > > + > > > +message_id: 0x1 > > > +protocol_id: 0x80 > > > + > > > ++---------------+--------------------------------------------------------------+ > > > +|Return values | > > > ++------------------+-----------------------------------------------------------+ > > > +|Name |Description | > > > ++------------------+-----------------------------------------------------------+ > > > +|int32 status |See ARM SCMI Specification for status code definitions. | > > > ++------------------+-----------------------------------------------------------+ > > > +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | > > > +| |Bits[15:8] Number of agents in the system | > > > +| |Bits[7:0] Number of vendor protocols in the system | > > > ++------------------+-----------------------------------------------------------+ > > > > Thanks of clarifing this....may I ask why number of agents is reported > > here too given that it is already exposed by Base protocol ? > > > > Not really arguing about this so much, but you will end up having to maintain this > > on 2 different protocols fw side...or are they not 'agents' in the SCMI meaning ? > > > > Anyway, I'm fine with it, even though you dont seem to use this > > anywhere. > > We don't use it anywhere and it looks like it was just put together > so that this protocol is compliant to the spec :| Interesting, I need to dig and check if that is needed to be compliant. Even if it is required, please add a text to say it must match what std. BASE protocol response(IOW it just can't be random here as you don't use it anymore). We may decide to match and warn if required at all. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation 2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar 2024-12-04 11:48 ` Cristian Marussi @ 2024-12-05 15:53 ` Sudeep Holla 1 sibling, 0 replies; 10+ messages in thread From: Sudeep Holla @ 2024-12-05 15:53 UTC (permalink / raw) To: Sibi Sankar Cc: cristian.marussi, andersson, Sudeep Holla, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On Fri, Nov 15, 2024 at 06:45:14AM +0530, Sibi Sankar wrote: > Add QCOM System Control Management Interface (SCMI) Generic Vendor > Extensions Protocol documentation. > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > --- > > v4: > * Update the protol attributes doc with more information. [Cristian] > > .../arm_scmi/vendors/qcom/qcom_generic.rst | 211 ++++++++++++++++++ > 1 file changed, 211 insertions(+) > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > new file mode 100644 > index 000000000000..141bc932e30f > --- /dev/null > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst > @@ -0,0 +1,211 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. include:: <isonum.txt> > + > +=============================================================================== > +QCOM System Control and Management Interface(SCMI) Vendor Protocols Extension > +=============================================================================== > + > +:Copyright: |copy| 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + > +:Author: Sibi Sankar <quic_sibis@quicinc.com> > + > +SCMI_GENERIC: System Control and Management Interface QCOM Generic Vendor Protocol > +================================================================================== > + > +This protocol is intended as a generic way of exposing a number of Qualcomm > +SoC specific features through a mixture of pre-determined algorithm string and > +param_id pairs hosted on the SCMI controller. It implements an interface compliant > +with the Arm SCMI Specification with additional vendor specific commands as > +detailed below. > + > +Commands: > +_________ > + > +PROTOCOL_VERSION > +~~~~~~~~~~~~~~~~ > + > +message_id: 0x0 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++---------------+--------------------------------------------------------------+ > +|Name |Description | > ++---------------+--------------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++---------------+--------------------------------------------------------------+ > +|uint32 version |For this revision of the specification, this value must be | > +| |0x10000. | > ++---------------+--------------------------------------------------------------+ > + > +PROTOCOL_ATTRIBUTES > +~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x1 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++------------------+-----------------------------------------------------------+ > +|uint32 attributes |Bits[31:16] Reserved, must be to 0. | > +| |Bits[15:8] Number of agents in the system | > +| |Bits[7:0] Number of vendor protocols in the system | > ++------------------+-----------------------------------------------------------+ > + > +PROTOCOL_MESSAGE_ATTRIBUTES > +~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +message_id: 0x2 > +protocol_id: 0x80 > + > ++---------------+--------------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |See ARM SCMI Specification for status code definitions. | > ++------------------+-----------------------------------------------------------+ > +|uint32 attributes |For all message id's the parameter has a value of 0. | > ++------------------+-----------------------------------------------------------+ > + > +QCOM_SCMI_SET_PARAM > +~~~~~~~~~~~~~~~~~~~ > I can understand the missing description for the above commands, but for the list below, no. What does QCOM_SCMI_SET_PARAM do exactly ? All I can understand is the syntax of the interface with below details. What is the algorithm string ? Is it fixed or choice of the caller ? If fixed, can we have that list here ? > +message_id: 0x10 > +protocol_id: 0x80 > + > ++------------------+-----------------------------------------------------------+ > +|Parameters | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|uint32 ext_id |Reserved, must be zero. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_low |Lower 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 algo_high |Upper 32-bit value of the algorithm string. | > ++------------------+-----------------------------------------------------------+ > +|uint32 param_id |Serves as the token message id for the algorithm string | > +| |and is used to set various parameters supported by it. | And how is it related to the algorithm string ? Sorry details please. Based on the quality firmware we have seen so far, I will be more pedantic, you need to be patient to make any progress and I don't want to deal with the Qcom firmware mess with all these. I will make you specify every single detail and the code will just be compliant with that. Anything else will be firmware bug that needs to be fixed in the firmware. Sorry, I don't see any other approach will make anyone's life easier here. > ++------------------+-----------------------------------------------------------+ > +|uint32 buf[] |Serves as the payload for the specified param_id and | > +| |algorithm string pair. | > ++------------------+-----------------------------------------------------------+ > +|Return values | > ++------------------+-----------------------------------------------------------+ > +|Name |Description | > ++------------------+-----------------------------------------------------------+ > +|int32 status |SUCCESS: if the param_id and buf[] is parsed successfully | > +| |by the chosen algorithm string. | > +| |NOT_SUPPORTED: if the algorithm string does not have any | > +| |matches. So there is a fixed list from the above statement IIUC. So kindly list them here in this document. I may need to follow the last version but I would prefer you to explicitly mention how is the MEMLAT protocol in the previous version gets used here ? I just can't understand that from these description. > + > +QCOM_SCMI_START_ACTIVITY > +~~~~~~~~~~~~~~~~~~~~~~~~ > What is this activity ? How will the firmware know what is that ? All possible details please if there are all hidden in the buffer too. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions 2024-11-15 1:15 [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar 2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar @ 2024-11-15 1:15 ` Sibi Sankar 2024-12-04 13:01 ` Cristian Marussi 2024-12-05 16:35 ` [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sudeep Holla 2 siblings, 1 reply; 10+ messages in thread From: Sibi Sankar @ 2024-11-15 1:15 UTC (permalink / raw) To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, quic_sibis, arm-scmi, Amir Vajid The QCOM SCMI Generic Extensions 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. Co-developed-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> 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> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> --- v4: * Splitting the series into vendor protocol and memlat client. Also the move the memlat client implementation back to RFC due to multiple opens. * Use common xfer helper to avoid code duplication [Dmitry] * Update enum documentation without duplicate enum info [Dmitry] drivers/firmware/arm_scmi/Kconfig | 1 + drivers/firmware/arm_scmi/Makefile | 1 + .../firmware/arm_scmi/vendors/qcom/Kconfig | 15 ++ .../firmware/arm_scmi/vendors/qcom/Makefile | 2 + .../arm_scmi/vendors/qcom/qcom-generic-ext.c | 139 ++++++++++++++++++ include/linux/scmi_qcom_protocol.h | 37 +++++ 6 files changed, 195 insertions(+) create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Kconfig create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Makefile create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c create mode 100644 include/linux/scmi_qcom_protocol.h diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig index dabd874641d0..73128442d97b 100644 --- a/drivers/firmware/arm_scmi/Kconfig +++ b/drivers/firmware/arm_scmi/Kconfig @@ -71,6 +71,7 @@ config ARM_SCMI_DEBUG_COUNTERS source "drivers/firmware/arm_scmi/transports/Kconfig" source "drivers/firmware/arm_scmi/vendors/imx/Kconfig" +source "drivers/firmware/arm_scmi/vendors/qcom/Kconfig" endif #ARM_SCMI_PROTOCOL diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile index 9ac81adff567..58cf4d656cbb 100644 --- a/drivers/firmware/arm_scmi/Makefile +++ b/drivers/firmware/arm_scmi/Makefile @@ -12,6 +12,7 @@ scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y) obj-$(CONFIG_ARM_SCMI_PROTOCOL) += transports/ obj-$(CONFIG_ARM_SCMI_PROTOCOL) += vendors/imx/ +obj-$(CONFIG_ARM_SCMI_PROTOCOL) += vendors/qcom/ obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-module.o diff --git a/drivers/firmware/arm_scmi/vendors/qcom/Kconfig b/drivers/firmware/arm_scmi/vendors/qcom/Kconfig new file mode 100644 index 000000000000..5dd9e8a6b75f --- /dev/null +++ b/drivers/firmware/arm_scmi/vendors/qcom/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0-only +menu "ARM SCMI QCOM Vendor Protocols" + +config QCOM_SCMI_GENERIC_EXT + tristate "Qualcomm Technologies, Inc. Qcom SCMI vendor Protocol" + depends on ARM_SCMI_PROTOCOL || COMPILE_TEST + help + 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. + + This driver defines/documents the message ID's used for this + communication and also exposes the operations used by the clients. +endmenu diff --git a/drivers/firmware/arm_scmi/vendors/qcom/Makefile b/drivers/firmware/arm_scmi/vendors/qcom/Makefile new file mode 100644 index 000000000000..6b98fabbebb8 --- /dev/null +++ b/drivers/firmware/arm_scmi/vendors/qcom/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_QCOM_SCMI_GENERIC_EXT) += qcom-generic-ext.o diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c new file mode 100644 index 000000000000..1b209093d275 --- /dev/null +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c @@ -0,0 +1,139 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#include <linux/scmi_qcom_protocol.h> + +#include "../../common.h" + +/** + * enum qcom_generic_ext_protocol_cmd - vendor specific commands supported by SCMI Qualcomm + * generic vendor protocol. + * + * This protocol is intended as a generic way of exposing a number of Qualcomm SoC + * specific features through a mixture of pre-determined algorithm string and param_id + * pairs hosted on the SCMI controller. + * + * The QCOM SCMI Vendor Protocol has the protocol id as 0x80 and vendor id set to + * Qualcomm and the implementation version set to 0x20000. The PROTOCOL_VERSION command + * returns version 1.0. + * + * @QCOM_SCMI_SET_PARAM: is used to set the parameter of a specific algo_str hosted on + * QCOM SCMI Vendor Protocol. The tx len depends on the algo_str used. + * @QCOM_SCMI_GET_PARAM: is used to get parameter information of a specific algo_str + * hosted on QCOM SCMI Vendor Protocol. The tx and rx len depends + * on the algo_str used. + * @QCOM_SCMI_START_ACTIVITY: is used to start the activity performed by the algo_str. + * @QCOM_SCMI_STOP_ACTIVITY: is used to stop a pre-existing activity performed by the algo_str. + */ +enum qcom_generic_ext_protocol_cmd { + QCOM_SCMI_SET_PARAM = 0x10, + QCOM_SCMI_GET_PARAM = 0x11, + QCOM_SCMI_START_ACTIVITY = 0x12, + QCOM_SCMI_STOP_ACTIVITY = 0x13, +}; + +/** + * struct qcom_scmi_msg - represents the various parameters to be populated + * for using the QCOM SCMI Vendor Protocol + * + * @ext_id: reserved, must be zero + * @algo_low: lower 32 bits of the algo_str + * @algo_high: upper 32 bits of the algo_str + * @param_id: serves as token message id to the specific algo_str + * @buf: serves as the payload to the specified param_id and algo_str pair + */ +struct qcom_scmi_msg { + __le32 ext_id; + __le32 algo_low; + __le32 algo_high; + __le32 param_id; + __le32 buf[]; +}; + +static int qcom_scmi_common_xfer(const struct scmi_protocol_handle *ph, + enum qcom_generic_ext_protocol_cmd cmd_id, void *buf, + size_t buf_len, u64 algo_str, u32 param_id, size_t rx_size) +{ + struct scmi_xfer *t; + struct qcom_scmi_msg *msg; + int ret; + + ret = ph->xops->xfer_get_init(ph, cmd_id, buf_len + sizeof(*msg), rx_size, &t); + if (ret) + return ret; + + msg = t->tx.buf; + msg->algo_low = cpu_to_le32(lower_32_bits(algo_str)); + msg->algo_high = cpu_to_le32(upper_32_bits(algo_str)); + msg->param_id = cpu_to_le32(param_id); + memcpy(msg->buf, buf, buf_len); + + ret = ph->xops->do_xfer(ph, t); + if (rx_size) + memcpy(buf, t->rx.buf, t->rx.len); + ph->xops->xfer_put(ph, t); + + return ret; +} + +static int qcom_scmi_set_param(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id) +{ + return qcom_scmi_common_xfer(ph, QCOM_SCMI_SET_PARAM, buf, buf_len, algo_str, + param_id, 0); +} + +static int qcom_scmi_get_param(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id, size_t rx_size) +{ + return qcom_scmi_common_xfer(ph, QCOM_SCMI_GET_PARAM, buf, buf_len, algo_str, + param_id, rx_size); +} + +static int qcom_scmi_start_activity(const struct scmi_protocol_handle *ph, void *buf, + size_t buf_len, u64 algo_str, u32 param_id) +{ + return qcom_scmi_common_xfer(ph, QCOM_SCMI_START_ACTIVITY, buf, buf_len, algo_str, + param_id, 0); +} + +static int qcom_scmi_stop_activity(const struct scmi_protocol_handle *ph, void *buf, + size_t buf_len, u64 algo_str, u32 param_id) +{ + return qcom_scmi_common_xfer(ph, QCOM_SCMI_STOP_ACTIVITY, buf, buf_len, algo_str, + param_id, 0); +} + +static struct qcom_generic_ext_ops qcom_proto_ops = { + .set_param = qcom_scmi_set_param, + .get_param = qcom_scmi_get_param, + .start_activity = qcom_scmi_start_activity, + .stop_activity = qcom_scmi_stop_activity, +}; + +static int qcom_generic_ext_protocol_init(const struct scmi_protocol_handle *ph) +{ + u32 version; + + ph->xops->version_get(ph, &version); + + dev_dbg(ph->dev, "QCOM Generic Vendor Version %d.%d\n", + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version)); + + return 0; +} + +static const struct scmi_protocol qcom_generic_ext = { + .id = SCMI_PROTOCOL_QCOM_GENERIC, + .owner = THIS_MODULE, + .instance_init = &qcom_generic_ext_protocol_init, + .ops = &qcom_proto_ops, + .vendor_id = "Qualcomm", + .impl_ver = 0x20000, +}; +module_scmi_protocol(qcom_generic_ext); + +MODULE_DESCRIPTION("QCOM SCMI Generic Vendor protocol"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/scmi_qcom_protocol.h b/include/linux/scmi_qcom_protocol.h new file mode 100644 index 000000000000..465b2522ca29 --- /dev/null +++ b/include/linux/scmi_qcom_protocol.h @@ -0,0 +1,37 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCMI Message Protocol driver QCOM extension header + * + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef _LINUX_SCMI_QCOM_PROTOCOL_H +#define _LINUX_SCMI_QCOM_PROTOCOL_H + +#include <linux/types.h> + +#define SCMI_PROTOCOL_QCOM_GENERIC 0x80 + +struct scmi_protocol_handle; + +/** + * struct qcom_generic_ext_ops - represents the various operations provided + * by QCOM Generic Vendor Protocol + * + * @set_param: set parameter specified by param_id and algo_str pair. + * @get_param: retrieve parameter specified by param_id and algo_str pair. + * @start_activity: initiate a specific activity defined by algo_str. + * @stop_activity: halt previously initiated activity defined by algo_str. + */ +struct qcom_generic_ext_ops { + int (*set_param)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id); + int (*get_param)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id, size_t rx_size); + int (*start_activity)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id); + int (*stop_activity)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, + u64 algo_str, u32 param_id); +}; + +#endif /* _LINUX_SCMI_QCOM_PROTOCOL_H */ -- 2.34.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions 2024-11-15 1:15 ` [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar @ 2024-12-04 13:01 ` Cristian Marussi 0 siblings, 0 replies; 10+ messages in thread From: Cristian Marussi @ 2024-12-04 13:01 UTC (permalink / raw) To: Sibi Sankar Cc: sudeep.holla, cristian.marussi, andersson, konrad.dybcio, linux-kernel, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi, Amir Vajid On Fri, Nov 15, 2024 at 06:45:15AM +0530, Sibi Sankar wrote: > The QCOM SCMI Generic Extensions 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. > Hi, > Co-developed-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> > 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> > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> You reworked/refactored quite a lot the internals since V4, you should have dropped the Reviewed-by tag. > --- > > v4: > * Splitting the series into vendor protocol and memlat client. > Also the move the memlat client implementation back to RFC > due to multiple opens. > * Use common xfer helper to avoid code duplication [Dmitry] > * Update enum documentation without duplicate enum info [Dmitry] > > drivers/firmware/arm_scmi/Kconfig | 1 + > drivers/firmware/arm_scmi/Makefile | 1 + > .../firmware/arm_scmi/vendors/qcom/Kconfig | 15 ++ > .../firmware/arm_scmi/vendors/qcom/Makefile | 2 + > .../arm_scmi/vendors/qcom/qcom-generic-ext.c | 139 ++++++++++++++++++ > include/linux/scmi_qcom_protocol.h | 37 +++++ > 6 files changed, 195 insertions(+) > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Kconfig > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/Makefile > create mode 100644 drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c > create mode 100644 include/linux/scmi_qcom_protocol.h > > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig > index dabd874641d0..73128442d97b 100644 > --- a/drivers/firmware/arm_scmi/Kconfig > +++ b/drivers/firmware/arm_scmi/Kconfig > @@ -71,6 +71,7 @@ config ARM_SCMI_DEBUG_COUNTERS > > source "drivers/firmware/arm_scmi/transports/Kconfig" > source "drivers/firmware/arm_scmi/vendors/imx/Kconfig" > +source "drivers/firmware/arm_scmi/vendors/qcom/Kconfig" > > endif #ARM_SCMI_PROTOCOL > > diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile > index 9ac81adff567..58cf4d656cbb 100644 > --- a/drivers/firmware/arm_scmi/Makefile > +++ b/drivers/firmware/arm_scmi/Makefile > @@ -12,6 +12,7 @@ scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y) > > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += transports/ > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += vendors/imx/ > +obj-$(CONFIG_ARM_SCMI_PROTOCOL) += vendors/qcom/ > > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-module.o > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/Kconfig b/drivers/firmware/arm_scmi/vendors/qcom/Kconfig > new file mode 100644 > index 000000000000..5dd9e8a6b75f > --- /dev/null > +++ b/drivers/firmware/arm_scmi/vendors/qcom/Kconfig > @@ -0,0 +1,15 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +menu "ARM SCMI QCOM Vendor Protocols" > + > +config QCOM_SCMI_GENERIC_EXT > + tristate "Qualcomm Technologies, Inc. Qcom SCMI vendor Protocol" > + depends on ARM_SCMI_PROTOCOL || COMPILE_TEST > + help > + 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. > + > + This driver defines/documents the message ID's used for this > + communication and also exposes the operations used by the clients. > +endmenu > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/Makefile b/drivers/firmware/arm_scmi/vendors/qcom/Makefile > new file mode 100644 > index 000000000000..6b98fabbebb8 > --- /dev/null > +++ b/drivers/firmware/arm_scmi/vendors/qcom/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +obj-$(CONFIG_QCOM_SCMI_GENERIC_EXT) += qcom-generic-ext.o > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c > new file mode 100644 > index 000000000000..1b209093d275 > --- /dev/null > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c > @@ -0,0 +1,139 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/scmi_qcom_protocol.h> > + > +#include "../../common.h" > + > +/** > + * enum qcom_generic_ext_protocol_cmd - vendor specific commands supported by SCMI Qualcomm > + * generic vendor protocol. > + * > + * This protocol is intended as a generic way of exposing a number of Qualcomm SoC > + * specific features through a mixture of pre-determined algorithm string and param_id > + * pairs hosted on the SCMI controller. > + * > + * The QCOM SCMI Vendor Protocol has the protocol id as 0x80 and vendor id set to > + * Qualcomm and the implementation version set to 0x20000. The PROTOCOL_VERSION command > + * returns version 1.0. The chosen protocol ID is already defined in the protocol doc in the series, and the note about the implementation version seems redundant, it is indeed specified as needed in scmi_protocol. > + * > + * @QCOM_SCMI_SET_PARAM: is used to set the parameter of a specific algo_str hosted on > + * QCOM SCMI Vendor Protocol. The tx len depends on the algo_str used. > + * @QCOM_SCMI_GET_PARAM: is used to get parameter information of a specific algo_str > + * hosted on QCOM SCMI Vendor Protocol. The tx and rx len depends > + * on the algo_str used. > + * @QCOM_SCMI_START_ACTIVITY: is used to start the activity performed by the algo_str. > + * @QCOM_SCMI_STOP_ACTIVITY: is used to stop a pre-existing activity performed by the algo_str. > + */ > +enum qcom_generic_ext_protocol_cmd { > + QCOM_SCMI_SET_PARAM = 0x10, > + QCOM_SCMI_GET_PARAM = 0x11, > + QCOM_SCMI_START_ACTIVITY = 0x12, > + QCOM_SCMI_STOP_ACTIVITY = 0x13, > +}; > + > +/** > + * struct qcom_scmi_msg - represents the various parameters to be populated > + * for using the QCOM SCMI Vendor Protocol > + * > + * @ext_id: reserved, must be zero > + * @algo_low: lower 32 bits of the algo_str > + * @algo_high: upper 32 bits of the algo_str > + * @param_id: serves as token message id to the specific algo_str > + * @buf: serves as the payload to the specified param_id and algo_str pair > + */ > +struct qcom_scmi_msg { > + __le32 ext_id; > + __le32 algo_low; > + __le32 algo_high; > + __le32 param_id; > + __le32 buf[]; > +}; > + > +static int qcom_scmi_common_xfer(const struct scmi_protocol_handle *ph, > + enum qcom_generic_ext_protocol_cmd cmd_id, void *buf, > + size_t buf_len, u64 algo_str, u32 param_id, size_t rx_size) > +{ > + struct scmi_xfer *t; > + struct qcom_scmi_msg *msg; > + int ret; > + > + ret = ph->xops->xfer_get_init(ph, cmd_id, buf_len + sizeof(*msg), rx_size, &t); > + if (ret) > + return ret; > + > + msg = t->tx.buf; > + msg->algo_low = cpu_to_le32(lower_32_bits(algo_str)); > + msg->algo_high = cpu_to_le32(upper_32_bits(algo_str)); > + msg->param_id = cpu_to_le32(param_id); > + memcpy(msg->buf, buf, buf_len); > + > + ret = ph->xops->do_xfer(ph, t); > + if (rx_size) You should check ret == 0 also here before considering to pick up the reply if a non-zero rx_size was specified. > + memcpy(buf, t->rx.buf, t->rx.len); ...you are using the same buf/buf_len to hold the TX request and get back the reply content if a non-zero rx_size was provided but while you can be sure that the reply payload rx.len <= rx_size by construction (via xfer_get_init) you cannot be equally sure that rx_size <= buf_len ...it depends on te caller how this operation is invoked...so you could end up oveflowing buf depending on the caller-provided params... ...please add some additional check at the start of this function like: if (rx_size > buf_len) return -EINVAL; ...to catch such bad invcations... > + ph->xops->xfer_put(ph, t); > + > + return ret; > +} > + > +static int qcom_scmi_set_param(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id) > +{ > + return qcom_scmi_common_xfer(ph, QCOM_SCMI_SET_PARAM, buf, buf_len, algo_str, > + param_id, 0); > +} > + > +static int qcom_scmi_get_param(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id, size_t rx_size) > +{ > + return qcom_scmi_common_xfer(ph, QCOM_SCMI_GET_PARAM, buf, buf_len, algo_str, > + param_id, rx_size); > +} > + > +static int qcom_scmi_start_activity(const struct scmi_protocol_handle *ph, void *buf, > + size_t buf_len, u64 algo_str, u32 param_id) > +{ > + return qcom_scmi_common_xfer(ph, QCOM_SCMI_START_ACTIVITY, buf, buf_len, algo_str, > + param_id, 0); > +} > + > +static int qcom_scmi_stop_activity(const struct scmi_protocol_handle *ph, void *buf, > + size_t buf_len, u64 algo_str, u32 param_id) > +{ > + return qcom_scmi_common_xfer(ph, QCOM_SCMI_STOP_ACTIVITY, buf, buf_len, algo_str, > + param_id, 0); > +} > + > +static struct qcom_generic_ext_ops qcom_proto_ops = { > + .set_param = qcom_scmi_set_param, > + .get_param = qcom_scmi_get_param, > + .start_activity = qcom_scmi_start_activity, > + .stop_activity = qcom_scmi_stop_activity, > +}; > + > +static int qcom_generic_ext_protocol_init(const struct scmi_protocol_handle *ph) > +{ > + u32 version; > + > + ph->xops->version_get(ph, &version); ... please check retval and bailout on error when not even a basic version_get succedeed... > + > + dev_dbg(ph->dev, "QCOM Generic Vendor Version %d.%d\n", > + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version)); > + > + return 0; > +} > + > +static const struct scmi_protocol qcom_generic_ext = { > + .id = SCMI_PROTOCOL_QCOM_GENERIC, > + .owner = THIS_MODULE, > + .instance_init = &qcom_generic_ext_protocol_init, > + .ops = &qcom_proto_ops, > + .vendor_id = "Qualcomm", > + .impl_ver = 0x20000, > +}; > +module_scmi_protocol(qcom_generic_ext); > + You may have to add a proper MODULE_ALIAS, if the series on autoload goes through https://lore.kernel.org/linux-arm-kernel/20241203200038.3961090-1-cristian.marussi@arm.com/ > +MODULE_DESCRIPTION("QCOM SCMI Generic Vendor protocol"); > +MODULE_LICENSE("GPL"); > diff --git a/include/linux/scmi_qcom_protocol.h b/include/linux/scmi_qcom_protocol.h > new file mode 100644 > index 000000000000..465b2522ca29 > --- /dev/null > +++ b/include/linux/scmi_qcom_protocol.h > @@ -0,0 +1,37 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SCMI Message Protocol driver QCOM extension header > + * > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#ifndef _LINUX_SCMI_QCOM_PROTOCOL_H > +#define _LINUX_SCMI_QCOM_PROTOCOL_H > + > +#include <linux/types.h> > + > +#define SCMI_PROTOCOL_QCOM_GENERIC 0x80 > + > +struct scmi_protocol_handle; > + > +/** > + * struct qcom_generic_ext_ops - represents the various operations provided > + * by QCOM Generic Vendor Protocol > + * > + * @set_param: set parameter specified by param_id and algo_str pair. > + * @get_param: retrieve parameter specified by param_id and algo_str pair. > + * @start_activity: initiate a specific activity defined by algo_str. > + * @stop_activity: halt previously initiated activity defined by algo_str. > + */ > +struct qcom_generic_ext_ops { > + int (*set_param)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id); > + int (*get_param)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id, size_t rx_size); > + int (*start_activity)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id); > + int (*stop_activity)(const struct scmi_protocol_handle *ph, void *buf, size_t buf_len, > + u64 algo_str, u32 param_id); > +}; > + > +#endif /* _LINUX_SCMI_QCOM_PROTOCOL_H */ > -- Thanks, Cristian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions 2024-11-15 1:15 [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar 2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar 2024-11-15 1:15 ` [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar @ 2024-12-05 16:35 ` Sudeep Holla 2 siblings, 0 replies; 10+ messages in thread From: Sudeep Holla @ 2024-12-05 16:35 UTC (permalink / raw) To: Sibi Sankar Cc: cristian.marussi, andersson, konrad.dybcio, linux-kernel, Sudeep Holla, linux-arm-msm, linux-arm-kernel, quic_rgottimu, quic_kshivnan, arm-scmi On Fri, Nov 15, 2024 at 06:45:13AM +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. > > Thanks in advance for taking time to review the series. > > V4: > * Splitting the series into vendor protocol and memlat client. > Also the move the memlat client implementation back to RFC > due to multiple opens. Sorry if I missed the rationale for the split here from the previous discussions, but I would like to see the DT bindings if any for all the users first before I can merge this. I am happy to get this series reviewed independently but my views might change looking at how it will be used as I might get better idea looking at the users. I really don't like the interface as well as the DT bindings that might be enforcing us to define. I have given my initial comments there. No need to respin it together immediately or even in future as along as there is a reference for me to look at. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-12-05 16:40 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-15 1:15 [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar 2024-11-15 1:15 ` [PATCH V5 1/2] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar 2024-12-04 11:48 ` Cristian Marussi 2024-12-05 11:07 ` Sibi Sankar 2024-12-05 11:37 ` Cristian Marussi 2024-12-05 15:32 ` Sudeep Holla 2024-12-05 15:53 ` Sudeep Holla 2024-11-15 1:15 ` [PATCH V5 2/2] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar 2024-12-04 13:01 ` Cristian Marussi 2024-12-05 16:35 ` [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sudeep Holla
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).