#
35f93203 |
|
11-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Introduce a new SCMI API and port CLK SCMI driver to it Expose new scmi_buf_get/put API methods to build and send messages; command request descriptors are now pre-allocated when the SCMI core is initialized and kept in a free list, instead of being allocated on the stack of the caller of the SCMI request. Dynamically allocated descriptors enable the SCMI core to keep around and track outstanding transactions for as long as needed, outliving the lifetime of the caller stack: this allows tracking of late or missing replies and it will be needed when adding support for SCMI transports that allows for more messages to be inflight concurrently. Move the existing CLK SCMI driver to the new API. Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43046
|
#
3595f18f |
|
07-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Add SCMI message tracking and centralize tx/rx logic In order to be able to support also new, more parallel, SCMI transports that by nature can allow multiple concurrent commands to be in-flight, pending a reply, we must be able to use the sequence number provided in the SCMI messages to track the message status, matching commands and replies while keeping track of timeouts and duplicates. Add the needed message tracking machinery in the core SCMI stack and move the residual common tx/rx logic from the specific transports to the core SCMI stack, while adding one more interface to let the transports customize ther behaviour. Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43045
|
#
403ca28c |
|
07-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Add new SCMI interfaces for init and message processing Introduce a couple of new SCMI interface methods to allow centralized initialization of transport-specific features and a couple of methods to handle message reception from the SCMI core. Move SCMI SMT related calls out of the core common SCMI code into the transport specific layers Mailbox/SMC. Make SCMI Mailbox/SMC transports use the new interface methods for initialization and message reception. Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43044
|
#
cbcfdff0 |
|
07-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Fix SCMI mailbox polling mechanism When the system is cold, the SCMI stack processes commands in polling mode with the current polling mechanism being a check of the status register in the mailbox controller to see if there is any pending doorbell request. Anyway, the completion interrupt is optional by the SCMI specification and a system could have been simply designed without it: for this reason polling on the mailbox controller status registers is not going to work in all situations. Moreover even alternative SCMI transports based on shared memory, like SMC, will not have at all a mailbox controller to poll for. On the other side, the associated SCMI Shared Memory Transport defines dedicated channel flags and status bits that can be used by the agent to explicitly request a polling-based transaction, even if the completion interrupt was available, and to check afterwards when the platform has completed its processing on the outstanding command. Use SCMI/SMT specific mechanism to process transactions in polling mode. Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43042
|
#
d46f01fd |
|
04-Oct-2023 |
Andrew Turner <andrew@FreeBSD.org> |
scmi: Split out the SCMI mailbox to a new file Add a new SCMI interface file to allow for multiple kind of transports and move the mailbox transport to its own file, using the new interface. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43039
|