Ken,

Our use case is to support a “secure driver”:

1) A peripheral can only be accessed in secure mode.

2) The peripheral is configured and a hardware process is triggered within the peripheral.

3) When the process completes, a secure interrupt is triggered.

4) The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished.

Alan

From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M
Sent: Thursday, March 5, 2020 10:28 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd
Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE

Hi Alan,

It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable?

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Wednesday, March 4, 2020 10:51 PM
To: 'tf-m@lists.trustedfirmware.org' <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] SPM_IDLE

Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document:

https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBuild/artifact/build-docs/tf-m_documents/install/doc/user_guide/html/docs/design_documents/tfm_cooperative_scheduling_rules.html

I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called.

Alan