| Age | Commit message (Collapse) | Author |
|---|
|
As exposed by "make randconfig", how we have SCMI_FIRMWARE today is
incomplete, and in one case, used incorrectly. First, SCMI_FIRMWARE has
a build-time dependency on OF_CONTROL being enabled, so add that.
Second, RESET_SCMI depends on SCMI_FIRMWARE being enabled, it should not
select that symbol. In turn, a number of platforms need to now enable
SCMI_FIRMWARE explicitly and not rely on RESET_SCMI to enable it for
them.
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Peng Fan <[email protected]>
Acked-by: Anshul Dalal <[email protected]>
Acked-by: Michal Simek <[email protected]> # Versal Gen 2
Reviewed-by: Patrice Chotard <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add Logical Machine Management(LMM) protocol which is intended for boot,
shutdown, and reset of other logical machines (LM). It is usually used to
allow one LM to manager another used as an offload or accelerator engine.
Following Linux Kernel, created a separate folder for holding vendor
protocol drivers.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Alice Guo <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Alice Guo <[email protected]>
|
|
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 <[email protected]>
Cc: Wolfgang Denk <[email protected]>
Signed-off-by: Etienne Carriere <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
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 <[email protected]>
Acked-by: Etienne Carriere <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Peng Fan <[email protected]>
Cc: Sudeep Holla <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This change implements a mailbox transport using SMT format for SCMI
exchanges. This implementation follows the Linux kernel and
SCP-firmware [1] as references implementation for SCMI message
processing using SMT format for communication channel meta-data.
Use of mailboxes in SCMI FDT bindings are defined in the Linux kernel
DT bindings since v4.17.
Links: [1] https://github.com/ARM-software/SCP-firmware
Signed-off-by: Etienne Carriere <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Peng Fan <[email protected]>
Cc: Sudeep Holla <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Peng Fan <[email protected]>
Cc: Sudeep Holla <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
