-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] SCMI PTA with OCALL #4535
Conversation
04af9c2
to
60a25fd
Compare
I think it would help the review if you could provide an overview of how this is supposed to work. It seems you're spawning a thread somewhere. What's the purpose with that thread, etc? |
Sorry, I was to push the Linux drivers but saw to many hoary things so spent time on fixing cleaning after creating this RFC. The more synthetic description I went to is the one in pta_scmi_client.h.
|
I'm sorry, I don't get it. Would it be possible to draw some diagram with plantuml for instance? |
okay, i'll prepare something. |
Thanks |
Adds a PTA interface to REE SCMI agents to get SCMI message communication channel for processing in OP-TEE SCMI server. Currently implement supports for a SCMI server built with CFG_SCMI_MSG_SMT=y. The implementation is made so that an alternate SCMI server implementation can added. Signed-off-by: Etienne Carriere <[email protected]>
Support posting message without buffer memref: Implement PTA_SCMI_CMD_PROCESS_SMT_MESSAGE where client provides the shared memory buffer reference with SCMI message notification instead of using a memory buffer statically assigned for the communication channel. Fix PTA_SCMI_CMD_GET_CHANNEL description inline comment. Signed-off-by: Etienne Carriere <[email protected]>
Enable SCMI PTA for REE to interface SCMI services in a threaded context. Signed-off-by: Etienne Carriere <[email protected]>
checkpatch suggests using the BIT macro instead of a left shift. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
Adds the ability for Core to perform "Out Calls", or OCALLs. OCALLs allow OP-TEE Core PTA services to invoke commands on their corresponding client in the same way that client can invoke commands on TAs. Adds a new capability that reports whether OP-TEE was built with OCALL support. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: split CFG_OCALL into CFG_{CORE|USER}_OCALL, no libutee, no pta] Signed-off-by: Etienne Carriere <[email protected]>
Using Ocall (CFG_CORE_OCALL=y), the SCMI agent and PTA can provision a secure thread for SCMI message passing/processing. The channel exchange protocol using OP-TEE Ocall is described in the PTA API header file pta_scmi_client.h. Signed-off-by: Etienne Carriere <[email protected]>
Enable CFG_CORE_OCALL to leverage Ocall suuport and provision a secure thread for SCMI message execution in a threaded context. Default to 3 threads since SCMI Linux driver will provision one for SCMI communication. Signed-off-by: Etienne Carriere <[email protected]>
Adds the ability for TAs to perform "Out Calls", or OCALLs. OCALLs allow TAs to invoke commands on their corresponding CA in the same way that CAs can invoke commands on TAs. Also, adds a new capability that reports whether OP-TEE was built with OCALL support. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: here the CFG_USER_OCALL part of the orginal patch] Signed-off-by: Etienne Carriere <[email protected]>
60a25fd
to
639182f
Compare
I've posted the Linux part in linaro-swg/linux#90. |
Thanks, very helpful. |
This P-R is based on #3673 (ocall) and #4533 (scmi pta). Or maybe should I abandon #4533 and consider only this P-R including the OCall part? |
To make a good review I need a proper proposal to review, that is something that will be merged once it's done. If a commit isn't final I don't think it makes sense to make a deep dive as things are going to change before it's merged However, I you want to include OCALL we need to finalize the kernel driver part of it first since that's the tricky part. I'm especially concerned about the shared memory part, I don't want to risk committing to an ABI that we in the end can't use. |
Let's start with the starter and first get SCMI PTA minimal features: #4533. |
Using Ocall (CFG_CORE_OCALL=y), the SCMI agent and PTA can provision a secure thread for SCMI message passing/processing. The channel exchange protocol using OP-TEE Ocall is described in the PTA API header file pta_scmi_client.h Note: this change was originally posted to OP-TEE through pull request OP-TEE#4535. Change-Id: I995192c660cd837fa7ccc025f5c95363e3b01937 Signed-off-by: Etienne Carriere <[email protected]> Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202484 Tested-by: Etienne CARRIERE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>
Using Ocall (CFG_CORE_OCALL=y), the SCMI agent and PTA can provision a secure thread for SCMI message passing/processing. The channel exchange protocol using OP-TEE Ocall is described in the PTA API header file pta_scmi_client.h Note: this change was originally posted to OP-TEE through pull request OP-TEE#4535. Change-Id: I995192c660cd837fa7ccc025f5c95363e3b01937 Signed-off-by: Etienne Carriere <[email protected]> Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202484 Tested-by: Etienne CARRIERE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>
This P-R is based on:
@HernanGatta, you see in this serie a commit leveraging OCALL to create a provisioned threaded entry in OP-TEE:
core: pta: scmi: ocall threaded context (54d0a2a).