Hi,
Yes, it could be an option to have/add power mgmt as part of the SCMI interface. However, I see that a use-case when the consumer is on a separate PE from TF-M, so the communication channel is already done via a payload (mailbox for example). Otherwise, if only local clients (same PE) are in need of power controls, then we're probably better off with a direct psa_call, so we avoid the overhead of payload + SCMI despatching. Either way we still need a driver to perform the actual power change. If we implement the interfaces nicely, SCMI partition "could" in the future use the interface into the platform_sp ( or whatever power-SP) to perform the required power changes.

Or at least, that's the way I see it.

@Brian, would you be able to provide a basic example of your use case for this need of NSPE to change some power settings?

Thanks in advnace
Hope it help
Nicola

From: Chris.Brand--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 14 February 2025 16:19
To: Nicola Mazzucato <Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; brian@ti.com <brian@ti.com>
Subject: [TF-M] Re: Adding Platform power control
 

I guess that could fit under the “power domain management” functionality of the SCMI interface (“the ability to place a given device or domain into the various power-saving states that it supports”). There’s a minimalist implementation of the SCMI partition (without power domain management functionality) at https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/+/refs/heads/main/docs/partitions/scmi_comms.rst

 

Chris

 

From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 14, 2025 12:57 AM
To: tf-m@lists.trustedfirmware.org; Quach, Brian <brian@ti.com>
Subject: [TF-M] Re: Adding Platform power control

 

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

 

Hi Brian,

 

If the peripherals can only be accessed by the secure world, then my suggestion would be to include the power controls as part of a partition.

 

An example could be the platform_sp, where once the client call type has been found, the action taken is implemented in the platform code, via a defined HAL.

That way the partition could be fairly generic and each platform can implement - or not - the required functionalities.

Then the build follows the same flow as the platform partition and the corresponding implementation.

 

Hope it helps,

Thanks

Nicola

 

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 13 February 2025 22:56
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Adding Platform power control

 

Hi,

 

I’m trying to add platform power control functions (to power off/on peripherials) to the SPM.  Are there any examples of this?  What is the cleanest way to implement?  Can it be done via adding code to source/third_party/tfm/platform/ext/target/<vendor>/ and compiling into the platform_s target?

 

Figure 3 from DEN0063 shows the connection between SPM and PRoT partitions is IMPLEMENTATION DEFINED.  How does the TF-M implement PRoT partitions to call the SPM?  Can it be a direct API call?  I did see platform_svc_handlers() but I assume that was for use by ARoT partitions (unpriviledged).

 

DEN0063 PSA Firmware Framework:

Some platforms include functionality that can only be accessed by firmware at the highest privilege level. For example, platform power control or control registers that are shared by secure and non-secure firmware. These Platform services must be implemented as part of the SPM, but the mechanism by which the NSPE firmware accesses these services is IMPLEMENTATION DEFINED.

 

Regards,

 

Brian Quach

SimpleLink MCU

Texas Instruments Inc.