This driver is a current limit management module to help manage
instantaneous peak current drawn by multiple subsystems on shared
supply. The inputs to the mitigation algorithm are current states
of different subsystems sharing this supply like cpu frequency,
gpu frequency, number of cores online, soc temperature, core leakage,
and modem state. It throttles cpu frequency and limits number of
online cores to reduce the dynamic current so as to keep the total
current drawn from supply in safe limits.
Change-Id: I4592b8be48bad3709e8cfb09da53f23279a8ff9b
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Add a driver to interact with the limits management hardware
lite (LMH-lite).
This driver provides API, which will interact with the trustzone
for getting details like the,
1. sensors supported by the LMH
2. sensors throttling intensity
3. various operating profiles
The driver also provides API for changing the LMH operating profile
and to enable or disable hardware event logs.
The driver handles the interrupt from the LMH-Lite hardware and
notifies the LMH ISR framework. The LMH ISR framework monitors the
throttling intensity of the sensors and then re-arms the interrupt
when the throttling intensities of all the sensors are zero.
CRs-Fixed: 704088
CRs-Fixed: 698387
Change-Id: I9eafb572c4a2a2d89ea55baa4eef23d592d32170
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Add a new Limits management hardware (LMH) monitor driver.
The LMH hardware driver, which interacts with the LMH hardware
via a secure image like TZ or hypervisor should register all
the LMH sensors with this driver. LMH monitor driver in turn
registers the sensors with the thermal sysfs framework.
The LMH monitor driver, when notified of a hardware throttling
interrupt by the hardware driver, will read the throttling
intensity and notify the thermal sysfs framework when
thresholds are crossed.
If the LMH hardware is capable of supporting multiple operating
profiles, then it can register itself separately as LMH
profile device. LMH Monitor driver exposes APIs to get/set the
LMH profiles.
LMH monitor driver exposes the below debugfs interfaces.
/sys/kernel/debug/lmh_monitor/interrupt_poll_delay_msec
- Configures the interrupt polling interval in the LMH
monitor driver. This value can be used by the hardware
driver also.
/sys/kernel/debug/lmh_monitor/hw_trace_enable
- Enable/disable LMH trace
/sys/kernel/debug/lmh_monitor/hw_trace_interval
- Interval in XO clock ticks for adding timestamp in the
trace logs.
/sys/kernel/debug/lmh_monitor/lmh-profile/level
- Set or get the current LMH operating profile
/sys/kernel/debug/lmh_monitor/lmh-profile/total_levels
- Total operating profile levels supported in this platform
/sys/kernel/debug/lmh_monitor/lmh-profile/available_levels
- Lists the available profile levels for this platform.
CRs-Fixed: 704088
CRs-Fixed: 698387
Change-Id: I9afb9b8ef8532d8af383b9afc039654a2d550af4
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Remove early initialization of TSENS
(temperature sensors driver) and Thermal drivers
from the existing board file. These can instead have
early driver initialization by changing the init calls
to use arch_init_call(). This allows having to support
boards that may not have a board file support.
Adding the initcall change within TSENS driver also
requires changing the client Thermal driver within
the same patch to avoid a crash due to dependencies
of early initialiation between these two drivers.
To avoid this also add support within the TSENS
driver to check for probe deferral and corresponding
changes to the Thermal driver to call this API.
Also include the data type check to avoid compilation
within the TSENS driver.
Change-Id: I787a95ae3a77d11ec8dcef8ce5eb404aabd27785
Signed-off-by: Dipen Parmar <dipenp@codeaurora.org>
Kernel Thermal Monitor exposes an IOCTL dev interface, which can
be used for user space cpu frequency mitigation.
CRs-Fixed: 538981
Change-Id: I48ab6be5a9bebee5219c94bdff81badf09576b2a
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
This change removes source files from the kernel tree that
were not being used during make. The list of used files
was generated using an annotated make log and was then
compared with new files added since the public release of
kernel version 3.10.00. New files which were added but
not used have been removed from the tree.
A diff was also run to determine the list of files that had
been modified since the release of kernel version 3.10.00.
These files were then scrubbed based on the current kernel
configuration, removing invalid and unused conditionals.
Some files which support planned functionality or are
useful in debugging have been excluded from this reap.
Change-Id: Ia44a224d3cea7bc78dd45e8a8279860d35d4b008
Signed-off-by: Ian Maund <imaund@codeaurora.org>
The thermal monitoring QPNP ADC driver is used for
monitoring multiple channels with recurring
measurements. It configures the VADC_TM peripheral
to set voltage and temperature thresholds and
notifies clients once the thresholds are crossed.
Upto five channels can be individually configured
for input channel, interval time, low and high
threshold.
The driver is added as part of the thermal sysfs
interface to provide the thermal clients the
ability to set temperature thresholds and receive
notification. Clients can separately enable/disable
low/high temperature thresholds for notification.
Channels 3 through 5 are allocated for thermistor
channels that can be used by the thermal clients
using thermal sysfs for temperature threshold
notification.
Separate kernel api's are provided for usb_id
and batt_therm driver to set voltage and temperature
threshold notifications. TM Channels 0 and 1 are
statically mapped for usb_id and batt_therm monitoring
respectively.
Change-Id: I8de8a494d68d3b29c029fdc7d650a8b74f17a645
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Add support for the temperature alarm peripheral found inside
Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
peripheral outputs a pulse on an interrupt line whenever the
thermal over temperature stage value changes. Implement an ISR
to manage this interrupt.
Register a thermal zone device in sysfs with mulitple trip points
corresponding to the physical threshold temperatures between over
temperature stages. The temperature reported by this thermal
zone device should reflect the actual PMIC die temperature if an
ADC is present on the given PMIC. If no ADC is present, then the
reported temperature should be estimated from the over
temperature stage value.
Send a notification to userspace via sysfs_notify() whenever the
over temperature stage value changes.
Change-Id: Icce6f3668befd9455270d7a8e553e76501d9bd74
Signed-off-by: David Collins <collinsd@codeaurora.org>
MSM8974 TSENS block supports 11 temperature
sensors that are used for thermal mitigation.
The TSENS driver is part of the thermal sysfs
framework that allows clients to set thresholds
and receive notification on temperature thresholds
being crossed through thermal sysfs.
The driver provides ability to thermal clients
to set upper/lower thresholds for each sensor
and receive individual notification for each
sensor once the threshold is crossed.
All sensors are enabled by default during
driver initialization.
The driver is initialized early during kernel
initialization to provide capability to the
thermal kernel driver to read temperature
from the TSENS sensors. To support this feature
a kernel API is provide to read the TSENS
temperature.
Change-Id: If17daae81cfb522a9cea786b5db0c920adb5ed2d
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Add a thermal driver to poll and detect any thermal condition at boot
and limit max cpu frequency on a thermal condition. This driver is
intended to limit cpu thermal output until the userspace thermald
kicks in. The thermald will disable this driver and take over the
cpu thermal sensing and mitigation.
Change-Id: I2710bfdeb5bf01c864437e13da835621d1b9202c
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
TSENS V2 supports reading from multiple sensors and
notifiying clients when the lower/upper thresholds
are reached. The lower/upper threshold use the last
sensors threshold that are set through the thermal sysfs.
TSENS HW is enabled only when the main sensor is requested.
The TSENS block is disabled if the main senors is disabled
irrespective of any other sensors that are being enabled.
When TSENS receives notification on temperature threshold
being reached, it checks and sends events to the sensors
that are enabled and whose thresholds are above the upper
or below the lower thresholds set in the tsens threshold
register.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Add a PMIC PM8xxx thermal management driver which handles
interrupts associated with thermal overload events and
which provides a means to read the current PMIC die
temperature.
Change-Id: I2063be9335be2971810358e82dd273e8a0acec5a
Signed-off-by: David Collins <collinsd@codeaurora.org>
The msm_tsens driver provides temperature notification to
thermal sys driver once the set threshold temperature
is reached and supports configuring the temperature
thresholds. The thermal sys interface is used by userspace
clients to set the configurable temperature thresholds and
receive notification.
Change-Id: I4fcbd2d88a1d36b9eacaeca1925cfe2d3b72f3d9
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Add msm_popmem-tm driver for monitoring the temperature of
MSM POP memory. The temperature reported is based off of
the refresh rate of the POP memory. The temperatures
are reported as follows:
Low Temperature: 25C
Normal Temperature: 50C
High (out of range) Temperature: 85C
Change-Id: Id299ac574745b2a5580ff9999dd514481468c184
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
The thermal governors are part of the thermal framework,
rather than a seperate feature/module.
Because the generic thermal layer can not work without
thermal governors, and it must load the thermal governors
during its initialization.
Build them into one module in this patch.
This also fix a problem that the generic thermal layer does not
work when CONFIG_THERMAL=m and CONFIG_THERMAL_GOV_XXX=y.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Eduardo Valentin <eduardo.valentin@ti.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
this is the preparation work to build all the thermal core framework
source file, like governors, cpu cooling, etc, into one module.
No functional change in this patch.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Eduardo Valentin <eduardo.valentin@ti.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
This driver supports both Armada 370 and Armada XP SoC
thermal management controllers.
Armada 370 has a register to check a valid temperature, whereas
Armada XP does not. Each has a different initialization (i.e. calibration)
function. The temperature conversion formula is the same for both.
The controller present in each SoC have a very similar feature set,
so it corresponds to have one driver to support both of them.
Although this driver may present similarities to Dove and Kirkwood
thermal driver, the exact differences and coincidences are not fully
known. For this reason, support is given through a separate driver.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Currently, we have three Kconfig options for thermal governors, aka,
CONFIG_FAIR_SHARE, CONFIG_USER_SPACE and CONFIG_STEP_WISE.
But these names are too generic that may bring confusion to users.
Rename them to CONFIG_THERMAL_GOV_FAIR_SHARE,
CONFIG_THERMAL_GOV_USER_SPACE, CONFIG_THERMAL_GOV_STEP_WISE
to avoid the generic naming.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The Marvell Dove SoC has a thermal sensor. Add a driver using the
thermal framework.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch adds support for Kirkwood 88F6282 and 88F6283 thermal sensor.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Intel PowerClamp driver performs synchronized idle injection across
all online CPUs. The goal is to maintain a given package level C-state
ratio.
Compared to other throttling methods already exist in the kernel,
such as ACPI PAD (taking CPUs offline) and clock modulation, this is often
more efficient in terms of performance per watt.
Please refer to Documentation/thermal/intel_powerclamp.txt for more details.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This driver is based on the thermal management framework in thermal_sys.c. A
thermal zone device is created with the trip points to which cooling devices
can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
clipped down to cool the CPU, and other cooling devices can be added and bound
to the trip points dynamically. The platform specific PRCMU interrupts are
used to active thermal update when trip points are reached.
Signed-off-by: hongbo.zhang <hongbo.zhang@linaro.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Francesco Lavra <francescolavra.fl@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch registers a governor which will let the
user land manage the platform thermals. Whenever a
trip happens, this governor just notifies the user
space using kobj_uevent().
Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch adds a simple step_wise governor to the
generic thermal layer. This algorithm throttles the
cooling devices in a linear fashion. If the 'trend'
is heating, it throttles by one step. And if the
thermal trend is cooling it de-throttles by one step.
This actually moves the throttling logic from thermal_sys.c
and puts inside step_wise.c, without any change.
Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch introduces a simple 'weight' based
governor named fair_share governor. Whenever the
thermal framework gets notified of the trip point
violation, this governor (if configured), throttles
the cooling devices associated with a thermal zone.
This mapping between a thermal zone and a cooling device
and the effectiveness of cooling are provided in the
platform layer.
Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This movement is needed because the hwmon entries and corresponding sysfs
interface is a duplicate of utilities already provided by
driver/thermal/thermal_sys.c. The goal is to place it in thermal folder
and add necessary functions to use the in-kernel thermal interfaces.
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
Acked-by: 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>
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>
This patch add basic Renesas R-Car thermal sensor support.
It was tested on R-Car H1 Marzen board.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ST's SPEAr13xx machines are based on CortexA9 ARM processors. These
machines contain a thermal sensor for junction temperature monitoring.
This patch adds support for this thermal sensor in existing thermal
framework.
[akpm@linux-foundation.org: little code cleanup]
[akpm@linux-foundation.org: print the pointer correctly]
[viresh.kumar@st.com: thermal/spear_thermal: add compilation dependency on PLAT_SPEAR]
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Build the generic thermal driver as module "thermal_sys".
Make ACPI thermal, video, processor and fan SELECT the generic
thermal driver, as these drivers rely on it to build the sysfs I/F.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The Generic Thermal sysfs driver for thermal management.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Manaf Meethalavalappu Pallikunhi