linux/drivers/thermal/Kconfig

506 lines
16 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
#
# Generic thermal drivers configuration
#
menuconfig THERMAL
bool "Thermal drivers"
help
Thermal drivers offer a generic mechanism for
thermal management. Usually it's made up of one or more thermal
zones and cooling devices.
Each thermal zone contains its own temperature, trip points,
and cooling devices.
All platforms with ACPI or Open Firmware thermal support can use
this driver.
If you want this support, you should say Y here.
if THERMAL
config THERMAL_NETLINK
bool "Thermal netlink management"
depends on NET
help
The thermal framework has a netlink interface to do thermal
zones discovery, temperature readings and events such as
trip point crossed, cooling device update or governor
change. It is recommended to enable the feature.
thermal: Add cooling device's statistics in sysfs This extends the sysfs interface for thermal cooling devices and exposes some pretty useful statistics. These statistics have proven to be quite useful specially while doing benchmarks related to the task scheduler, where we want to make sure that nothing has disrupted the test, specially the cooling device which may have put constraints on the CPUs. The information exposed here tells us to what extent the CPUs were constrained by the thermal framework. The write-only "reset" file is used to reset the statistics. The read-only "time_in_state_ms" file shows the time (in msec) spent by the device in the respective cooling states, and it prints one line per cooling state. The read-only "total_trans" file shows single positive integer value showing the total number of cooling state transitions the device has gone through since the time the cooling device is registered or the time when statistics were reset last. The read-only "trans_table" file shows a two dimensional matrix, where an entry <i,j> (row i, column j) represents the number of transitions from State_i to State_j. This is how the directory structure looks like for a single cooling device: $ ls -R /sys/class/thermal/cooling_device0/ /sys/class/thermal/cooling_device0/: cur_state max_state power stats subsystem type uevent /sys/class/thermal/cooling_device0/power: autosuspend_delay_ms runtime_active_time runtime_suspended_time control runtime_status /sys/class/thermal/cooling_device0/stats: reset time_in_state_ms total_trans trans_table This is tested on ARM 64-bit Hisilicon hikey620 board running Ubuntu and ARM 64-bit Hisilicon hikey960 board running Android. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2018-04-02 13:56:25 +03:00
config THERMAL_STATISTICS
bool "Thermal state transition statistics"
help
Export thermal state transition statistics information through sysfs.
If in doubt, say N.
config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
int "Emergency poweroff delay in milli-seconds"
default 0
help
Thermal subsystem will issue a graceful shutdown when
critical temperatures are reached using orderly_poweroff(). In
case of failure of an orderly_poweroff(), the thermal emergency
poweroff kicks in after a delay has elapsed and shuts down the system.
This config is number of milliseconds to delay before emergency
poweroff kicks in. Similarly to the critical trip point,
the delay should be carefully profiled so as to give adequate
time for orderly_poweroff() to finish on regular execution.
If set to 0 emergency poweroff will not be supported.
In doubt, leave as 0.
config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
depends on HWMON=y || HWMON=THERMAL
default y
help
In case a sensor is registered with the thermal
framework, this option will also register it
as a hwmon. The sensor will then have the common
hwmon sysfs interface.
Say 'Y' here if you want all thermal sensors to
have hwmon sysfs interface too.
config THERMAL_OF
bool
prompt "APIs to parse thermal data out of device tree"
depends on OF
default y
help
This options provides helpers to add the support to
read and parse thermal data definitions out of the
device tree blob.
Say 'Y' here if you need to build thermal infrastructure
based on device tree.
config THERMAL_ACPI
depends on ACPI
bool
config THERMAL_WRITABLE_TRIPS
bool "Enable writable trip points"
help
This option allows the system integrator to choose whether
trip temperatures can be changed from userspace. The
writable trips need to be specified when setting up the
thermal zone but the choice here takes precedence.
Say 'Y' here if you would like to allow userspace tools to
change trip temperatures.
choice
prompt "Default Thermal governor"
default THERMAL_DEFAULT_GOV_STEP_WISE
help
This option sets which thermal governor shall be loaded at
startup. If in doubt, select 'step_wise'.
config THERMAL_DEFAULT_GOV_STEP_WISE
bool "step_wise"
select THERMAL_GOV_STEP_WISE
help
Use the step_wise governor as default. This throttles the
devices one step at a time.
config THERMAL_DEFAULT_GOV_FAIR_SHARE
bool "fair_share"
select THERMAL_GOV_FAIR_SHARE
help
Use the fair_share governor as default. This throttles the
devices based on their 'contribution' to a zone. The
contribution should be provided through platform data.
config THERMAL_DEFAULT_GOV_USER_SPACE
bool "user_space"
select THERMAL_GOV_USER_SPACE
help
The Userspace governor allows to get trip point crossed
notification from the kernel via uevents. It is recommended
to use the netlink interface instead which gives richer
information about the thermal framework events.
config THERMAL_DEFAULT_GOV_POWER_ALLOCATOR
bool "power_allocator"
depends on THERMAL_GOV_POWER_ALLOCATOR
help
Select this if you want to control temperature based on
system and device power allocation. This governor can only
operate on cooling devices that implement the power API.
endchoice
config THERMAL_GOV_FAIR_SHARE
bool "Fair-share thermal governor"
help
Enable this to manage platform thermals using fair-share governor.
config THERMAL_GOV_STEP_WISE
bool "Step_wise thermal governor"
help
Enable this to manage platform thermals using a simple linear
governor.
config THERMAL_GOV_BANG_BANG
bool "Bang Bang thermal governor"
default n
help
Enable this to manage platform thermals using bang bang governor.
Say 'Y' here if you want to use two point temperature regulation
used for fans without throttling. Some fan drivers depend on this
governor to be enabled (e.g. acerhdf).
config THERMAL_GOV_USER_SPACE
bool "User_space thermal governor"
help
Enable this to let the user space manage the platform thermals.
config THERMAL_GOV_POWER_ALLOCATOR
bool "Power allocator thermal governor"
thermal: cpu_cooling: Migrate to using the EM framework The newly introduced Energy Model framework manages power cost tables in a generic way. Moreover, it supports several types of models since the tables can come from DT or firmware (through SCMI) for example. On the other hand, the cpu_cooling subsystem manages its own power cost tables using only DT data. In order to avoid the duplication of data in the kernel, and in order to enable IPA with EMs coming from more than just DT, remove the private tables from cpu_cooling.c and migrate it to using the centralized EM framework. Doing so should have no visible functional impact for existing users of IPA since: - recent extenstions to the the PM_OPP infrastructure enable the registration of EMs in PM_EM using the DT property used by IPA; - the existing upstream cpufreq drivers marked with the 'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP infrastructure, which means they all support PM_EM. The only two exceptions are qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which doesn't use DT for power costs. For existing users of cpu_cooling, PM_EM tables will contain the exact same power values that IPA used to compute on its own until now. The only new dependency for them is to compile in CONFIG_ENERGY_MODEL. The case where the thermal subsystem is used without an Energy Model (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's frequency table which is already a dependency for cpu_cooling.c anyway. Since the thermal framework expects the cooling states in a particular order, bail out whenever the CPUFreq table is unsorted, since that is fairly uncommon in general, and there are currently no users of cpu_cooling for this use-case. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20191030151451.7961-5-qperret@google.com
2019-10-30 18:14:51 +03:00
depends on ENERGY_MODEL
help
Enable this to manage platform thermals by dynamically
allocating and limiting power to devices.
thermal: add generic cpufreq cooling implementation This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor | | \|/ | Cpufreq cooling device <--------------- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [akpm@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: SangWook Ju <sw.ju@samsung.com> Cc: Durgadoss <durgadoss.r@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2012-08-16 15:41:40 +04:00
config CPU_THERMAL
bool "Generic cpu cooling support"
depends on THERMAL_OF
help
Enable the CPU cooling features. If the system has no active
cooling device available, this option allows to use the CPU
as a cooling device.
if CPU_THERMAL
config CPU_FREQ_THERMAL
bool "CPU frequency cooling device"
depends on CPU_FREQ
default y
thermal: add generic cpufreq cooling implementation This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor | | \|/ | Cpufreq cooling device <--------------- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [akpm@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: SangWook Ju <sw.ju@samsung.com> Cc: Durgadoss <durgadoss.r@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2012-08-16 15:41:40 +04:00
help
This implements the generic cpu cooling mechanism through frequency
reduction. An ACPI version of this already exists
(drivers/acpi/processor_thermal.c).
thermal: add generic cpufreq cooling implementation This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor | | \|/ | Cpufreq cooling device <--------------- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [akpm@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: SangWook Ju <sw.ju@samsung.com> Cc: Durgadoss <durgadoss.r@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2012-08-16 15:41:40 +04:00
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
config CPU_IDLE_THERMAL
bool "CPU idle cooling device"
depends on IDLE_INJECT
help
This implements the CPU cooling mechanism through
idle injection. This will throttle the CPU by injecting
idle cycle.
endif
thermal: add generic cpufreq cooling implementation This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor | | \|/ | Cpufreq cooling device <--------------- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [akpm@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: SangWook Ju <sw.ju@samsung.com> Cc: Durgadoss <durgadoss.r@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2012-08-16 15:41:40 +04:00
config DEVFREQ_THERMAL
bool "Generic device cooling support"
depends on PM_DEVFREQ
depends on PM_OPP
help
This implements the generic devfreq cooling mechanism through
frequency reduction for devices using devfreq.
This will throttle the device by limiting the maximum allowed DVFS
frequency corresponding to the cooling level.
In order to use the power extensions of the cooling device,
devfreq should use the simple_ondemand governor.
thermal: introduce clock cooling device This patch introduces a new thermal cooling device based on common clock framework. The original motivation to write this cooling device is to be able to cool down thermal zones using clocks that feed co-processors, such as GPUs, DSPs, Image Processing Co-processors, etc. But it is written in a way that it can be used on top of any clock. The implementation is pretty straight forward. The code creates a thermal cooling device based on a pair of a struct device and a clock name. The struct device is assumed to be usable by the OPP layer. The OPP layer is used as source of the list of possible frequencies. The (cpufreq) frequency table is then used as a map from frequencies to cooling states. Cooling states are indexes to the frequency table. The logic sits on top of common clock framework, specifically on clock pre notifications. Any PRE_RATE_CHANGE is hijacked, and the transition is only allowed when the new rate is within the thermal limit (cooling state -> freq). When a thermal cooling device state transition is requested, the clock is also checked to verify if the current clock rate is within the new thermal limit. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Mike Turquette <mturquette@linaro.org> Cc: Nishanth Menon <nm@ti.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Len Brown <len.brown@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-pm@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-01-06 17:04:18 +04:00
If you want this support, you should say Y here.
config THERMAL_EMULATION
bool "Thermal emulation mode support"
help
Enable this option to make a emul_temp sysfs node in thermal zone
directory to support temperature emulation. With emulation sysfs node,
user can manually input temperature and test the different trip
threshold behaviour for simulation purpose.
WARNING: Be careful while enabling this option on production systems,
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
config THERMAL_MMIO
tristate "Generic Thermal MMIO driver"
depends on OF
depends on HAS_IOMEM
help
This option enables the generic thermal MMIO driver that will use
memory-mapped reads to get the temperature. Any HW/System that
allows temperature reading by a single memory-mapped reading, be it
register or shared memory, is a potential candidate to work with this
driver.
config HISI_THERMAL
tristate "Hisilicon thermal driver"
depends on ARCH_HISI || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
default y
help
Enable this to plug hisilicon's thermal sensor driver into the Linux
thermal framework. cpufreq is used as the cooling device to throttle
CPUs when the passive trip is crossed.
config IMX_THERMAL
tristate "Temperature sensor driver for Freescale i.MX SoCs"
depends on ARCH_MXC || COMPILE_TEST
depends on NVMEM || !NVMEM
depends on MFD_SYSCON
depends on OF
help
Support for Temperature Monitor (TEMPMON) found on Freescale i.MX SoCs.
It supports one critical trip point and one passive trip point. The
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
config IMX_SC_THERMAL
tristate "Temperature sensor driver for NXP i.MX SoCs with System Controller"
depends on IMX_SCU
depends on OF
help
Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
system controller inside, Linux kernel has to communicate with system
controller via MU (message unit) IPC to get temperature from thermal
sensor. It supports one critical trip point and one
passive trip point for each thermal sensor.
config IMX8MM_THERMAL
tristate "Temperature sensor driver for Freescale i.MX8MM SoC"
depends on ARCH_MXC || COMPILE_TEST
depends on OF
help
Support for Thermal Monitoring Unit (TMU) found on Freescale i.MX8MM SoC.
It supports one critical trip point and one passive trip point. The
cpufreq is used as the cooling device to throttle CPUs when the passive
trip is crossed.
config K3_THERMAL
tristate "Texas Instruments K3 thermal support"
depends on ARCH_K3 || COMPILE_TEST
help
If you say yes here you get thermal support for the Texas Instruments
K3 SoC family. The current chip supported is:
- AM654
This includes temperature reading functionality.
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
depends on OF
help
Support for die junction temperature warning alarm for Maxim
Semiconductor PMIC MAX77620 device. Device generates two alarm
interrupts when PMIC die temperature cross the threshold of
120 degC and 140 degC.
config QORIQ_THERMAL
tristate "QorIQ Thermal Monitoring Unit"
depends on THERMAL_OF && HAS_IOMEM
depends on PPC_E500MC || SOC_LS1021A || ARCH_LAYERSCAPE || (ARCH_MXC && ARM64) || COMPILE_TEST
select REGMAP_MMIO
help
Support for Thermal Monitoring Unit (TMU) found on QorIQ platforms.
It supports one critical trip point and one passive trip point. The
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
config SPEAR_THERMAL
tristate "SPEAr thermal sensor driver"
depends on PLAT_SPEAR || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework.
config SUN8I_THERMAL
tristate "Allwinner sun8i thermal driver"
depends on ARCH_SUNXI || COMPILE_TEST
depends on HAS_IOMEM
depends on NVMEM
depends on OF
depends on RESET_CONTROLLER
help
Support for the sun8i thermal sensor driver into the Linux thermal
framework.
To compile this driver as a module, choose M here: the
module will be called sun8i-thermal.
config ROCKCHIP_THERMAL
tristate "Rockchip thermal driver"
depends on ARCH_ROCKCHIP || COMPILE_TEST
depends on RESET_CONTROLLER
depends on HAS_IOMEM
help
Rockchip thermal driver provides support for Temperature sensor
ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
trip point. Cpufreq is used as the cooling device and will throttle
CPUs when the Temperature crosses the passive trip point.
config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_IOMEM
help
Enable this to plug the R-Car thermal sensor driver into the Linux
thermal framework.
config RCAR_GEN3_THERMAL
tristate "Renesas R-Car Gen3 and RZ/G2 thermal driver"
depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this to plug the R-Car Gen3 or RZ/G2 thermal sensor driver into
the Linux thermal framework.
config RZG2L_THERMAL
tristate "Renesas RZ/G2L thermal driver"
depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this to plug the RZ/G2L thermal sensor driver into the Linux
thermal framework.
config KIRKWOOD_THERMAL
tristate "Temperature sensor on Marvell Kirkwood SoCs"
depends on MACH_KIRKWOOD || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Support for the Kirkwood thermal sensor driver into the Linux thermal
framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
config DOVE_THERMAL
tristate "Temperature sensor on Marvell Dove SoCs"
depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Support for the Dove thermal sensor driver in the Linux thermal
framework.
config DB8500_THERMAL
tristate "DB8500 thermal management"
depends on MFD_DB8500_PRCMU && OF
default y
help
Adds DB8500 thermal management implementation according to the thermal
management framework. A thermal zone with several trip points will be
created. Cooling devices can be bound to the trip points to cool this
thermal zone if trip points reached.
config ARMADA_THERMAL
tristate "Marvell EBU Armada SoCs thermal management"
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this option if you want to have support for thermal management
controller present in Marvell EBU Armada SoCs (370,375,XP,38x,7K,8K).
thermal: da9062/61: Thermal junction temperature monitoring driver Add junction temperature monitoring supervisor device driver, compatible with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added. If the PMIC's internal junction temperature rises above T_WARN (125 degC) an interrupt is issued. This T_WARN level is defined as the THERMAL_TRIP_HOT trip-wire inside the device driver. The thermal triggering mechanism is interrupt based and happens when the temperature rises above a given threshold level. The component cannot return an exact temperature, it only has knowledge if the temperature is above or below a given threshold value. A status bit must be polled to detect when the temperature falls below that threshold level again. A kernel work queue is configured to repeatedly poll and detect when the temperature falls below this trip-wire, between 1 and 10 second intervals (defaulting at 3 seconds). This scheme is provided as an example. It would be expected that any final implementation will also include a notify() function and any of these settings could be altered to match the application where appropriate. When over-temperature is reached, the interrupt from the DA9061/2 will be repeatedly triggered. The IRQ is therefore disabled when the first over-temperature event happens and the status bit is polled using a work-queue until it becomes false. This strategy is designed to allow the periodic transmission of uevents (HOT trip point) as the first level of temperature supervision method. It is intended for non-invasive temperature control, where the necessary measures for cooling the system down are left to the host software. Once the temperature falls again, the IRQ is re-enabled so a new critical over-temperature event can be detected. Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-03-28 17:43:33 +03:00
config DA9062_THERMAL
tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
depends on MFD_DA9062 || COMPILE_TEST
depends on OF
help
Enable this for the Dialog Semiconductor thermal sensor driver.
This will report PMIC junction over-temperature for one thermal trip
zone.
Compatible with the DA9062 and DA9061 PMICs.
menu "Mediatek thermal drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
source "drivers/thermal/mediatek/Kconfig"
endmenu
config AMLOGIC_THERMAL
tristate "Amlogic Thermal Support"
default ARCH_MESON
depends on OF && ARCH_MESON
help
If you say yes here you get support for Amlogic Thermal
for G12 SoC Family.
This driver can also be built as a module. If so, the module will
be called amlogic_thermal.
menu "Intel thermal drivers"
depends on X86 || X86_INTEL_QUARK || COMPILE_TEST
source "drivers/thermal/intel/Kconfig"
endmenu
menu "Broadcom thermal drivers"
depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || ARCH_BCM_IPROC || \
COMPILE_TEST
source "drivers/thermal/broadcom/Kconfig"
endmenu
menu "Texas Instruments thermal drivers"
depends on ARCH_HAS_BANDGAP || COMPILE_TEST
depends on HAS_IOMEM
source "drivers/thermal/ti-soc-thermal/Kconfig"
endmenu
menu "Samsung thermal drivers"
depends on ARCH_EXYNOS || COMPILE_TEST
source "drivers/thermal/samsung/Kconfig"
endmenu
menu "STMicroelectronics thermal drivers"
depends on (ARCH_STI || ARCH_STM32) && OF
source "drivers/thermal/st/Kconfig"
endmenu
source "drivers/thermal/tegra/Kconfig"
config GENERIC_ADC_THERMAL
tristate "Generic ADC based thermal sensor"
depends on IIO
help
This enabled a thermal sysfs driver for the temperature sensor
which is connected to the General Purpose ADC. The ADC channel
is read via IIO framework and the channel information is provided
to this driver. This driver reports the temperature by reading ADC
channel and converts it to temperature based on lookup table.
menu "Qualcomm thermal drivers"
depends on (ARCH_QCOM && OF) || COMPILE_TEST
source "drivers/thermal/qcom/Kconfig"
endmenu
config UNIPHIER_THERMAL
tristate "Socionext UniPhier thermal driver"
depends on ARCH_UNIPHIER || COMPILE_TEST
depends on THERMAL_OF && MFD_SYSCON
help
Enable this to plug in UniPhier on-chip PVT thermal driver into the
thermal framework. The driver supports CPU thermal zone temperature
reporting and a couple of trip points.
config SPRD_THERMAL
tristate "Temperature sensor on Spreadtrum SoCs"
depends on ARCH_SPRD || COMPILE_TEST
help
Support for the Spreadtrum thermal sensor driver in the Linux thermal
framework.
config KHADAS_MCU_FAN_THERMAL
tristate "Khadas MCU controller FAN cooling support"
depends on OF
depends on MFD_KHADAS_MCU
select MFD_CORE
select REGMAP
help
If you say yes here you get support for the FAN controlled
by the Microcontroller found on the Khadas VIM boards.
endif