Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-01 08:59:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/firmware/scmi/Kconfig

44 lines
1.5 KiB
Text
Raw Normal View History

firmware: add SCMI agent uclass This change introduces SCMI agent uclass to interact with a firmware using the SCMI protocols [1]. SCMI agent uclass currently supports a single method to request processing of the SCMI message by an identified server. A SCMI message is made of a byte payload associated to a protocol ID and a message ID, all defined by the SCMI specification [1]. On return from process_msg() method, the caller gets the service response. SCMI agent uclass defines a post bind generic sequence for all devices. The sequence binds all the SCMI protocols listed in the FDT for that SCMI agent device. Currently none, but later change will introduce protocols. This change implements a simple sandbox device for the SCMI agent uclass. The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. To prepare for further test support, the sandbox exposes a architecture function for test application to read the sandbox emulated devices state. Currently supports 2 SCMI agents, identified by an ID in the FDT device name. The simplistic DM test does nothing yet. SCMI agent uclass is designed for platforms that embed a SCMI server in a firmware hosted somewhere, for example in a companion co-processor or in the secure world of the executing processor. SCMI protocols allow an SCMI agent to discover and access external resources as clock, reset controllers and more. SCMI agent and server communicate following the SCMI specification [1]. This SCMI agent implementation complies with the DT bindings defined in the Linux kernel source tree regarding SCMI agent description since v5.8. Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-09 16:44:00 +00:00
config SCMI_FIRMWARE
bool "Enable SCMI support"
select FIRMWARE
select OF_TRANSLATE
firmware: scmi: Add OP-TEE transport This change implements an SCMI transport for agent interfacing the OP-TEE SCMI service. OP-TEE provides an SCMI PTA (Pseudo-TA) for non-secure world to send SCMI messages over an identified channel. The driver implemented here uses a SMT shared memory for passing messages between client and server. The implementation opens and releases channel resources for each passed SCMI message so that resources allocated (sessions) or registered (shared memory areas) in OP-TEE firmware are released for example before relocation as the driver will likely allocate/register them back when probed after relocation. The integration of the driver using dedicated config switch CONFIG_SCMI_AGENT_OPTEE is designed on the model posted to the U-Boot ML by Patrick Delaunay [1]. Link: [1] https://lore.kernel.org/all/20211028191222.v3.4.Ib2e58ee67f4d023823d8b5404332dc4d7e847277@changeid/ Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Wolfgang Denk <wd@denx.de> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-11-09 16:08:24 +00:00
depends on SANDBOX || DM_MAILBOX || ARM_SMCCC || OPTEE
firmware: add SCMI agent uclass This change introduces SCMI agent uclass to interact with a firmware using the SCMI protocols [1]. SCMI agent uclass currently supports a single method to request processing of the SCMI message by an identified server. A SCMI message is made of a byte payload associated to a protocol ID and a message ID, all defined by the SCMI specification [1]. On return from process_msg() method, the caller gets the service response. SCMI agent uclass defines a post bind generic sequence for all devices. The sequence binds all the SCMI protocols listed in the FDT for that SCMI agent device. Currently none, but later change will introduce protocols. This change implements a simple sandbox device for the SCMI agent uclass. The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. To prepare for further test support, the sandbox exposes a architecture function for test application to read the sandbox emulated devices state. Currently supports 2 SCMI agents, identified by an ID in the FDT device name. The simplistic DM test does nothing yet. SCMI agent uclass is designed for platforms that embed a SCMI server in a firmware hosted somewhere, for example in a companion co-processor or in the secure world of the executing processor. SCMI protocols allow an SCMI agent to discover and access external resources as clock, reset controllers and more. SCMI agent and server communicate following the SCMI specification [1]. This SCMI agent implementation complies with the DT bindings defined in the Linux kernel source tree regarding SCMI agent description since v5.8. Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-09 16:44:00 +00:00
help
System Control and Management Interface (SCMI) is a communication
protocol that defines standard interfaces for power, performance
and system management. The SCMI specification is available at
https://developer.arm.com/architectures/system-architectures/software-standards/scmi
An SCMI agent communicates with a related SCMI server firmware
located in another sub-system, as a companion micro controller
or a companion host in the CPU system.
Communications between agent (client) and the SCMI server are
firmware: scmi: Add OP-TEE transport This change implements an SCMI transport for agent interfacing the OP-TEE SCMI service. OP-TEE provides an SCMI PTA (Pseudo-TA) for non-secure world to send SCMI messages over an identified channel. The driver implemented here uses a SMT shared memory for passing messages between client and server. The implementation opens and releases channel resources for each passed SCMI message so that resources allocated (sessions) or registered (shared memory areas) in OP-TEE firmware are released for example before relocation as the driver will likely allocate/register them back when probed after relocation. The integration of the driver using dedicated config switch CONFIG_SCMI_AGENT_OPTEE is designed on the model posted to the U-Boot ML by Patrick Delaunay [1]. Link: [1] https://lore.kernel.org/all/20211028191222.v3.4.Ib2e58ee67f4d023823d8b5404332dc4d7e847277@changeid/ Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Wolfgang Denk <wd@denx.de> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-11-09 16:08:24 +00:00
based on message exchange. Messages can be exchanged over transport
firmware: scmi: support Arm SMCCC transport This change implements a SMCCC transport for SCMI exchanges. This implementation follows the Linux kernel as references implementation for SCMI message processing, using the SMT format for communication channel meta-data. Use of SMCCC transport in SCMI FDT bindings are defined in the Linux kernel DT bindings since v5.8. SMCCC with SMT is implemented in OP-TEE from tag 3.9.0 [2]. Links: [2] https://github.com/OP-TEE/optee_os/commit/a58c4d706d23 Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-09 16:44:02 +00:00
channels as a mailbox device or an Arm SMCCC service with some
piece of identified shared memory.
firmware: scmi: add configs to select the supported agents Add two configs CONFIG_SCMI_AGENT_MAILBOX and CONFIG_SCMI_AGENT_SMCCC to select the supported agents as all the agents are not supported. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
2021-10-28 17:13:15 +00:00
config SCMI_AGENT_MAILBOX
bool "Enable SCMI agent mailbox"
depends on SCMI_FIRMWARE && DM_MAILBOX
default y
help
Enable the SCMI communication channel based on mailbox
for compatible "arm,scmi".
config SCMI_AGENT_SMCCC
bool "Enable SCMI agent SMCCC"
depends on SCMI_FIRMWARE && ARM_SMCCC
default y
help
Enable the SCMI communication channel based on Arm SMCCC service for
compatible "arm,scmi-smc".
firmware: scmi: Add OP-TEE transport This change implements an SCMI transport for agent interfacing the OP-TEE SCMI service. OP-TEE provides an SCMI PTA (Pseudo-TA) for non-secure world to send SCMI messages over an identified channel. The driver implemented here uses a SMT shared memory for passing messages between client and server. The implementation opens and releases channel resources for each passed SCMI message so that resources allocated (sessions) or registered (shared memory areas) in OP-TEE firmware are released for example before relocation as the driver will likely allocate/register them back when probed after relocation. The integration of the driver using dedicated config switch CONFIG_SCMI_AGENT_OPTEE is designed on the model posted to the U-Boot ML by Patrick Delaunay [1]. Link: [1] https://lore.kernel.org/all/20211028191222.v3.4.Ib2e58ee67f4d023823d8b5404332dc4d7e847277@changeid/ Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Wolfgang Denk <wd@denx.de> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-11-09 16:08:24 +00:00
config SCMI_AGENT_OPTEE
bool "Enable SCMI agent OP-TEE"
depends on SCMI_FIRMWARE && OPTEE
default y
help
Enable the SCMI communication channel based on OP-TEE transport
for compatible "linaro,scmi-optee".
Reference in a new issue Copy permalink