linux-dev/drivers/firmware/arm_scmi/common.h, branch linus/master

firmware: arm_scmi: Split protocol specific definitions in a dedicated header

2022-04-28T17:22:51Z

Move some SCMI protocol specific definitions from common.h into a the new dedicated protocols.h header so that SCMI protocols core code can include only what it needs; this is going to be useful to avoid the risk of growing indefinitely the dimension of common.h, especially when introducing some common protocols helper functions. Header common.h will continue to be included by SCMI core and transport layers. Link: https://lore.kernel.org/r/20220330150551.2573938-10-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Dynamically allocate implemented protocols array

2022-04-28T17:22:51Z

Move away from a statically allocated array for holding the current set of protocols implemented by the platform in favour of allocating it dynamically based on the number of protocols effectively advertised by the platform via BASE protocol exchanges. While at that, rectify the BASE_DISCOVER_LIST_PROTOCOLS loop iterations to terminate only when a number of protocols equal to the advertised ones has been received, instead of looping till the platform returns no more protocols descriptors. This new behaviour is better compliant with the specification and it has been tested to work equally well against an SCMI stack running on top of an official SCP firmware on a JUNO board. Link: https://lore.kernel.org/r/20220330150551.2573938-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add new parameter to mark_txdone

2021-12-21T10:59:38Z

Add a new xfer parameter to mark_txdone transport operation which enables the SCMI core to optionally pass back into the transport layer a reference to the xfer descriptor that is being handled. Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com Reviewed-by: Florian Fainelli Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add support for atomic transports

2021-12-21T10:59:37Z

An SCMI transport can be configured as .atomic_enabled in order to signal to the SCMI core that all its TX path is executed in atomic context and that, when requested, polling mode should be used while waiting for command responses. When a specific platform configuration had properly configured such a transport as .atomic_enabled, the SCMI core will also take care not to sleep in the corresponding RX path while waiting for a response if that specific command transaction was requested as atomic using polling mode. Asynchronous commands should not be used in an atomic context and so a warning is emitted if polling was requested for an asynchronous command. Add also a method to check, from the SCMI drivers, if the underlying SCMI transport is currently configured to support atomic transactions: this will be used by upper layers to determine if atomic requests can be supported at all on this SCMI instance. Link: https://lore.kernel.org/r/20211220195646.44498-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag

2021-12-21T10:59:26Z

Add a flag to let the transport signal to the core if its handling of sync command implies that, after .send_message has returned successfully, the requested command can be assumed to be fully and completely executed on SCMI platform side so that any possible response value is already immediately available to be retrieved by a .fetch_response: in other words the polling phase can be skipped in such a case and the response values accessed straight away. Note that all of the above applies only when polling mode of operation was selected by the core: if instead a completion IRQ was found to be available the normal response processing path based on completions will still be followed. Link: https://lore.kernel.org/r/20211220195646.44498-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add configurable polling mode for transports

2021-12-21T10:55:11Z

SCMI communications along TX channels can optionally be provided of a completion interrupt; when such interrupt is not available, command transactions should rely on polling, where the SCMI core takes care to repeatedly evaluate the transport-specific .poll_done() function, if available, to determine if and when a request was fully completed or timed out. Such mechanism is already present and working on a single transfer base: SCMI protocols can indeed enable hdr.poll_completion on specific commands ahead of each transfer and cause that transaction to be handled with polling. Introduce a couple of flags to be able to enforce such polling behaviour globally at will: - scmi_desc.force_polling: to statically switch the whole transport to polling mode. - scmi_chan_info.no_completion_irq: to switch a single channel dynamically to polling mode if, at runtime, is determined that no completion interrupt was available for such channel. Link: https://lore.kernel.org/r/20211220195646.44498-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add optee transport

2021-11-17T11:24:51Z

Add a new transport channel to the SCMI firmware interface driver for SCMI message exchange based on optee transport channel. The optee transport is realized by connecting and invoking OP-TEE SCMI service interface PTA. Optee transport support (CONFIG_ARM_SCMI_TRANSPORT_OPTEE) is default enabled when optee driver (CONFIG_OPTEE) is enabled. Effective optee transport is setup upon OP-TEE SCMI service discovery at optee device initialization. For this SCMI UUID is registered to the optee bus for probing. This is done from the link_supplier operator of the SCMI optee transport. The optee transport can use a statically defined shared memory in which case SCMI device tree node defines it using an "arm,scmi-shmem" compatible phandle through property shmem. Alternatively, optee transport allocates the shared memory buffer from the optee driver when no shmem property is defined. The protocol used to exchange SCMI message over that shared memory is negotiated between optee transport driver and the OP-TEE service through capabilities exchange. OP-TEE SCMI service is integrated in OP-TEE since its release tag 3.13.0. The service interface is published in [1]. Link: [1] https://github.com/OP-TEE/optee_os/blob/3.13.0/lib/libutee/include/pta_scmi_client.h Link: https://lore.kernel.org/r/20211028140009.23331-2-etienne.carriere@linaro.org Cc: Cristian Marussi Cc: Sudeep Holla Reviewed-by: Cristian Marussi Signed-off-by: Etienne Carriere Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add virtio transport

2021-08-05T09:24:08Z

This transport enables communications with an SCMI platform through virtio; the SCMI platform will be represented by a virtio device. Implement an SCMI virtio driver according to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. The virtio transport has one Tx channel (virtio cmdq, A2P channel) and at most one Rx channel (virtio eventq, P2A channel). The following feature bit defined in [1] is not implemented: VIRTIO_SCMI_F_SHARED_MEMORY. The number of messages which can be pending simultaneously is restricted according to the virtqueue capacity negotiated at probing time. As soon as Rx channel message buffers are allocated or have been read out by the arm-scmi driver, feed them back to the virtio device. Since some virtio devices may not have the short response time exhibited by SCMI platforms using other transports, set a generous response timeout. SCMI polling mode is not supported by this virtio transport since deemed meaningless: polling mode operation is offered by the SCMI core to those transports that could not provide a completion interrupt on the TX path, which is never the case for virtio whose core callbacks can easily call into core scmi_rx_callback upon messages reception. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" Cc: Jason Wang Co-developed-by: Peter Hilber Co-developed-by: Cristian Marussi Signed-off-by: Igor Skalkin [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add priv parameter to scmi_rx_callback

2021-08-05T09:23:23Z

Add a new opaque void *priv parameter to scmi_rx_callback which can be optionally provided by the transport layer when invoking scmi_rx_callback and that will be passed back to the transport layer in xfer->priv. This can be used by transports that needs to keep track of their specific data structures together with the valid xfers. Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add optional link_supplier() transport op

2021-08-05T09:23:23Z

Some transports are also effectively registered with other kernel subsystem in order to be properly probed and initialized; as a consequence such kind of transports, and their related devices, might still not have been probed and initialized at the time the main SCMI core driver is probed. Add an optional .link_supplier() transport operation which can be used by the core SCMI stack to dynamically check if the transport is ready and dynamically link its device to the SCMI platform instance device. Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com Signed-off-by: Peter Hilber [ Cristian: reworded commit message ] Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla