#
9342829d |
| 23-Jan-2025 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Make transports report the effective length of the received messages
Once a message is received that fits into the RX buffer, update the msg.rx_len field with the effective length of the messa
scmi: Make transports report the effective length of the received messages
Once a message is received that fits into the RX buffer, update the msg.rx_len field with the effective length of the message received.
Tested on: Arm Morello Board Reviewed by: andrew Sponsored by: Arm Ltd Pull Request: https://reviews.freebsd.org/D47420 Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
show more ...
|
#
23f025e2 |
| 10-Jan-2025 |
Andrew Turner <andrew@FreeBSD.org> |
scmi: Fix the scmi_shmem module name
This fixes the "module scmi already present" message on boot.
Sponsored by: Arm Ltd
|
Revision tags: release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0 |
|
#
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
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
show more ...
|
#
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-flig
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
show more ...
|
#
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 meth
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
show more ...
|
#
a0ba2a97 |
| 07-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Protect SCMI/SMT channels from concurrent transmissions
The SCMI/SMT memory areas are used from the agent and the platform as channels to exchage commands and replies.
Once the platform has c
scmi: Protect SCMI/SMT channels from concurrent transmissions
The SCMI/SMT memory areas are used from the agent and the platform as channels to exchage commands and replies.
Once the platform has completed its processing and a reply is ready to be read from the agent, the platform will relinquish the channel to the agent by setting the CHANNEL_FREE bits in the related SMT area.
When this happens, though, the agent has still to effectively read back the reply message and any other concurrent request happened to have been issued in the meantime will have been to be hold back until the reply is processed or risk to be overwritten by the new request.
The base->mtx lock that currently guards the whole scmi_request() operation is released when sleeping waiting for a reply, so the above mentioned race can still happen or, in a slightly different scenario, the concurrent transmission could just fail, finding the channel busy, after having sneaked through the mutex.
Adding a new mechanism to let the agent explicitly acquire/release the channel paves the way, in the future, to remove such central commmon lock in favour of new dedicated per-transport locking mechanisms, since not all transports will necessarily need the same level of protection.
Add a flag, controlled by the agent, to mark when the channel has an inflight command transaction still pending to be completed and make the agent spin on it when queueing multiple concurrent messages on the same SMT channel.
Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43043
show more ...
|
#
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 mai
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
show more ...
|
#
d220b1cf |
| 06-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
scmi: Extend and refactor SCMI shmem support
Add a few new common public scmi_shmem methods to be used to handle SCMI shared memory areas from multiple transports; while doing that review the shared
scmi: Extend and refactor SCMI shmem support
Add a few new common public scmi_shmem methods to be used to handle SCMI shared memory areas from multiple transports; while doing that review the shared memory accesses to read only the SMT header fields strictly relevant to the SCMI message processing.
Move all the SCMI shmem related code to the existing scmi_shmem.c file and add a new dedicated scmi_shmem.h header.
Introduce some commonly needed message header manipulation macros.
Reviewed by: andrew Tested on: Arm Morello Board Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43041
show more ...
|
#
fdafd315 |
| 24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remov
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
show more ...
|
Revision tags: release/14.0.0 |
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
Revision tags: release/13.2.0 |
|
#
54b96380 |
| 19-Dec-2022 |
Ruslan Bukin <br@FreeBSD.org> |
Add support for ARM System Control and Management Interface (SCMI) v3.1.
The SCMI specification describes a set of standard interfaces for power, performance and system management.
SCMI is extensib
Add support for ARM System Control and Management Interface (SCMI) v3.1.
The SCMI specification describes a set of standard interfaces for power, performance and system management.
SCMI is extensible and provides interfaces to access functions which are often implemented in firmwares in the System Control Processor (SCP).
This implements Shared Memory-based transfer, which is one of the ways on how messages are exchanged between agents and the platform.
This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which is a mechanism that the caller can use to alert the callee of the presence of a message.
The support implements clock management interface. For instance this allows us to control HDMI pixel clock on ARM Morello Board.
Tested on ARM Morello Board.
Obtained from: CheriBSD Differential Revision: https://reviews.freebsd.org/D37316 Reviewed by: manu Sponsored by: UKRI
show more ...
|