Preparing to add i.MX LMM and CPU protocol driver, support probe SCMI vendor ID 0x80(i.MX SCMI LMM ID) and 0x82(i.MX SCMI CPU ID). And use Kconfig option to support conditional compilation. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Alice Guo <alice.guo@nxp.com>
Add conditional compilation for SCMI protocol support in scmi_get_protocol() and scmi_add_protocol() based on corresponding Kconfig options. This ensures that only the enabled protocols are compiled and accessed, and reducing binary size. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Alice Guo <alice.guo@nxp.com>
This patch adds SCMI pin control protocol support to make the pin controller driver based on SCMI, such as drivers/pinctrl/nxp/pinctrl-imx-scmi.c, can be bound to the SCMI agent device whose protocol id is 0x19. Signed-off-by: Alice Guo <alice.guo@nxp.com>
U_BOOT_SCMI_PROTO_DRIVER macro is used to add a SCMI protocol driver to scmi_proto_driver list. scmi_proto_driver_get() function can be used to match a SCMI protocol id and its driver. Signed-off-by: Alice Guo <alice.guo@nxp.com>
Add power domain driver based on SCMI power domain management protocol. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
SCMI base protocol is mandatory, and once SCMI node is found in a device tree, the protocol handle (udevice) is unconditionally installed to the agent. Then basic information will be retrieved from SCMI server via the protocol and saved into the agent instance's local storage. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
This framework allows SCMI protocols to be installed and bound to the agent so that the agent can manage and utilize them later. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
SCMI specification allows any protocol to have its own channel for the transport. While the current SCMI driver may assign its channel from a device tree, the core function, devm_scmi_process_msg(), doesn't use a protocol's channel, but always use an agent's channel. With this commit, devm_scmi_process_msg() tries to find and use a protocol's channel. If it doesn't exist, use an agent's. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Changes SCMI transport operator ::process_msg to pass the SCMI channel reference provided by caller SCMI protocol device. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>