On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
>
>
> From: Andrei Cherechesu <[email protected]>
>
> Introduce the SCMI-SMC layer to have some basic degree of
> awareness about SCMI calls that are based on the ARM System
> Control and Management Interface (SCMI) specification (DEN0056E).
>
> The SCMI specification includes various protocols for managing
> system-level resources, such as: clocks, pins, reset, system power,
> power domains, performance domains, etc. The clients are named
> "SCMI agents" and the server is named "SCMI platform".
>
> Only support the shared-memory based transport with SMCs as
> the doorbell mechanism for notifying the platform. Also, this
> implementation only handles the "arm,scmi-smc" compatible,
> requiring the following properties:
> - "arm,smc-id" (unique SMC ID)
> - "shmem" (one or more phandles pointing to shmem zones
> for each channel)
>
> The initialization is done as initcall, since we need
> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
> If no "arm,scmi-smc" compatible node is found in the host
> DT, the initialization fails silently, as it's not mandatory.
> Otherwise, we get the 'arm,smc-id' DT property from the node,
> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
> are not validated, as the SMC calls are only passed through
> to EL3 FW if coming from the hardware domain.
>
> Create a new 'firmware' folder to keep the SCMI code separate
> from the generic ARM code.
>
> Signed-off-by: Andrei Cherechesu <[email protected]>
> Reviewed-by: Stefano Stabellini <[email protected]>
NIT for the future. If there are changes in-between the revisions, in general
you should
drop the Rb/Ab tags. Here you incorporated my feedback, so:
Acked-by: Michal Orzel <[email protected]>
The series is ready to go in. I'll commit it today or tomorrow as I'm waiting
for
staging to become "green" again. Thanks.
~Michal
