#
af78e5c3 |
|
20-Sep-2023 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Move power-domain driver to the pmdomain dir To simplify with maintenance let's move the Arm SCMI power-domain driver to the new pmdomain directory. Link: https://lore.kernel.org/all/20230921113328.3208651-1-sudeep.holla@arm.com Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3c3d818a |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add core raw transmission support Add SCMI raw mode support which exposes a userspace interface to allow for bare SCMI command injection and snooping from userspace. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-13-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
37b5be82 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Split bus and driver into distinct modules Make the SCMI bus on its own as a distinct module initialized at subsys_initcall level when builtin. Keep the SCMI driver core stack, together with any configured transport, in a different module initialized as module_init level. SCMI drivers initialization remain unchanged at module_init level. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-10-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
0316f99c |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add SCMI v3.1 powercap protocol basic support Add support for SCMI v3.1 powercap protocol, with the exception of powercap fast channels, exposing all the new related powercap protocol operations as usual in include/linux/scmi_protocol.h. Link: https://lore.kernel.org/r/20220704102241.2988447-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2c4b97fe |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add SCMI System Power Control driver Add an SCMI System Power control driver to handle platform's requests carried by SYSTEM_POWER_STATE_NOTIFIER notifications: such platform requested system-wide power state transitions are handled accordingly, gracefully or forcefully, depending on the notifications' message flags. Graceful requests are relayed to userspace using the same Kernel API used to handle ACPI Shutdown bus events. Link: https://lore.kernel.org/r/20220704101933.2981635-5-cristian.marussi@arm.com Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
cdf157fa |
|
03-Feb-2022 |
Ard Biesheuvel <ardb@kernel.org> |
firmware: arm_scmi: Disable ftrace for Clang Thumb2 builds The SMC calling convention designates R0-R7 as input registers in AArch32 mode, and this conflicts with the compiler's use of R7 as a frame pointer when building in Thumb2 mode. Generally, we don't enable the frame pointer, and GCC happily enables the -pg profiling hooks without them. However, Clang refuses, and errors out with the message below: drivers/firmware/arm_scmi/smc.c:152:2: error: write to reserved register 'R7' arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res); ^ include/linux/arm-smccc.h:550:4: note: expanded from macro 'arm_smccc_1_1_invoke' arm_smccc_1_1_smc(__VA_ARGS__); \ ^ Let's just disable ftrace for the compilation unit when building this configuration. Link: https://lore.kernel.org/r/20220203082204.1176734-11-ardb@kernel.org Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5f90f189 |
|
28-Oct-2021 |
Etienne Carriere <etienne.carriere@linaro.org> |
firmware: arm_scmi: Add optee transport 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 <cristian.marussi@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
46abe13b |
|
03-Aug-2021 |
Igor Skalkin <igor.skalkin@opensynergy.com> |
firmware: arm_scmi: Add virtio transport 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" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f301bba0 |
|
03-Aug-2021 |
Peter Hilber <peter.hilber@opensynergy.com> |
firmware: arm_scmi: Add message passing abstractions for transports Add abstractions for future transports using message passing, such as virtio. Derive the abstractions from the shared memory abstractions. Abstract the transport SDU through the opaque struct scmi_msg_payld. Also enable the transport to determine all other required information about the transport SDU. Link: https://lore.kernel.org/r/20210803131024.40280-12-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted to new SCMI Kconfig layout, updated Copyrights ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a7b1138b |
|
03-Aug-2021 |
Igor Skalkin <igor.skalkin@opensynergy.com> |
firmware: arm_scmi: Make shmem support optional for transports Upcoming new SCMI transports won't need any kind of shared memory support. Compile shmem.c only if a shmem based transport is selected. Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e8419c24 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make SCMI transports configurable Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack. Mailbox and SMC are by default enabled if their related dependencies are satisfied. While doing that move all SCMI related config options in their own dedicated submenu. Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2add5cac |
|
19-Nov-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add voltage domain management protocol support SCMI v3.0 introduces voltage domain protocol which provides commands to: - Discover the voltage levels supported by a domain - Get the configuration and voltage level of a domain - Set the configuration and voltage level of a domain Let us add support for the same. Link: https://lore.kernel.org/r/20201119191051.46363-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
66d90f6e |
|
06-Sep-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Enable building as a single module Now, with all the plumbing in place to enable building scmi as a module instead of built-in modules, let us enable the same. Link: https://lore.kernel.org/r/20200907195046.56615-5-sudeep.holla@arm.com Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a8803055 |
|
07-Sep-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add system power protocol support Add bare protocol support for SCMI system power protocol as needed by an OSPM agent: basic initialization and SYSTEM_POWER_STATE_NOTIFIER core notification support. No event-handling logic is attached to such notification.. Link: https://lore.kernel.org/r/20200907174657.32466-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1fc2dd18 |
|
01-Jul-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add notification protocol-registration Add the core SCMI notifications protocol-registration support: allow protocols to register their own set of supported events, during their initialization phase. Notification core can track multiple platform instances by their handles. Link: https://lore.kernel.org/r/20200701155348.52864-2-cristian.marussi@arm.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d7642823 |
|
25-Jun-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Use HAVE_ARM_SMCCC_DISCOVERY instead of ARM_PSCI_FW Commit e5bfb21d98b6 ("firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above") introduced new config option to identify the availability of SMCCC discoverability of version and features transparently hiding the indirect dependency on ARM_PSCI_FW. Commit 5a897e3ab429 ("firmware: arm_scmi: fix psci dependency") just worked around the build dependency making SCMI SMC/HVC transport depend on ARM_PSCI_FW at the time. Since it really just relies on SMCCC directly and not on ARM_PSCI_FW, let us move to use CONFIG_HAVE_ARM_SMCCC_DISCOVERY instead of CONFIG_ARM_PSCI_FW. Link: https://lore.kernel.org/r/20200625101937.51939-1-sudeep.holla@arm.com Cc: Peng Fan <peng.fan@nxp.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5a897e3a |
|
07-May-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: fix psci dependency When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled, arm-scmi runs into a link failure: arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message': smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit' Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now. We rely on PSCI bindings anyways for the conduit and this should be fine. Link: https://lore.kernel.org/r/20200507144905.11397-1-sudeep.holla@arm.com Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1dc65580 |
|
08-Mar-2020 |
Peng Fan <peng.fan@nxp.com> |
firmware: arm_scmi: Add smc/hvc transport Use the value of "arm,smc-id" property from the device tree as the first argument for SMCCC call leaving all the other arguments as zero for now. There is no Rx, only Tx because of smc/hvc not support Rx. Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com Signed-off-by: Peng Fan <peng.fan@nxp.com> [sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5c8a47a5 |
|
30-Jan-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_scmi: Make scmi core independent of the transport type The SCMI specification is fairly independent of the transport protocol, which can be a simple mailbox (already implemented) or anything else. The current Linux implementation however is very much dependent on the mailbox transport layer. This patch makes the SCMI core code (driver.c) independent of the mailbox transport layer and moves all mailbox related code to a new file: mailbox.c and all struct shared_mem related code to a new file: shmem.c. We can now implement more transport protocols to transport SCMI messages. The transport protocols just need to provide struct scmi_transport_ops, with its version of the callbacks to enable exchange of SCMI messages. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
95a15d80 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add RESET protocol in SCMI v2.0 SCMIv2.0 adds a new Reset Management Protocol to manage various reset states a given device or domain can enter. Device(s) that can be collectively reset through a common reset signal constitute a reset domain for the firmware. A reset domain can be reset autonomously or explicitly through assertion and de-assertion of the signal. When autonomous reset is chosen, the firmware is responsible for taking the necessary steps to reset the domain and to subsequently bring it out of reset. When explicit reset is chosen, the caller has to specifically assert and then de-assert the reset signal by issuing two separate RESET commands. Add the basic SCMI reset infrastructure that can be used by Linux reset controller driver. Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ec8f24b7 |
|
19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
898216c9 |
|
14-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add device power domain support using genpd This patch hooks up the support for device power domain provided by SCMI using the Linux generic power domain infrastructure. Cc: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5179c523 |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add initial support for sensor protocol The sensor protocol provides functions to manage platform sensors, and provides the commands to describe the protocol version and the various attribute flags. It also provides commands to discover various sensors implemented and managed by the platform, read any sensor synchronously or asynchronously as allowed by the platform, program sensor attributes and/or configurations, if applicable. This patch adds support for most of the above features. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
76a65509 |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add initial support for power protocol The power protocol is intended for management of power states of various power domains. The power domain management protocol provides commands to describe the protocol version, discover the implementation specific attributes, set and get the power state of a domain. This patch adds support for the above mention features of the protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> -- drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/power.c | 242 +++++++++++++++++++++++++++++++++++++ include/linux/scmi_protocol.h | 28 +++++ 3 files changed, 271 insertions(+), 1 deletion(-) create mode 100644 drivers/firmware/arm_scmi/power.c
|
#
5f6c6430 |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add initial support for clock protocol The clock protocol is intended for management of clocks. It is used to enable or disable clocks, and to set and get the clock rates. This protocol provides commands to describe the protocol version, discover various implementation specific attributes, describe a clock, enable and disable a clock and get/set the rate of the clock synchronously or asynchronously. This patch adds initial support for the clock protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a9e3fbfa |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add initial support for performance protocol The performance protocol is intended for the performance management of group(s) of device(s) that run in the same performance domain. It includes even the CPUs. A performance domain is defined by a set of devices that always have to run at the same performance level. For example, a set of CPUs that share a voltage domain, and have a common frequency control, is said to be in the same performance domain. The commands in this protocol provide functionality to describe the protocol version, describe various attribute flags, set and get the performance level of a domain. It also supports discovery of the list of performance levels supported by a performance domain, and the properties of each performance level. This patch adds basic support for the performance protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
933c5044 |
|
30-Oct-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices The SCMI specification encompasses various protocols. However, not every protocol has to be present on a given platform/implementation as not every protocol is relevant for it. Furthermore, the platform chooses which protocols it exposes to a given agent. The only protocol that must be implemented is the base protocol. The base protocol is used by an agent to discover which protocols are available to it. In order to enumerate the discovered implemented protocols, this patch adds support for a separate scmi protocol bus. It also adds mechanism to register support for different protocols. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b6f20ff8 |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add common infrastructure and support for base protocol The base protocol describes the properties of the implementation and provide generic error management. The base protocol provides commands to describe protocol version, discover implementation specific attributes and vendor/sub-vendor identification, list of protocols implemented and the various agents are in the system including OSPM and the platform. It also supports registering for notifications of platform errors. This protocol is mandatory. This patch adds support for the same along with some basic infrastructure to add support for other protocols. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
aa4f886f |
|
28-Mar-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add basic driver infrastructure for SCMI The SCMI is intended to allow OSPM to manage various functions that are provided by the hardware platform it is running on, including power and performance functions. SCMI provides two levels of abstraction, protocols and transports. Protocols define individual groups of system control and management messages. A protocol specification describes the messages that it supports. Transports describe the method by which protocol messages are communicated between agents and the platform. This patch adds basic infrastructure to manage the message allocation, initialisation, packing/unpacking and shared memory management. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|