| Age | Commit message (Collapse) | Author |
|---|
|
and 'sti-thermal' of .git into next
|
|
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
This patch add registers, bit fields and compatible strings for Exynos3250 TMU
(Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
a target speed of 1.0 GHz.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
It might not be a problem currently but unregister/uninitialize things
in the reverse order that they are registered/initialized.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
DT-enabled Dove has moved from ARCH_DOVE in mach-dove to MACH_DOVE
in mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
DT-only MACH_DOVE to thermal Kconfig.
This was originally supposed to go in via "ARM: dove: prepare new Dove DT Kconfig"
patch from Sebastian Hesselbarth for 3.15, but slipped through the cracks.
I've tested on CuBox that without this patch you can't compile
dove_thermal into a mach-mvebu based kernel, and with this patch I can
build the driver and it works as expected run-time.
v2: non-ascii char creeped in somehow
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
This is the traditional way of obtaining a device driver's register
address space. The aim of this driver is to supply controller specific
information to the ST Thermal Core.
Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
controller
Supply controller specific information to the ST Thermal Core.
Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
This core is shared by both ST's 'memory mapped' and
'system configuration register' based Thermal controllers.
Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Wrong address is checked after memory allocation.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
On latest i.MX6 SOC with thermal calibration data of 0x5A100000,
the critical trip temperature will be an invalid value and
cause system auto shutdown as below log:
thermal thermal_zone0: critical temperature reached(42 C),shutting down
So, with universal formula for thermal sensor, only room
temperature point is calibrated, which means the calibration
data read from fuse only has valid data of bit [31:20], others
are all 0, the critical trip point temperature can NOT depend
on the hot point calibration data, here we set it to 20 C higher
than default passive temperature.
Signed-off-by: Anson Huang <b20788@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
When binding cooling devices to thermal zones created from the device
tree the minimum and maximum cooling states are in the wrong order
leading to failure to bind.
Fix the order of cooling states in the call to
thermal_zone_bind_cooling_device to fix this.
Cc:Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
It looks like this code is missing braces, otherwise the if
statement shouldn't have been indented. Fix it.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
On 05/21/2014 04:22 PM, Aaron Lu wrote:
> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>> Hello,
>>
>> I get following error when rmmod thermal.
>>
>> rmmod thermal
>> Killed
While dealing with this problem, I found another problem that also
results in a kernel crash on thermal module removal:
From: Aaron Lu <aaron.lu@intel.com>
Date: Wed, 21 May 2014 16:05:38 +0800
Subject: [PATCH] thermal: hwmon: Make the check for critical temp valid consistent
We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
to decide if we need to create the temp_crit attribute file but we just
check if tz->ops->get_crit_temp exists to decide if we need to remove
that attribute file. Some ACPI thermal zone doesn't have a valid critical
trip point and that would result in removing a non-existent device file
on thermal module unload.
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The ACPI object definition can contain passive and critical
trip temperature. Export them via thermal sysfs.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal management update from Zhang Rui:
"Specifics:
- fix a bug in Exynos thermal driver, which overwrites the hardware
trip point threshold when updating software trigger levels and
results in emergency shutdown. From: Tushar Behera.
- add thermal sensor support for Armada 375 and 38x SoCs. From
Ezequiel Garcia.
- add TMU (Thermal Management Unit) support for Exynos5260 and
Exynos5420 SoCs. From Naveen Krishna Chatradhi.
- add support for the additional digital temperature sensors in the
Intel SoCs like Bay Trail. From: Srinivas Pandruvada.
- a couple of cleanups and small fixes from Jingoo Han, Bartlomiej
Zolnierkiewicz, Geert Uytterhoeven, Jacob Pan, Paul Walmsley and
Lan,Tianyu"
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (21 commits)
thermal: spear: remove unnecessary OOM messages
thermal: exynos: remove unnecessary OOM messages
thermal: rcar: remove unnecessary OOM messages
thermal: armada: Support Armada 380 SoC
thermal: armada: Support Armada 375 SoC
thermal: armada: Allow to specify an 'inverted readout' sensor
thermal: armada: Pass the platform_device to init_sensor()
thermal: armada: Add generic infrastructure to handle the sensor
thermal: armada: Add infrastructure to support generic formulas
thermal: armada: Rename armada_thermal_ops struct
thermal/intel_powerclamp: add newer cpu ids
thermal: rcar: Use pm_runtime_put() i.s.o. pm_runtime_put_sync()
thermal: samsung: Only update available threshold limits
Thermal/int3403: Fix thermal hysteresis unit conversion
thermal: Intel SoC DTS thermal
thermal: samsung: Add TMU support for Exynos5260 SoCs
thermal: samsung: Add TMU support for Exynos5420 SoCs
thermal: samsung: change base_common to more meaningful base_second
thermal: samsung: replace inten_ bit fields with intclr_
thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
...
|
|
'intel-soc-dts-thermal' and 'thermal-soc-fixes' of .git into next
|
|
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Now that a generic infrastructure is in place, it's possible to support
the Armada 380 SoC thermal sensor. This sensor is similar to the one
available in the already supported SoCs, with its specific temperature formula
and specific sensor initialization.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Now that a generic infrastructure is in place, it's possible to support
the new Armada 375 SoC thermal sensor. This sensor is similar to the one
available in the already supported SoCs, with its specific temperature formula
and specific sensor initialization.
In addition, we also add support for the Z1 SoC stepping, which needs
an initialization-quirk to work properly.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
In order to support inverted-formula thermal sensor readout, this commit
introduces an 'inverted' field in the SoC-specific structure which
allows to specify an inversion of the temperature formula.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
In order to perform SoC-specific quirks on platforms that need them,
this commit adds a new parameter to the init_sensor() function.
This will be used to support early silicons of the Armada 375 SoC,
to workaround some hardware issues.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
In order to support similar SoC where the sensor value and valid
bit can have different shifts and/or mask, we add such fields to the
per-variant structure, instead of having the values hardcoded.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
In order to support other similar SoC, with different sensor
coefficients, this commit adds the coeficients to the per-variant
structure, instead of having the formula hardcoded.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
As preparation work to add a generic infrastructure to support
different SoC variants, the armada_thermal_ops will be used
to host the SoC-specific fields, such as formula values and
register shifts.
For this reason, the name armada_thermal_ops is no longer suitable,
and this commit replaces it with armada_thermal_data.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Add support for Broadwell and Valleyview CPUs
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
|
|
There's no need for this to be synchronous
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Currently the threshold limits are updated in 2 stages, once for all
software trigger levels and again for hardware trip point.
While updating the software trigger levels, it overwrites the threshold
limit for hardware trip point thereby forcing the Exynos core to issue
an emergency shutdown.
Updating only the required fields in threshold register fixes this issue.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into thermal-soc-fixes
|
|
Thermal hysteresis represents a temperature difference.
But the original code treats it as a temperature value,
Convert it from tenths of degree Kelvin to Milli-Celsius
by deducing 273200. This is not right.
Kelvin and Celsius have same degree size. From temperature
difference view, the conversion between tenths of degree
Kelvin unit and Milli-Celsius unit is just to multiply 100.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
In the Intel SoCs like Bay Trail, there are 2 additional digital temperature
sensors(DTS), in addition to the standard DTSs in the core. Also they support
4 programmable thresholds, out of which two can be used by OSPM. These
thresholds can be used by OSPM thermal control. Out of these two thresholds,
one is used by driver and one user mode can change via thermal sysfs to get
notifications on threshold violations.
The driver defines one critical trip points, which is set to TJ MAX - offset.
The offset can be changed via module parameter (default 5C). Also it uses
one of the thresholds to get notification for this temperature violation.
This is very important for orderly shutdown as the many of these devices don't
have ACPI thermal zone, and expects that there is some other thermal control
mechanism present in OSPM. When a Linux distro is used without additional
specialized thermal control program, BIOS can do force shutdown when thermals
are not under control. When temperature reaches critical, the Linux thermal
core will initiate an orderly shutdown.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
This patch adds the registers, bit fields and compatible strings
required to support for the 5 TMU channels on Exynos5260.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a0000 contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.
Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
Menu for Samsung thermal support is visible on all Samsung
platforms while thermal drivers are currently available only
for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
with ARCH_EXYNOS one.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
Treat both negative and zero return values from clk_round_rate() as
errors. This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather than a
signed type, since some clock sources can generate rates higher than
(2^31)-1 Hz.
Eventually, when calling clk_round_rate(), only a return value of zero
will be considered a error. All other values will be considered valid
rates. The comparison against values less than 0 is kept to preserve
the correct behavior in the meantime.
This patch also gets rid of a comparison between unsigned and signed
values; a side-benefit.
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
The cpufreq core now supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
Also remove the redundant !! operator.
It should have no functional changes.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal management updates from Zhang Rui:
"We only have a couple of fixes/cleanups for platform thermal drivers
this time.
Specifics:
- rcar thermal driver: avoid updating the thermal zone in case an IRQ
was triggered but the temperature didn't effectively change. From
Patrick Titiano.
- update the imx thermal driver' formula of converting thermal
sensor' raw date to real temperature in degree C. From Anson
Huang.
- trivial code cleanups of ti soc thermal and rcar thermal driver
from Jingoo Han and Patrick Titiano"
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
thermal: rcar-thermal: update thermal zone only when temperature changes
thermal: rcar-thermal: fix same mask applied twice
thermal: ti-soc-thermal: Use SIMPLE_DEV_PM_OPS macro
thermal: imx: update formula for thermal sensor
|
|
Avoid updating the thermal zone in case an IRQ was triggered but the
temperature didn't effectively change.
Note this is not a driver issue.
Below is a captured debug trace illustrating the purpose of this patch:
out of 8 thermal zone updates, only 2 are actually necessary.
[ 41.120000] rcar_thermal_work(): cctemp=25000
[ 41.120000] rcar_thermal_work(): nctemp=30000
[ 41.120000] rcar_thermal_work(): temp is now 30000C, update thermal zone
[ 58.990000] rcar_thermal_work(): cctemp=30000
[ 58.990000] rcar_thermal_work(): nctemp=30000
[ 58.990000] rcar_thermal_work(): same temp, do not update thermal zone
[ 59.290000] rcar_thermal_work(): cctemp=30000
[ 59.290000] rcar_thermal_work(): nctemp=30000
[ 59.290000] rcar_thermal_work(): same temp, do not update thermal zone
[ 59.590000] rcar_thermal_work(): cctemp=30000
[ 59.590000] rcar_thermal_work(): nctemp=30000
[ 59.590000] rcar_thermal_work(): same temp, do not update thermal zone
[ 59.890000] rcar_thermal_work(): cctemp=30000
[ 59.890000] rcar_thermal_work(): nctemp=30000
[ 59.890000] rcar_thermal_work(): same temp, do not update thermal zone
[ 60.190000] rcar_thermal_work(): cctemp=30000
[ 60.190000] rcar_thermal_work(): nctemp=30000
[ 60.190000] rcar_thermal_work(): same temp, do not update thermal zone
[ 60.490000] rcar_thermal_work(): cctemp=30000
[ 60.490000] rcar_thermal_work(): nctemp=30000
[ 60.490000] rcar_thermal_work(): same temp, do not update thermal zone
[ 60.790000] rcar_thermal_work(): cctemp=30000
[ 60.790000] rcar_thermal_work(): nctemp=35000
[ 60.790000] rcar_thermal_work(): temp is now 35000C, update thermal zone
I suspect this may be due to sensor sampling accuracy / fluctuation,
but no formal proof.
Signed-off-by: Patrick Titiano <ptitiano@baylibre.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Mask is already applied preceding the if statement.
Remove the second mask.
Signed-off-by: Patrick Titiano <ptitiano@baylibre.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Thermal sensor used to need two calibration points which are
in fuse map to get a slope for converting thermal sensor's raw
data to real temperature in degree C. Due to the chip calibration
limitation, hardware team provides an universal formula to get
real temperature from internal thermal sensor raw data:
Slope = 0.4297157 - (0.0015976 * 25C fuse);
Update the formula, as there will be no hot point calibration
data in fuse map from now on.
Signed-off-by: Anson Huang <b20788@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull CPU hotplug notifiers registration fixes from Rafael Wysocki:
"The purpose of this single series of commits from Srivatsa S Bhat
(with a small piece from Gautham R Shenoy) touching multiple
subsystems that use CPU hotplug notifiers is to provide a way to
register them that will not lead to deadlocks with CPU online/offline
operations as described in the changelog of commit 93ae4f978ca7f ("CPU
hotplug: Provide lockless versions of callback registration
functions").
The first three commits in the series introduce the API and document
it and the rest simply goes through the users of CPU hotplug notifiers
and converts them to using the new method"
* tag 'cpu-hotplug-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (52 commits)
net/iucv/iucv.c: Fix CPU hotplug callback registration
net/core/flow.c: Fix CPU hotplug callback registration
mm, zswap: Fix CPU hotplug callback registration
mm, vmstat: Fix CPU hotplug callback registration
profile: Fix CPU hotplug callback registration
trace, ring-buffer: Fix CPU hotplug callback registration
xen, balloon: Fix CPU hotplug callback registration
hwmon, via-cputemp: Fix CPU hotplug callback registration
hwmon, coretemp: Fix CPU hotplug callback registration
thermal, x86-pkg-temp: Fix CPU hotplug callback registration
octeon, watchdog: Fix CPU hotplug callback registration
oprofile, nmi-timer: Fix CPU hotplug callback registration
intel-idle: Fix CPU hotplug callback registration
clocksource, dummy-timer: Fix CPU hotplug callback registration
drivers/base/topology.c: Fix CPU hotplug callback registration
acpi-cpufreq: Fix CPU hotplug callback registration
zsmalloc: Fix CPU hotplug callback registration
scsi, fcoe: Fix CPU hotplug callback registration
scsi, bnx2fc: Fix CPU hotplug callback registration
scsi, bnx2i: Fix CPU hotplug callback registration
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver changes from Arnd Bergmann:
"These changes are mostly for ARM specific device drivers that either
don't have an upstream maintainer, or that had the maintainer ask us
to pick up the changes to avoid conflicts.
A large chunk of this are clock drivers (bcm281xx, exynos, versatile,
shmobile), aside from that, reset controllers for STi as well as a
large rework of the Marvell Orion/EBU watchdog driver are notable"
* tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits)
Revert "dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac."
Revert "net: stmmac: Add SOCFPGA glue driver"
ARM: shmobile: r8a7791: Fix SCIFA3-5 clocks
ARM: STi: Add reset controller support to mach-sti Kconfig
drivers: reset: stih416: add softreset controller
drivers: reset: stih415: add softreset controller
drivers: reset: Reset controller driver for STiH416
drivers: reset: Reset controller driver for STiH415
drivers: reset: STi SoC system configuration reset controller support
dts: socfpga: Add sysmgr node so the gmac can use to reference
dts: socfpga: Add support for SD/MMC on the SOCFPGA platform
reset: Add optional resets and stubs
ARM: shmobile: r7s72100: fix bus clock calculation
Power: Reset: Generalize qnap-poweroff to work on Synology devices.
dts: socfpga: Update clock entry to support multiple parents
ARM: socfpga: Update socfpga_defconfig
dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
net: stmmac: Add SOCFPGA glue driver
watchdog: orion_wdt: Use %pa to print 'phys_addr_t'
drivers: cci: Export CCI PMU revision
...
|
|
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
Fix the thermal x86-pkg-temp code by using this latter form of callback
registration.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch does a cleanup about the thermal zone govenor,
setting and make the following rule.
1. For thermal zone devices that are registered w/o tz->tzp,
they can use the default thermal governor only.
2. For thermal zone devices w/ governor name specified in
tz->tzp->governor_name, we will use the default govenor
if the governor specified is not available at the moment,
and update tz->governor when the matched governor is registered.
This also fixes a problem that OF registered thermal zones
are running with no governor.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Javi Merino <javi.merino@arm.com>
|
|
In initialization, if the cooling device is initialized at
max cooling state, and the thermal zone temperature is below
the first trip point, then the cooling state can't be updated
to the right state, untill the first trip point be triggered.
To fix this issue, allow first update of cooling device state
during registration, initialized "updated" device field as
"false" (instead of "true").
Signed-off-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST)
broke build on archs wihout io memory.
On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.
drivers/thermal/rcar_thermal.c:404: undefined reference to `devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
