mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-12 21:57:43 +00:00
f46f11dc1e
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJalvXJAAoJEABBurwxfuKYUHoQANi5gm0vGgRhb8/Cc6BHF9ij
WVge3E2O+Ygg2qTKJJxWvwG3w09Pu9Pugwoa7vuisDNz4ihF+3WEYCZiwrbQhMOQ
8ZyxXwdBu4Kp0fnNAGGq0MWllwspVgdC2Be5jviDTMw7H8ZIQEiKjxPkdSFY1xFj
YAtTzuUeDcuztUb3IliOpLscxNUqGEQr4p/xj0VFu+1XSwtYo/9bDU7haiYNj0MD
zbNv9WhyjUHTTsdQjDW4YGywQpFPu/oI8oSR5q+Q3mudccaZYbvvTwKDRACLVkr4
rpeymFdGSEU8OI23pKql4eEZ2DC1VKuVnG9peTr9UhhuRL8jQKqFLeCYH0fGcY89
VGWDIFBjyUg1NK7giCriqCq4m68UM49ChITXY6zRrIvyONgUZj6p6kTmCHC3TULH
LWfu9lf7XqI5/AqZaXhHsDPL2Arf0u5K7rP6yaU0BgdQ2HRKV8rIT3KadjsOioAw
bIDfpi4eInmq41CUy1gsWP6nIRg4qR4sZiWC2CW8ap0gbHq8a7PVuuRi4VDCZIkN
CfntuDAnE+FMq/cMpgLRGteNbl0MVAeAeJfEGNyk5ahhYZtvnAy142zDpBmvWZth
ZuZvb7mwiNPiZTC65B/DFDdSCKZtD+LVCodzcm2Pkx6zgW0SC6pje+mX0+zpDxZ9
A9Eguiun1hInKX3URD1D
=qOck
-----END PGP SIGNATURE-----
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
311 lines
8.8 KiB
Text
311 lines
8.8 KiB
Text
#
|
|
# ARM CPU Frequency scaling drivers
|
|
#
|
|
|
|
config ACPI_CPPC_CPUFREQ
|
|
tristate "CPUFreq driver based on the ACPI CPPC spec"
|
|
depends on ACPI_PROCESSOR
|
|
select ACPI_CPPC_LIB
|
|
help
|
|
This adds a CPUFreq driver which uses CPPC methods
|
|
as described in the ACPIv5.1 spec. CPPC stands for
|
|
Collaborative Processor Performance Controls. It
|
|
is based on an abstract continuous scale of CPU
|
|
performance values which allows the remote power
|
|
processor to flexibly optimize for power and
|
|
performance. CPPC relies on power management firmware
|
|
support for its operation.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_ARMADA_37XX_CPUFREQ
|
|
tristate "Armada 37xx CPUFreq support"
|
|
depends on ARCH_MVEBU
|
|
help
|
|
This adds the CPUFreq driver support for Marvell Armada 37xx SoCs.
|
|
The Armada 37xx PMU supports 4 frequency and VDD levels.
|
|
|
|
# big LITTLE core layer and glue drivers
|
|
config ARM_BIG_LITTLE_CPUFREQ
|
|
tristate "Generic ARM big LITTLE CPUfreq driver"
|
|
depends on (ARM_CPU_TOPOLOGY || ARM64) && HAVE_CLK
|
|
# if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be =y
|
|
depends on !CPU_THERMAL || THERMAL
|
|
select PM_OPP
|
|
help
|
|
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
|
|
|
|
config ARM_DT_BL_CPUFREQ
|
|
tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
|
|
depends on ARM_BIG_LITTLE_CPUFREQ && OF
|
|
help
|
|
This enables probing via DT for Generic CPUfreq driver for ARM
|
|
big.LITTLE platform. This gets frequency tables from DT.
|
|
|
|
config ARM_SCPI_CPUFREQ
|
|
tristate "SCPI based CPUfreq driver"
|
|
depends on ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
|
|
help
|
|
This adds the CPUfreq driver support for ARM platforms using SCPI
|
|
protocol for CPU power management.
|
|
|
|
This driver uses SCPI Message Protocol driver to interact with the
|
|
firmware providing the CPU DVFS functionality.
|
|
|
|
config ARM_VEXPRESS_SPC_CPUFREQ
|
|
tristate "Versatile Express SPC based CPUfreq driver"
|
|
depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
|
|
help
|
|
This add the CPUfreq driver support for Versatile Express
|
|
big.LITTLE platforms using SPC for power management.
|
|
|
|
config ARM_BRCMSTB_AVS_CPUFREQ
|
|
tristate "Broadcom STB AVS CPUfreq driver"
|
|
depends on ARCH_BRCMSTB || COMPILE_TEST
|
|
default y
|
|
help
|
|
Some Broadcom STB SoCs use a co-processor running proprietary firmware
|
|
("AVS") to handle voltage and frequency scaling. This driver provides
|
|
a standard CPUfreq interface to to the firmware.
|
|
|
|
Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
|
|
|
|
config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
|
|
bool "Broadcom STB AVS CPUfreq driver sysfs debug capability"
|
|
depends on ARM_BRCMSTB_AVS_CPUFREQ
|
|
help
|
|
Enabling this option turns on debug support via sysfs under
|
|
/sys/kernel/debug/brcmstb-avs-cpufreq. It is possible to read all and
|
|
write some AVS mailbox registers through sysfs entries.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_EXYNOS5440_CPUFREQ
|
|
tristate "SAMSUNG EXYNOS5440"
|
|
depends on SOC_EXYNOS5440
|
|
depends on HAVE_CLK && OF
|
|
select PM_OPP
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver for Samsung EXYNOS5440
|
|
SoC. The nature of exynos5440 clock controller is
|
|
different than previous exynos controllers so not using
|
|
the common exynos framework.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_HIGHBANK_CPUFREQ
|
|
tristate "Calxeda Highbank-based"
|
|
depends on ARCH_HIGHBANK && CPUFREQ_DT && REGULATOR
|
|
default m
|
|
help
|
|
This adds the CPUFreq driver for Calxeda Highbank SoC
|
|
based boards.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_IMX6Q_CPUFREQ
|
|
tristate "Freescale i.MX6 cpufreq support"
|
|
depends on ARCH_MXC
|
|
depends on REGULATOR_ANATOP
|
|
select PM_OPP
|
|
help
|
|
This adds cpufreq driver support for Freescale i.MX6 series SoCs.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_KIRKWOOD_CPUFREQ
|
|
def_bool MACH_KIRKWOOD
|
|
help
|
|
This adds the CPUFreq driver for Marvell Kirkwood
|
|
SoCs.
|
|
|
|
config ARM_MEDIATEK_CPUFREQ
|
|
tristate "CPU Frequency scaling support for MediaTek SoCs"
|
|
depends on ARCH_MEDIATEK && REGULATOR
|
|
depends on !CPU_THERMAL || THERMAL
|
|
select PM_OPP
|
|
help
|
|
This adds the CPUFreq driver support for MediaTek SoCs.
|
|
|
|
config ARM_OMAP2PLUS_CPUFREQ
|
|
bool "TI OMAP2+"
|
|
depends on ARCH_OMAP2PLUS
|
|
default ARCH_OMAP2PLUS
|
|
|
|
config ARM_S3C_CPUFREQ
|
|
bool
|
|
help
|
|
Internal configuration node for common cpufreq on Samsung SoC
|
|
|
|
config ARM_S3C24XX_CPUFREQ
|
|
bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
|
|
depends on ARCH_S3C24XX
|
|
select ARM_S3C_CPUFREQ
|
|
help
|
|
This enables the CPUfreq driver for the Samsung S3C24XX family
|
|
of CPUs.
|
|
|
|
For details, take a look at <file:Documentation/cpu-freq>.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_S3C24XX_CPUFREQ_DEBUG
|
|
bool "Debug CPUfreq Samsung driver core"
|
|
depends on ARM_S3C24XX_CPUFREQ
|
|
help
|
|
Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
|
|
|
|
config ARM_S3C24XX_CPUFREQ_IODEBUG
|
|
bool "Debug CPUfreq Samsung driver IO timing"
|
|
depends on ARM_S3C24XX_CPUFREQ
|
|
help
|
|
Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
|
|
|
|
config ARM_S3C24XX_CPUFREQ_DEBUGFS
|
|
bool "Export debugfs for CPUFreq"
|
|
depends on ARM_S3C24XX_CPUFREQ && DEBUG_FS
|
|
help
|
|
Export status information via debugfs.
|
|
|
|
config ARM_S3C2410_CPUFREQ
|
|
bool
|
|
depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2410
|
|
select S3C2410_CPUFREQ_UTILS
|
|
help
|
|
CPU Frequency scaling support for S3C2410
|
|
|
|
config ARM_S3C2412_CPUFREQ
|
|
bool
|
|
depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2412
|
|
default y
|
|
select S3C2412_IOTIMING
|
|
help
|
|
CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
|
|
|
|
config ARM_S3C2416_CPUFREQ
|
|
bool "S3C2416 CPU Frequency scaling support"
|
|
depends on CPU_S3C2416
|
|
help
|
|
This adds the CPUFreq driver for the Samsung S3C2416 and
|
|
S3C2450 SoC. The S3C2416 supports changing the rate of the
|
|
armdiv clock source and also entering a so called dynamic
|
|
voltage scaling mode in which it is possible to reduce the
|
|
core voltage of the CPU.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_S3C2416_CPUFREQ_VCORESCALE
|
|
bool "Allow voltage scaling for S3C2416 arm core"
|
|
depends on ARM_S3C2416_CPUFREQ && REGULATOR
|
|
help
|
|
Enable CPU voltage scaling when entering the dvs mode.
|
|
It uses information gathered through existing hardware and
|
|
tests but not documented in any datasheet.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_S3C2440_CPUFREQ
|
|
bool "S3C2440/S3C2442 CPU Frequency scaling support"
|
|
depends on ARM_S3C24XX_CPUFREQ && (CPU_S3C2440 || CPU_S3C2442)
|
|
select S3C2410_CPUFREQ_UTILS
|
|
default y
|
|
help
|
|
CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
|
|
|
|
config ARM_S3C64XX_CPUFREQ
|
|
bool "Samsung S3C64XX"
|
|
depends on CPU_S3C6410
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver for Samsung S3C6410 SoC.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_S5PV210_CPUFREQ
|
|
bool "Samsung S5PV210 and S5PC110"
|
|
depends on CPU_S5PV210
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver for Samsung S5PV210 and
|
|
S5PC110 SoCs.
|
|
|
|
If in doubt, say N.
|
|
|
|
config ARM_SA1100_CPUFREQ
|
|
bool
|
|
|
|
config ARM_SA1110_CPUFREQ
|
|
bool
|
|
|
|
config ARM_SCMI_CPUFREQ
|
|
tristate "SCMI based CPUfreq driver"
|
|
depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
|
|
select PM_OPP
|
|
help
|
|
This adds the CPUfreq driver support for ARM platforms using SCMI
|
|
protocol for CPU power management.
|
|
|
|
This driver uses SCMI Message Protocol driver to interact with the
|
|
firmware providing the CPU DVFS functionality.
|
|
|
|
config ARM_SPEAR_CPUFREQ
|
|
bool "SPEAr CPUFreq support"
|
|
depends on PLAT_SPEAR
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver support for SPEAr SOCs.
|
|
|
|
config ARM_STI_CPUFREQ
|
|
tristate "STi CPUFreq support"
|
|
depends on SOC_STIH407
|
|
help
|
|
This driver uses the generic OPP framework to match the running
|
|
platform with a predefined set of suitable values. If not provided
|
|
we will fall-back so safe-values contained in Device Tree. Enable
|
|
this config option if you wish to add CPUFreq support for STi based
|
|
SoCs.
|
|
|
|
config ARM_TANGO_CPUFREQ
|
|
bool
|
|
depends on CPUFREQ_DT && ARCH_TANGO
|
|
default y
|
|
|
|
config ARM_TEGRA20_CPUFREQ
|
|
bool "Tegra20 CPUFreq support"
|
|
depends on ARCH_TEGRA
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver support for Tegra20 SOCs.
|
|
|
|
config ARM_TEGRA124_CPUFREQ
|
|
tristate "Tegra124 CPUFreq support"
|
|
depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR
|
|
default y
|
|
help
|
|
This adds the CPUFreq driver support for Tegra124 SOCs.
|
|
|
|
config ARM_TEGRA186_CPUFREQ
|
|
tristate "Tegra186 CPUFreq support"
|
|
depends on ARCH_TEGRA && TEGRA_BPMP
|
|
help
|
|
This adds the CPUFreq driver support for Tegra186 SOCs.
|
|
|
|
config ARM_TI_CPUFREQ
|
|
bool "Texas Instruments CPUFreq support"
|
|
depends on ARCH_OMAP2PLUS
|
|
help
|
|
This driver enables valid OPPs on the running platform based on
|
|
values contained within the SoC in use. Enable this in order to
|
|
use the cpufreq-dt driver on all Texas Instruments platforms that
|
|
provide dt based operating-points-v2 tables with opp-supported-hw
|
|
data provided. Required for cpufreq support on AM335x, AM437x,
|
|
DRA7x, and AM57x platforms.
|
|
|
|
config ARM_PXA2xx_CPUFREQ
|
|
tristate "Intel PXA2xx CPUfreq driver"
|
|
depends on PXA27x || PXA25x
|
|
help
|
|
This add the CPUFreq driver support for Intel PXA2xx SOCs.
|
|
|
|
If in doubt, say N.
|