summaryrefslogtreecommitdiff
path: root/include/linux/scmi_protocol.h
AgeCommit message (Collapse)AuthorFilesLines
2019-12-24firmware: arm_scmi: Add support for multiple device per protocolSudeep Holla1-1/+4
Currently only one scmi device is created for each protocol enumerated. However, there is requirement to make use of some procotols by multiple kernel subsystems/frameworks. One such example is SCMI PERFORMANCE protocol which can be used by both cpufreq and devfreq drivers. Similarly, SENSOR protocol may be used by hwmon and iio subsystems, and POWER protocol may be used by genpd and regulator drivers. In order to achieve that, let us extend the scmi bus to match based not only protocol id but also the scmi device name if one is available. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add RESET protocol in SCMI v2.0Sudeep Holla1-0/+26
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>
2019-08-12firmware: arm_scmi: Drop config flag in clk_ops->rate_setSudeep Holla1-1/+1
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum number of pending asynchronous clock rate changes supported by the platform. If it's non-zero, then we should be able to use asynchronous clock rate set for any clocks until the maximum limit is reached. In order to add that support, let's drop the config flag passed to clk_ops->rate_set and handle the asynchronous requests dynamically. Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add asynchronous sensor read if it supportsSudeep Holla1-0/+2
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. We can read that flag and use asynchronous reads for any sensors with that attribute set. Let's use the new scmi_do_xfer_with_response to support asynchronous sensor reads. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Drop async flag in sensor_ops->reading_getSudeep Holla1-1/+1
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. Ideally we should be able to read that flag and use asynchronous reads for any sensors with that attribute set. In order to add that support, let's drop the async flag passed to sensor_ops->reading_get and dynamically switch between sync and async flags based on the attributes as provided by the firmware. Cc: linux-hwmon@vger.kernel.org Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Align few names in sensors protocol with SCMI specificationSudeep Holla1-6/+6
Looks like more code developed during the draft versions of the specification slipped through and they don't match the final released version. This seem to have happened only with sensor protocol. Renaming few command and function names here to match exactly with the released version of SCMI specification for ease of maintenance. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Use the correct style for SPDX License IdentifierSudeep Holla1-1/+1
Fix to correct the SPDX License Identifier style in header file related to firmware frivers for ARM SCMI message protocol. For C header files Documentation/process/license-rules.rst mandates C-like comments(opposed to C source files where C++ style should be used). While at it, change GPL-2.0 to GPL-2.0-only similar to the ones in psci.h and scpi_protocol.h Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-06-12firmware: arm_scmi: fetch and store sensor scaleFlorian Fainelli1-0/+1
In preparation for dealing with scales within the SCMI HWMON driver, fetch and store the sensor unit scale into the scmi_sensor_info structure. In order to simplify computations for upper layer, take care of sign extending the scale to a full 8-bit signed value. Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> [sudeep.holla: update bitfield values as per specification] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-09-10firmware: arm_scmi: add a getter for power of performance statesQuentin Perret1-0/+4
The SCMI protocol can be used to get power estimates from firmware corresponding to each performance state of a device. Although these power costs are already managed by the SCMI firmware driver, they are not exposed to any external subsystem yet. Fix this by adding a new get_power() interface to the exisiting perf_ops defined for the SCMI protocol. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-05-10firmware: arm_scmi: rename get_transition_latency and add_opps_to_deviceSudeep Holla1-5/+5
Most of the scmi code follows the suggestion from Greg KH on a totally different thread[0] to have the subsystem name first, followed by the noun and finally the verb with couple of these exceptions. This patch fixes them so that all the functions names are aligned to that practice. [0] https://www.spinics.net/lists/arm-kernel/msg583673.html Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-05-09firmware: arm_scmi: fix kernel-docs documentationSudeep Holla1-0/+8
There are few missing descriptions for function parameters and structure members along with certain instances where excessive function parameters or structure members are described. This patch fixes all of those warnings. Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add option for polling based performance domain operationsSudeep Holla1-4/+4
In order to implement fast CPU DVFS switching, we need to perform all DVFS operations atomically. Since SCMI transfer already provide option to choose between pooling vs interrupt driven(default), we can opt for polling based transfers for set,get performance domain operations. This patch adds option to choose between polling vs interrupt driven SCMI transfers for set,get performance level operations. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add initial support for sensor protocolSudeep Holla1-0/+46
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>
2018-02-28firmware: arm_scmi: add initial support for power protocolSudeep Holla1-0/+28
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
2018-02-28firmware: arm_scmi: add initial support for clock protocolSudeep Holla1-0/+44
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>
2018-02-28firmware: arm_scmi: add initial support for performance protocolSudeep Holla1-0/+42
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>
2018-02-28firmware: arm_scmi: add scmi protocol bus to enumerate protocol devicesSudeep Holla1-0/+64
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>
2018-02-28firmware: arm_scmi: add common infrastructure and support for base protocolSudeep Holla1-0/+37
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>
2018-02-28firmware: arm_scmi: add basic driver infrastructure for SCMISudeep Holla1-0/+16
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>