u-boot/drivers/firmware/scmi/scmi_agent-uclass.c

172 lines
3.9 KiB
C
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
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2020 Linaro Limited.
*/
#define LOG_CATEGORY UCLASS_SCMI_AGENT
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
#include <common.h>
#include <dm.h>
#include <errno.h>
#include <scmi_agent-uclass.h>
#include <scmi_protocols.h>
#include <dm/device_compat.h>
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
#include <dm/device-internal.h>
#include <linux/compat.h>
/**
* struct error_code - Helper structure for SCMI error code conversion
* @scmi: SCMI error code
* @errno: Related standard error number
*/
struct error_code {
int scmi;
int errno;
};
static const struct error_code scmi_linux_errmap[] = {
{ .scmi = SCMI_NOT_SUPPORTED, .errno = -EOPNOTSUPP, },
{ .scmi = SCMI_INVALID_PARAMETERS, .errno = -EINVAL, },
{ .scmi = SCMI_DENIED, .errno = -EACCES, },
{ .scmi = SCMI_NOT_FOUND, .errno = -ENOENT, },
{ .scmi = SCMI_OUT_OF_RANGE, .errno = -ERANGE, },
{ .scmi = SCMI_BUSY, .errno = -EBUSY, },
{ .scmi = SCMI_COMMS_ERROR, .errno = -ECOMM, },
{ .scmi = SCMI_GENERIC_ERROR, .errno = -EIO, },
{ .scmi = SCMI_HARDWARE_ERROR, .errno = -EREMOTEIO, },
{ .scmi = SCMI_PROTOCOL_ERROR, .errno = -EPROTO, },
};
int scmi_to_linux_errno(s32 scmi_code)
{
int n;
if (!scmi_code)
return 0;
for (n = 0; n < ARRAY_SIZE(scmi_linux_errmap); n++)
if (scmi_code == scmi_linux_errmap[n].scmi)
return scmi_linux_errmap[1].errno;
return -EPROTO;
}
/*
* SCMI agent devices binds devices of various uclasses depeding on
* the FDT description. scmi_bind_protocol() is a generic bind sequence
* called by the uclass at bind stage, that is uclass post_bind.
*/
static int scmi_bind_protocols(struct udevice *dev)
{
int ret = 0;
ofnode node;
firmware: scmi: use protocol node name to bind the scmi regulator driver In scmi firmware driver, it is better to bind the scmi protocol driver "scmi_voltage_domain" with the node name of the protocol 17 and not the sub-node named "regulator", because is a fixed string which doesn't provide information and because it is not aligned with the other scmi protocol nodes. For example on stm32mp135f-dk board with device tree in stm32mp131.dtsi scmi: scmi { compatible = "linaro,scmi-optee"; #address-cells = <1>; #size-cells = <0>; linaro,optee-channel-id = <0>; shmem = <&scmi_shm>; scmi_clk: protocol@14 { reg = <0x14>; #clock-cells = <1>; }; scmi_reset: protocol@16 { reg = <0x16>; #reset-cells = <1>; }; scmi_voltd: protocol@17 { reg = <0x17>; scmi_regu: regulators { #address-cells = <1>; #size-cells = <0>; scmi_reg11: voltd-reg11 { reg = <VOLTD_SCMI_REG11>; regulator-name = "reg11"; }; scmi_reg18: voltd-reg18 { reg = <VOLTD_SCMI_REG18>; regulator-name = "reg18"; }; scmi_usb33: voltd-usb33 { reg = <VOLTD_SCMI_USB33>; regulator-name = "usb33"; }; }; }; }; Before the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- regulators regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... after the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- protocol@17 regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2022-11-25 11:56:29 +00:00
const char *name;
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
dev_for_each_subnode(node, dev) {
struct driver *drv = NULL;
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
u32 protocol_id;
if (!ofnode_is_enabled(node))
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
continue;
if (ofnode_read_u32(node, "reg", &protocol_id))
continue;
firmware: scmi: use protocol node name to bind the scmi regulator driver In scmi firmware driver, it is better to bind the scmi protocol driver "scmi_voltage_domain" with the node name of the protocol 17 and not the sub-node named "regulator", because is a fixed string which doesn't provide information and because it is not aligned with the other scmi protocol nodes. For example on stm32mp135f-dk board with device tree in stm32mp131.dtsi scmi: scmi { compatible = "linaro,scmi-optee"; #address-cells = <1>; #size-cells = <0>; linaro,optee-channel-id = <0>; shmem = <&scmi_shm>; scmi_clk: protocol@14 { reg = <0x14>; #clock-cells = <1>; }; scmi_reset: protocol@16 { reg = <0x16>; #reset-cells = <1>; }; scmi_voltd: protocol@17 { reg = <0x17>; scmi_regu: regulators { #address-cells = <1>; #size-cells = <0>; scmi_reg11: voltd-reg11 { reg = <VOLTD_SCMI_REG11>; regulator-name = "reg11"; }; scmi_reg18: voltd-reg18 { reg = <VOLTD_SCMI_REG18>; regulator-name = "reg18"; }; scmi_usb33: voltd-usb33 { reg = <VOLTD_SCMI_USB33>; regulator-name = "usb33"; }; }; }; }; Before the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- regulators regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... after the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- protocol@17 regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2022-11-25 11:56:29 +00:00
name = ofnode_get_name(node);
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
switch (protocol_id) {
case SCMI_PROTOCOL_ID_CLOCK:
if (IS_ENABLED(CONFIG_CLK_SCMI))
drv = DM_DRIVER_GET(scmi_clock);
break;
case SCMI_PROTOCOL_ID_RESET_DOMAIN:
if (IS_ENABLED(CONFIG_RESET_SCMI))
drv = DM_DRIVER_GET(scmi_reset_domain);
break;
case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI)) {
node = ofnode_find_subnode(node, "regulators");
if (!ofnode_valid(node)) {
dev_err(dev, "no regulators node\n");
return -ENXIO;
}
drv = DM_DRIVER_GET(scmi_voltage_domain);
}
break;
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
default:
break;
}
if (!drv) {
dev_dbg(dev, "Ignore unsupported SCMI protocol %#x\n",
protocol_id);
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
continue;
}
firmware: scmi: use protocol node name to bind the scmi regulator driver In scmi firmware driver, it is better to bind the scmi protocol driver "scmi_voltage_domain" with the node name of the protocol 17 and not the sub-node named "regulator", because is a fixed string which doesn't provide information and because it is not aligned with the other scmi protocol nodes. For example on stm32mp135f-dk board with device tree in stm32mp131.dtsi scmi: scmi { compatible = "linaro,scmi-optee"; #address-cells = <1>; #size-cells = <0>; linaro,optee-channel-id = <0>; shmem = <&scmi_shm>; scmi_clk: protocol@14 { reg = <0x14>; #clock-cells = <1>; }; scmi_reset: protocol@16 { reg = <0x16>; #reset-cells = <1>; }; scmi_voltd: protocol@17 { reg = <0x17>; scmi_regu: regulators { #address-cells = <1>; #size-cells = <0>; scmi_reg11: voltd-reg11 { reg = <VOLTD_SCMI_REG11>; regulator-name = "reg11"; }; scmi_reg18: voltd-reg18 { reg = <VOLTD_SCMI_REG18>; regulator-name = "reg18"; }; scmi_usb33: voltd-usb33 { reg = <VOLTD_SCMI_USB33>; regulator-name = "usb33"; }; }; }; }; Before the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- regulators regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... after the patch: > dm tree scmi_agent 0 [ + ] scmi-over-optee |-- scmi clk 1 [ + ] scmi_clk | |-- protocol@14 ... reset 1 [ ] scmi_reset_domain | |-- protocol@16 nop 2 [ + ] scmi_voltage_domain | `-- protocol@17 regulator 0 [ + ] scmi_regulator | |-- voltd-reg11 regulator 1 [ + ] scmi_regulator | |-- voltd-reg18 regulator 2 [ + ] scmi_regulator | |-- voltd-usb33 ... Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2022-11-25 11:56:29 +00:00
ret = device_bind(dev, drv, name, NULL, node, NULL);
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
if (ret)
break;
}
return ret;
}
static struct udevice *find_scmi_transport_device(struct udevice *dev)
{
struct udevice *parent = dev;
do {
parent = dev_get_parent(parent);
} while (parent && device_get_uclass_id(parent) != UCLASS_SCMI_AGENT);
if (!parent)
dev_err(dev, "Invalid SCMI device, agent not found\n");
return parent;
}
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
static const struct scmi_agent_ops *transport_dev_ops(struct udevice *dev)
{
return (const struct scmi_agent_ops *)dev->driver->ops;
}
int devm_scmi_of_get_channel(struct udevice *dev, struct scmi_channel **channel)
{
struct udevice *parent;
parent = find_scmi_transport_device(dev);
if (!parent)
return -ENODEV;
if (transport_dev_ops(parent)->of_get_channel)
return transport_dev_ops(parent)->of_get_channel(parent, channel);
/* Drivers without a get_channel operator don't need a channel ref */
*channel = NULL;
return 0;
}
int devm_scmi_process_msg(struct udevice *dev, struct scmi_channel *channel,
struct scmi_msg *msg)
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
{
const struct scmi_agent_ops *ops;
struct udevice *parent;
parent = find_scmi_transport_device(dev);
if (!parent)
return -ENODEV;
ops = transport_dev_ops(parent);
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
if (ops->process_msg)
return ops->process_msg(parent, channel, msg);
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
return -EPROTONOSUPPORT;
}
UCLASS_DRIVER(scmi_agent) = {
.id = UCLASS_SCMI_AGENT,
.name = "scmi_agent",
.post_bind = scmi_bind_protocols,
};