| 3229e333 | 28-Oct-2024 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Calculate virtio PDU max size dynamically
SCMI virtio transport maximum PDU size is currently hardcoded at build
time; this will not play well with the possibile retrieval of a d
firmware: arm_scmi: Calculate virtio PDU max size dynamically
SCMI virtio transport maximum PDU size is currently hardcoded at build
time; this will not play well with the possibile retrieval of a different
size at run-time.
Make the virtio transport derive the maximum PDU size from the max_msg_size
provided by the SCMI core.
No functional change.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Message-Id: <20241028120151.1301177-3-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
| 5c14f388 | 28-Oct-2024 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Account for SHMEM memory overhead
Transports using shared memory have to consider the overhead due to the
layout area when determining the area effectively available for messages
firmware: arm_scmi: Account for SHMEM memory overhead
Transports using shared memory have to consider the overhead due to the
layout area when determining the area effectively available for messages.
Till now, such definitions were ambiguos across the SCMI stack and the
overhead layout area was not considered at all.
Add proper checks in the shmem layer to validate the provided max_msg_size
against the effectively available memory area, less the layout.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Message-Id: <20241028120151.1301177-2-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
| 2cd7f3db | 27-Aug-2024 |
Florian Fainelli <florian.fainelli@broadcom.com> |
firmware: arm_scmi: Support 'reg-io-width' property for shared memory
Some shared memory areas might only support a certain access width,
such as 32-bit, which memcpy_{from,to}_io() does not adhere
firmware: arm_scmi: Support 'reg-io-width' property for shared memory
Some shared memory areas might only support a certain access width,
such as 32-bit, which memcpy_{from,to}_io() does not adhere to at least
on ARM64 by making both 8-bit and 64-bit accesses to such memory.
Update the shmem layer to support reading from and writing to such
shared memory area using the specified I/O width in the Device Tree. The
various transport layers making use of the shmem.c code are updated
accordingly to pass the I/O accessors that they store.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Message-Id: <20240827182450.3608307-3-florian.fainelli@broadcom.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
| da1642bc | 14-Oct-2024 |
Justin Chen <justin.chen@broadcom.com> |
firmware: arm_scmi: Queue in scmi layer for mailbox implementation
send_message() does not block in the MBOX implementation. This is
because the mailbox layer has its own queue. However, this confus
firmware: arm_scmi: Queue in scmi layer for mailbox implementation
send_message() does not block in the MBOX implementation. This is
because the mailbox layer has its own queue. However, this confuses
the per xfer timeouts as they all start their timeout ticks in
parallel.
Consider a case where the xfer timeout is 30ms and a SCMI transaction
takes 25ms:
| 0ms: Message #0 is queued in mailbox layer and sent out, then sits
| at scmi_wait_for_message_response() with a timeout of 30ms
| 1ms: Message #1 is queued in mailbox layer but not sent out yet.
| Since send_message() doesn't block, it also sits at
| scmi_wait_for_message_response() with a timeout of 30ms
| ...
| 25ms: Message #0 is completed, txdone is called and message #1 is sent
| 31ms: Message #1 times out since the count started at 1ms. Even though
| it has only been inflight for 6ms.
Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Message-Id: <20241014160717.1678953-1-justin.chen@broadcom.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
| ccf50219 | 27-Aug-2024 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Replace the use of of_node_put() to __free(device_node)
Use __free for device_node values, and thus drop calls to of_node_put.
The goal is simplify of_node reference cleanup by
firmware: arm_scmi: Replace the use of of_node_put() to __free(device_node)
Use __free for device_node values, and thus drop calls to of_node_put.
The goal is simplify of_node reference cleanup by using this scope-based
of_node_put() cleanup to simplify function exit handling. When using __free
a resource is allocated within a block, it is automatically freed at the
end of the block.
This cleanup aligns well with the recent change in shmem.c to use __free
instead of explicit of_node_put() calls.
Message-Id: <20240827143838.1465913-3-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
| 668f0cb2 | 30-Jul-2024 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Remove const from transport descriptors
The descriptor structure scmi_desc contains a variety of fields related to
the transport functionalities and it is defined by the transpor
firmware: arm_scmi: Remove const from transport descriptors
The descriptor structure scmi_desc contains a variety of fields related to
the transport functionalities and it is defined by the transport drivers
themselves; such elements, though, serve varied purposes and have different
lifetime.
In particular, while there are some of those elements that provide a
description of transport features that are supposed to be immutable, on
the other side there are present also some other characteristics that are
instead supposed to be configurable on a per-platform base since they
represent configuration features tied to the specific hardware/firmware
system.
The immutable fields are already qualified as const on the their own; get
rid of the structure-level const qualifier which is not needed, so as to
enable possible runtime customization of the mutable configuration
features.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 19x19 EVK
Message-Id: <20240730144707.1647025-2-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|