- 22 7月, 2014 1 次提交
-
-
由 Javi Merino 提交于
Cc: Eduardo Valentin <eduardo.valentin@ti.com> Cc: Zhang Rui <rui.zhang@intel.com> Signed-off-by: NJavi Merino <javi.merino@arm.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 15 7月, 2014 6 次提交
-
-
由 Chanwoo Choi 提交于
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: NChanwoo Choi <cw00.choi@samsung.com> [Add MUX address setting bits by Jonghwa Lee] Signed-off-by: NJonghwa Lee <jonghwa3.lee@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com> Signed-off-by: NZhang 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: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Reviewed-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Riku Voipio 提交于
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: NRiku 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: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Lee Jones 提交于
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: NAjit Pal Singh <ajitpal.singh@st.com> Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Lee Jones 提交于
Supply controller specific information to the ST Thermal Core. Signed-off-by: NAjit Pal Singh <ajitpal.singh@st.com> Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Lee Jones 提交于
This core is shared by both ST's 'memory mapped' and 'system configuration register' based Thermal controllers. Signed-off-by: NAjit Pal Singh <ajitpal.singh@st.com> Signed-off-by: NLee Jones <lee.jones@linaro.org> Acked-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 01 7月, 2014 2 次提交
-
-
由 Rickard Strandqvist 提交于
Wrong address is checked after memory allocation. Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Anson Huang 提交于
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: NAnson Huang <b20788@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 30 6月, 2014 4 次提交
-
-
由 Punit Agrawal 提交于
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: NPunit Agrawal <punit.agrawal@arm.com> Reviewed-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Stephen Boyd 提交于
It looks like this code is missing braces, otherwise the if statement shouldn't have been indented. Fix it. Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Aaron Lu 提交于
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: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Srinivas Pandruvada 提交于
The ACPI object definition can contain passive and critical trip temperature. Export them via thermal sysfs. Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 15 5月, 2014 15 次提交
-
-
由 Jingoo Han 提交于
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Jingoo Han 提交于
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Jingoo Han 提交于
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Acked-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Ezequiel Garcia 提交于
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: NJason Cooper <jason@lakedaemon.net> Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Jacob Pan 提交于
Add support for Broadwell and Valleyview CPUs Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
-
由 Geert Uytterhoeven 提交于
There's no need for this to be synchronous Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Tushar Behera 提交于
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: NTushar Behera <tushar.behera@linaro.org> Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 lan,Tianyu 提交于
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: NLan Tianyu <tianyu.lan@intel.com> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Srinivas Pandruvada 提交于
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: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 07 5月, 2014 6 次提交
-
-
由 Naveen Krishna Chatradhi 提交于
This patch adds the registers, bit fields and compatible strings required to support for the 5 TMU channels on Exynos5260. Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Naveen Krishna Chatradhi 提交于
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: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NAndrew Bresticker <abrestic@chromium.org> Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Naveen Krishna Chatradhi 提交于
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: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Naveen Krishna Chatradhi 提交于
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: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NEduardo 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: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <pwalmsley@nvidia.com> Cc: Eduardo Valentin <eduardo.valentin@ti.com> Cc: Zhang Rui <rui.zhang@intel.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
- 30 4月, 2014 1 次提交
-
-
由 Stratos Karafotis 提交于
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: NStratos Karafotis <stratosk@semaphore.gr> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 4月, 2014 4 次提交
-
-
由 Patrick Titiano 提交于
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: NPatrick Titiano <ptitiano@baylibre.com> Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Patrick Titiano 提交于
Mask is already applied preceding the if statement. Remove the second mask. Signed-off-by: NPatrick Titiano <ptitiano@baylibre.com> Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Jingoo Han 提交于
Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Anson Huang 提交于
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: NAnson Huang <b20788@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 20 3月, 2014 1 次提交
-
-
由 Srivatsa S. Bhat 提交于
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: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-