aboutsummaryrefslogtreecommitdiff
path: root/include/scmi_agent.h
AgeCommit message (Collapse)Author
2022-06-23firmware: scmi: add multi-channel supportEtienne Carriere
Adds resources for SCMI protocols to possibly use a dedicated SCMI channel instead of the default channel allocated by the SCMI agent during initialization. As per DT binding documentation, some SCMI transports can define a specific SCMI communication channel for given SCMI protocols. It allows SCMI protocols to pass messages concurrently each other. This change introduces new scmi agent uclass API function devm_scmi_of_get_channel() for SCMI drivers probe sequences to get a reference to the SCMI channel assigned to its related SCMI protocol. The function queries the channel reference to its SCMI transport driver through new scmi agent uclass operator .of_get_channel that uses Device Tree information from related SCMI agent node. Operator .of_get_channel returns a reference to the SCMI channel assigned to SCMI protocol used by the caller device. SCMI transport drivers that do not support multi-channel are not mandated to register this operator. When so, API function devm_scmi_of_get_channel() returns NULL and SCMI transport driver are expected to retrieve by their own means the reference to the unique SCMI channel, for example using platform data as these drivers currently do in U-Boot source tree. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-06-23firmware: scmi: prepare scmi uclass API to multi-channelEtienne Carriere
Changes SCMI driver API function devm_scmi_process_msg() to add an SCMI channel reference argument for when SCMI agent supports SCMI protocol specific channels. First argument of devm_scmi_process_msg() is also change to point to the caller SCMI protocol device rather than its parent device (the SCMI agent device). The argument is a pointer to opaque struct scmi_channel known from the SCMI transport drivers. It is currently unused and caller a pass NULL value. A later change will enable such support once SCMI protocol drivers have means to get the channel reference during initialization. Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-03-02scmi: change parameter dev in devm_scmi_process_msgEtienne Carriere
Changes devm_scmi_process_msg() first argument from target parent device to current SCMI device and lookup the SCMI agent device among SCMI device parents for find the SCMI agent operator needed for communication with the firmware. This change is needed in order to support CCF in clk_scmi driver unless what CCF will fail to find the right udevice related to exposed SCMI clocks. This patch allows to simplify the caller sequence, using SCMI device reference as parameter instead of knowing SCMI uclass topology. This change also adds some protection in case devm_scmi_process_msg() API function is called for an invalid device type. Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-01-19doc: replace @return by Return:Heinrich Schuchardt
Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-11-23firmware: scmi: fix description of an API functionEtienne Carriere
Correct inline comment describing API function devm_scmi_process_msg(). Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2020-09-30firmware: add SCMI agent uclassEtienne Carriere
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>