diff options
author | Arnd Bergmann | 2018-03-07 16:45:07 +0100 |
---|---|---|
committer | Arnd Bergmann | 2018-03-07 16:45:07 +0100 |
commit | f46f11dc1e86270935041fbc3920ba71a050a5fd (patch) | |
tree | e049f00eb27f573e2f3d90d379554c869f6469c3 /drivers/firmware/Kconfig | |
parent | Merge tag 'scpi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kern... (diff) | |
parent | cpufreq: scmi: add support for fast frequency switching (diff) | |
download | kernel-qcow2-linux-f46f11dc1e86270935041fbc3920ba71a050a5fd.tar.gz kernel-qcow2-linux-f46f11dc1e86270935041fbc3920ba71a050a5fd.tar.xz kernel-qcow2-linux-f46f11dc1e86270935041fbc3920ba71a050a5fd.zip |
Merge tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers
Pull "ARM SCMI support for v4.17" from Sudeep Holla:
ARM System Control and Management Interface(SCMI)[1] is more flexible and
easily extensible than any of the existing interfaces.
Few existing as well as future ARM platforms provide micro-controllers
to abstract various power and other system management tasks which have
similar interfaces, both in terms of the functions that are provided by
them, and in terms of how requests are communicated to them.
There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
BPMP, and so on already. This specification is to standardize and avoid any
further fragmentation in the design of such interface by various vendors.
The current SCMI driver implementation is very basic and initial support.
It lacks support for notifications, asynchronous/delayed response, perf/power
statistics region and sensor register region.
Mailbox is the only form of transport supported currently in the driver.
SCMI supports interrupt based mailbox communication, where, on completion
of the processing of a message, the caller receives an interrupt as well as
polling for completion.
SCMI is designed to minimize the dependency on the mailbox/transport
hardware. So in terms of SCMI, each channel in the mailbox includes
memory area, doorbell and completion interrupt.
However the doorbell and completion interrupt is highly mailbox dependent
which was bit of controversial as part of SCMI/mailbox discussions.
Arnd and me discussed about the few aspects of SCMI and the mailbox framework:
1. Use of mailbox framework for doorbell type mailbox controller:
- Such hardware may not require any data to be sent to signal the remote
about the presence of a message. The channel will have in-built
information on how to trigger the signal to the remote.
There are few mailbox controller drivers which are purely doorbell based.
e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc
2. Supporting other mailbox controller:
- SCMI just needs a mechanism to signal the remote firmware. Such
controller may need fixed message to be sent to trigger a doorbell.
In such case we may need to get that data from DT and pass the same
to the controller. It's not covered in the current DT binding, but
can be extended as optional property in future.
However handling notifications may be interesting on such mailbox, but
again there is no way to interpret what the data field(remote message)
means, it could be a bit mask or a number or don't-care.
Arnd mentioned that he doesn't like the way the mailbox binding deals
with doorbell-type hardware, but we do have quite a few precedent drivers
already and changing the binding to add a data field would not make it any
better, but could cause other problems. So he is happy with the status quo
of SCMI implementation.
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html
* tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
cpufreq: scmi: add support for fast frequency switching
cpufreq: add support for CPU DVFS based on SCMI message protocol
hwmon: add support for sensors exported via ARM SCMI
hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration
clk: add support for clocks provided by SCMI
firmware: arm_scmi: add device power domain support using genpd
firmware: arm_scmi: add per-protocol channels support using idr objects
firmware: arm_scmi: refactor in preparation to support per-protocol channels
firmware: arm_scmi: add option for polling based performance domain operations
firmware: arm_scmi: add support for polling based SCMI transfers
firmware: arm_scmi: probe and initialise all the supported protocols
firmware: arm_scmi: add initial support for sensor protocol
firmware: arm_scmi: add initial support for power protocol
firmware: arm_scmi: add initial support for clock protocol
firmware: arm_scmi: add initial support for performance protocol
firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices
firmware: arm_scmi: add common infrastructure and support for base protocol
firmware: arm_scmi: add basic driver infrastructure for SCMI
dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol
dt-bindings: mailbox: add support for mailbox client shared memory
Diffstat (limited to 'drivers/firmware/Kconfig')
-rw-r--r-- | drivers/firmware/Kconfig | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index b7c748248e53..6e83880046d7 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -19,6 +19,40 @@ config ARM_PSCI_CHECKER on and off through hotplug, so for now torture tests and PSCI checker are mutually exclusive. +config ARM_SCMI_PROTOCOL + bool "ARM System Control and Management Interface (SCMI) Message Protocol" + depends on ARM || ARM64 || COMPILE_TEST + depends on MAILBOX + help + ARM System Control and Management Interface (SCMI) protocol is a + set of operating system-independent software interfaces that are + used in system management. SCMI is extensible and currently provides + interfaces for: Discovery and self-description of the interfaces + it supports, Power domain management which is the ability to place + a given device or domain into the various power-saving states that + it supports, Performance management which is the ability to control + the performance of a domain that is composed of compute engines + such as application processors and other accelerators, Clock + management which is the ability to set and inquire rates on platform + managed clocks and Sensor management which is the ability to read + sensor data, and be notified of sensor value. + + This protocol library provides interface for all the client drivers + making use of the features offered by the SCMI. + +config ARM_SCMI_POWER_DOMAIN + tristate "SCMI power domain driver" + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF) + default y + select PM_GENERIC_DOMAINS if PM + help + This enables support for the SCMI power domains which can be + enabled or disabled via the SCP firmware + + This driver can also be built as a module. If so, the module + will be called scmi_pm_domain. Note this may needed early in boot + before rootfs may be available. + config ARM_SCPI_PROTOCOL tristate "ARM System Control and Power Interface (SCPI) Message Protocol" depends on ARM || ARM64 || COMPILE_TEST |