RE: [PATCH v2] thermal: consistently use int for temperatures

2015-07-23 Thread Zhang, Rui
As the original patch has not been in upstream, I'd prefer a refreshed patch, 
rather than an incremental fix.

Thanks,
rui

 -Original Message-
 From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
 Sent: Thursday, July 23, 2015 6:38 PM
 To: Zhang, Rui
 Cc: Punit Agrawal; linux...@vger.kernel.org; Eduardo Valentin; linux-
 ker...@vger.kernel.org; Jean Delvare; Peter Feuerer; Heiko Stuebner;
 Lukasz Majewski; Stephen Warren; Thierry Reding; linux-
 a...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; linux-o...@vger.kernel.org; linux-samsung-
 s...@vger.kernel.org; Guenter Roeck; Rafael J. Wysocki; Maxime Ripard;
 Darren Hart; lm-sens...@lm-sensors.org
 Subject: Re: [PATCH v2] thermal: consistently use int for temperatures
 Importance: High
 
 Hi Zhang,
 
 On Tue, Jul 21, 2015 at 01:35:31PM +, Zhang, Rui wrote:
   
  Patch applied.
 
 Thanks for applying. I missed to convert another place, so we get a new
 compiler warning. The attached patch fixes this (suitable for git rebase --
 autosquash). Please let me know if you can handle this or if you prefer a new
 patch instead.
 
 Thanks
  Sascha
 
 
 -8-
 
 From 4907a7c32fd16eaf9f31d9f904276c9a0176b717 Mon Sep 17 00:00:00 2001
 From: Sascha Hauer s.ha...@pengutronix.de
 Date: Thu, 23 Jul 2015 12:32:31 +0200
 Subject: [PATCH] fixup! thermal: consistently use int for temperatures
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 fixes:
 drivers/power/charger-manager.c: In function
 ‘cm_get_battery_temperature’:
 drivers/power/charger-manager.c:622:45: warning: passing argument 2 of
 ‘thermal_zone_get_temp’ from incompatible pointer type
ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long *)temp);
 
 Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
 ---
  drivers/power/charger-manager.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-
 manager.c index 1c202cc..907293e 100644
 --- a/drivers/power/charger-manager.c
 +++ b/drivers/power/charger-manager.c
 @@ -619,7 +619,7 @@ static int cm_get_battery_temperature(struct
 charger_manager *cm,
 
  #ifdef CONFIG_THERMAL
   if (cm-tzd_batt) {
 - ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long
 *)temp);
 + ret = thermal_zone_get_temp(cm-tzd_batt, temp);
   if (!ret)
   /* Calibrate temperature unit */
   *temp /= 100;
 --
 2.1.4
 
 
 --
 Pengutronix e.K.   | |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH v2 0/9] thermal: exynos: various cleanups

2014-06-30 Thread Zhang Rui
Eduardo,

what do you think of this patch set?

thanks,
rui

On Tue, 2014-06-17 at 19:27 +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series contains various cleanups for EXYNOS thermal
 driver.  Overall it decreases driver's LOC by 12%.  It is based
 on next-20140617 kernel.  It should not cause any functionality
 changes.
 
 Changes since v1:
 - synced patches against next-20140617
 - merged patch thermal: exynos: remove unused defines into
   thermal: exynos: remove unused struct exynos_tmu_registers
   entries one (per request from Eduardo)
 - improved patch descriptions for patches #1-5
 - fixed documentation for pdata-gain and pdata-reference_voltage
 - added Reviewed-by from Amit to patches #6, #7 and #10
 - added missing Acked-by from Kyungmin Park
 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (9):
   thermal: exynos: remove unused struct exynos_tmu_registers entries
   thermal: exynos: remove dead code for HW_MODE calibration
   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
 calibration
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_initialize()
   thermal: exynos: remove redundant threshold_code checks from
 exynos_tmu_initialize()
   thermal: exynos: simplify temp_to_code() and code_to_temp()
   thermal: exynos: cache non_hw_trigger_levels in pdata
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_control()
   thermal: exynos: remove identical values from exynos*_tmu_registers
 structures
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 181 
 
  drivers/thermal/samsung/exynos_tmu.h|  90 +---
  drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
  drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
  5 files changed, 41 insertions(+), 328 deletions(-)
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] thermal: samsung: Only update available threshold limits

2014-05-15 Thread Zhang Rui
On 四, 2014-04-24 at 11:48 +0530, Amit Kachhap wrote:
 On 4/14/14, Tushar Behera tushar.beh...@linaro.org wrote:
  Currently the threshold limits are updated in 2 stages, once for all
  software trigger levels and again for hardware trip point.
 I guess the first stage is bootloader as could not find this in this file.
 Anyways the changes looks fine to me.
 
 Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com

applied.

thanks,
rui
 
 
  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.beh...@linaro.org
  ---
  Based on v3.15-rc1.
 
   drivers/thermal/samsung/exynos_tmu.c |4 
   1 file changed, 4 insertions(+)
 
  diff --git a/drivers/thermal/samsung/exynos_tmu.c
  b/drivers/thermal/samsung/exynos_tmu.c
  index 0d96a51..ffccc89 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -225,6 +225,8 @@ skip_calib_data:
  trigger_levs++;
  }
 
  +   rising_threshold = readl(data-base + reg-threshold_th0);
  +
  if (data-soc == SOC_ARCH_EXYNOS4210) {
  /* Write temperature code for threshold */
  threshold_code = temp_to_code(data, pdata-threshold);
  @@ -249,6 +251,7 @@ skip_calib_data:
  ret = threshold_code;
  goto out;
  }
  +   rising_threshold = ~(0xff  8 * i);
  rising_threshold |= threshold_code  8 * i;
  if (pdata-threshold_falling) {
  threshold_code = temp_to_code(data,
  @@ -281,6 +284,7 @@ skip_calib_data:
  }
  if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
  /* 1-4 level to be assigned in th0 reg */
  +   rising_threshold = ~(0xff  8 * i);
  rising_threshold |= threshold_code  8 * i;
  writel(rising_threshold,
  data-base + reg-threshold_th0);
  --
  1.7.9.5
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
  in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/10] thermal: exynos: various cleanups

2014-05-15 Thread Zhang Rui
On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series contains various cleanups for EXYNOS thermal
 driver.  Overall it decreases driver's LOC by 13%.  It is based
 on next-20140428 kernel.  It should not cause any functionality
 changes.
 
Amit,

what do you think of this patch set?

thanks,
rui
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (10):
   thermal: exynos: remove unused struct exynos_tmu_registers entries
   thermal: exynos: remove unused defines
   thermal: exynos: remove dead code for HW_MODE calibration
   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
 calibration
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_initialize()
   thermal: exynos: remove redundant threshold_code checks from
 exynos_tmu_initialize()
   thermal: exynos: simplify temp_to_code() and code_to_temp()
   thermal: exynos: cache non_hw_trigger_levels in pdata
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_control()
   thermal: exynos: remove identical values from exynos*_tmu_registers
 structures
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 181 
 
  drivers/thermal/samsung/exynos_tmu.h|  86 +--
  drivers/thermal/samsung/exynos_tmu_data.c   |  40 +-
  drivers/thermal/samsung/exynos_tmu_data.h   |  32 +
  5 files changed, 37 insertions(+), 303 deletions(-)
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v12 0/7] cpufreq:boost: CPU Boost mode support

2014-01-09 Thread Zhang Rui
On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote:
 On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote:
  Hi Rafael,
 
 Hi,
 
   This patch series introduces support for CPU overclocking technique
   called Boost.
   
   It is a follow up of a LAB governor proposal. Boost is a LAB
   component:
   http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
   
   Boost unifies hardware based solution (e.g. Intel Nehalem) with
   software oriented one (like the one done at Exynos).
   For this reason cpufreq/freq_table code has been reorganized to
   include common code.
   
   Important design decisions:
   - Boost related code is compiled-in unconditionally to cpufreq core
   and disabled by default. The cpufreq_driver is responsibile for
   setting boost_supported flag and providing set_boost callback(if HW
   support is needed). For software managed boost, special Kconfig flag -
 CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only
 when a target platform has thermal framework properly configured.
   
   - struct cpufreq_driver has been extended with boost related fields:
   -- boost_supported - when driver supports boosting
   -- boost_enabled - boost state
   -- set_boost - callback to function, which is necessary to
  enable/disable boost
   
   - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is
   visible _only_ when cpufreq driver supports Boost.
   
   - No special spin_lock for Boost was created. The one from cpufreq
   core was reused.
   
   - The Boost code doesn't rely on any policy. When boost state is
   changed, then the policy list is iterated and proper adjustements are
   done.
   
   - To improve safety level, the thermal framework is also extended to
   disable software boosting, when thermal trip point is reached. After
   cooling down the boost can be enabled again. This emulates behaviour
   similar to HW managed boost (like x86)
   
   Tested at HW:
  Exynos 4412 3.13-rc4 Linux
  Intel Core i7-3770 3.13-rc4 Linux
   
   Above patches were posted on top of kernel_pm/bleeding-edge
   (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149)
   
   Lukasz Majewski (7):
 cpufreq: Add boost frequency support in core
 cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common
   boost solution
 cpufreq:boost:Kconfig: Provide support for software managed BOOST
 cpufreq:exynos:Extend Exynos cpufreq driver to support boost
   framework
 Documentation:cpufreq:boost: Update BOOST documentation
 cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ
 thermal:exynos:boost: Automatic enable/disable of BOOST feature (at
   Exynos4412)
   
Documentation/cpu-freq/boost.txt  |   26 +++
drivers/cpufreq/Kconfig   |4 +
drivers/cpufreq/Kconfig.arm   |   15 
drivers/cpufreq/acpi-cpufreq.c|   86
   +++-- drivers/cpufreq/cpufreq.c |
   118 -
   drivers/cpufreq/exynos-cpufreq.c  |3 +
   drivers/cpufreq/exynos4x12-cpufreq.c  |2 +-
   drivers/cpufreq/freq_table.c  |   56 --
   drivers/thermal/samsung/exynos_tmu_data.c |   12 +--
   include/linux/cpufreq.h   |   24 ++ 10 files
   changed, 261 insertions(+), 85 deletions(-)
   
  
  A gentle ping about BOOST patches.
  
  Its been already acked by Viresh and Eduardo.
  
  It applies on kernel_pm/bleeding_edge SHA1:
  4836deb72c5e2a9af0cb2129c1149783a26d99ab
 
 It looks like Rui is still looking into this.
 
 Rui, are you fine with this series?
 
Yes, I'm okay with the thermal related parts of this patch set.

thanks,
rui
 Rafael
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v12 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)

2014-01-09 Thread Zhang Rui
On Fri, 2013-12-20 at 15:24 +0100, Lukasz Majewski wrote:
 This patch provides auto disable/enable operation for boost. It uses already
 present thermal infrastructure to provide BOOST hysteresis.
 The TMU data has been modified to work properly with or without BOOST.
 Hence, the two first trip points with corresponding clip frequencies were
 adjusted.
 
 The first one was reduced from 85 to 70 degrees and clip frequency was
 increased to 1.4 GHz from 800 MHz. This trip point is in fact responsible
 for providing BOOST hysteresis. When temperature exceeds 70 deg, the maximal
 non BOOST frequency for Exynos4412 is imposed.
 
 Since the first trigger level has been stolen for BOOST, the second one
 needs to be a compromise for the previously used two for non BOOST
 configuration. The 95 deg with modified clip freq (to 400 MHz) shall provide
 a good balance between cooling down the overheated device and throughput on
 an acceptable level.
 
 Two last trigger levels were not modified since, they cause platform shutdown
 on emergency overheat situation.
 Third trip point passage results in SW managed shut down of the system.
 If the last trip point is crossed, the PMU HW generates the power off
 signal.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Myungjoo Ham myungjoo@samsung.com
 Acked-by: Eduardo Valentin eduardo.valen...@ti.com

Reviewed-by: Zhang Rui rui.zh...@intel.com

thanks,
rui
 
 ---
 Changes for v12:
 - More verbose patch description to explain new TMU temperature assignment
   for Exynos4412
 
 Changes for v11:
 - Use only one thermal data set
 - Adjust Exynos4412 thermal data to work with or without BOOST
 
 Changes for v10:
 - Remove boost related code from thermal_core.c
 - Use already present thermal infrastructure to provide thermal hysteresis
 - Introduce special set of TMU data for BOOST
 
 Changes for v9:
 - None
 
 Changes for v8:
 - Move cpufreq_boost_* stub functions definition (needed when cpufreq
   is not compiled in) to cpufreq.h at cpufreq core support commit
 
 Changes for v7:
 - None
 
 Changes for v6:
 - Disable boost only when supported and enabled
 - Protect boost related thermal_zone_device struct fields with mutex
 - Evaluate temperature trend during boost enable decision
 - Create separate methods to handle boost enable/disable
   (thermal_boost_{enable|disable}) operations
 - Boost is disabled at any trip point passage (not only the non critical 
 one)
 - Add stub definitions for cpufreq boost functions used when
   CONFIG_CPU_FREQ is NOT defined.
 
 Changes for v5:
 - Move boost disable code from cpu_cooling.c to thermal_core.c
   (to handle_non_critical_trips)
 - Extent struct thermal_zone_device by adding overheated bool flag
 - Implement auto enable of boost after device cools down
 - Introduce boost_polling flag, which indicates if thermal uses it's 
 predefined
   pool delay or has woken up thermal workqueue only to wait until device
   cools down.
 
 Changes for v4:
 - New patch
 
  drivers/thermal/samsung/exynos_tmu_data.c |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index 073c292..476b768 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -131,8 +131,8 @@ static const struct exynos_tmu_registers 
 exynos4412_tmu_registers = {
  
  #define EXYNOS4412_TMU_DATA \
   .threshold_falling = 10, \
 - .trigger_levels[0] = 85, \
 - .trigger_levels[1] = 103, \
 + .trigger_levels[0] = 70, \
 + .trigger_levels[1] = 95, \
   .trigger_levels[2] = 110, \
   .trigger_levels[3] = 120, \
   .trigger_enable[0] = true, \
 @@ -155,12 +155,12 @@ static const struct exynos_tmu_registers 
 exynos4412_tmu_registers = {
   .second_point_trim = 85, \
   .default_temp_offset = 50, \
   .freq_tab[0] = { \
 - .freq_clip_max = 800 * 1000, \
 - .temp_level = 85, \
 + .freq_clip_max = 1400 * 1000, \
 + .temp_level = 70, \
   }, \
   .freq_tab[1] = { \
 - .freq_clip_max = 200 * 1000, \
 - .temp_level = 103, \
 + .freq_clip_max = 400 * 1000, \
 + .temp_level = 95, \
   }, \
   .freq_tab_count = 2, \
   .registers = exynos4412_tmu_registers, \


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 23/25] thermal: exynos: fix error return code

2014-01-01 Thread Zhang Rui
On Sun, 2013-12-29 at 23:47 +0100, Julia Lawall wrote:
 From: Julia Lawall julia.law...@lip6.fr
 
 Set the return variable to an error code as done elsewhere in the function.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 (
 if@p1 (\(ret  0\|ret != 0\))
  { ... return ret; }
 |
 ret@p1 = 0
 )
 ... when != ret = e1
 when != ret
 *if(...)
 {
   ... when != ret = e2
   when forall
  return ret;
 }
 
 // /smpl
 
 Signed-off-by: Julia Lawall julia.law...@lip6.fr

applied.

thanks,
rui
 
 ---
 Not tested.
 
  drivers/thermal/samsung/exynos_tmu.c |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 32f38b9..0d96a51 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -205,6 +205,7 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
  skip_calib_data:
   if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
   dev_err(pdev-dev, Invalid max trigger level\n);
 + ret = -EINVAL;
   goto out;
   }
  
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] thermal:samsung: fix compilation warning

2014-01-01 Thread Zhang Rui
On Fri, 2013-12-20 at 17:42 +0530, Naveen Krishna Chatradhi wrote:
 This patch fixes a compilation warning.
 
 warning: passing argument 5 of 'thermal_zone_device_register' discards 'const'
 qualifier from pointer target type [enabled by default]
 include/linux/thermal.h:270:29: note: expected 'struct 
 thermal_zone_device_ops *'
 but argument is of type 'const struct thermal_zone_device_ops *'
 
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

applied.

thanks,
rui
 ---
  drivers/thermal/samsung/exynos_thermal_common.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index c2301da..3f5ad25 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -280,7 +280,7 @@ static int exynos_get_trend(struct thermal_zone_device 
 *thermal,
   return 0;
  }
  /* Operation callback functions for thermal zone */
 -static struct thermal_zone_device_ops const exynos_dev_ops = {
 +static struct thermal_zone_device_ops exynos_dev_ops = {
   .bind = exynos_bind,
   .unbind = exynos_unbind,
   .get_temp = exynos_get_temp,


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v12 1/4] thermal: samsung: replace inten_ bit fields with intclr_

2014-01-01 Thread Zhang Rui
On Thu, 2013-12-19 at 11:35 +0530, Naveen Krishna Chatradhi wrote:
 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.nav...@samsung.com
 Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com

Eduardo,

what do you think of this patch set?

thanks,
rui
 ---
 Changes since v11:
 Added Reviewed by Tomasz
 
 Changes since v10:
 None
 
  drivers/thermal/samsung/exynos_tmu.c  |6 +++---
  drivers/thermal/samsung/exynos_tmu.h  |   16 
  drivers/thermal/samsung/exynos_tmu_data.c |   18 +-
  drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
  4 files changed, 22 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 32f38b9..c493245 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -237,7 +237,7 @@ skip_calib_data:
   writeb(pdata-trigger_levels[i], data-base +
   reg-threshold_th0 + i * sizeof(reg-threshold_th0));
  
 - writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
 + writel(reg-intclr_rise_mask, data-base + reg-tmu_intclear);
   } else {
   /* Write temperature code for rising and falling threshold */
   for (i = 0;
 @@ -264,8 +264,8 @@ skip_calib_data:
   writel(falling_threshold,
   data-base + reg-threshold_th1);
  
 - writel((reg-inten_rise_mask  reg-inten_rise_shift) |
 - (reg-inten_fall_mask  reg-inten_fall_shift),
 + writel((reg-intclr_rise_mask  reg-intclr_rise_shift) |
 + (reg-intclr_fall_mask  reg-intclr_fall_shift),
   data-base + reg-tmu_intclear);
  
   /* if last threshold limit is also present */
 diff --git a/drivers/thermal/samsung/exynos_tmu.h 
 b/drivers/thermal/samsung/exynos_tmu.h
 index 3fb6554..980859a 100644
 --- a/drivers/thermal/samsung/exynos_tmu.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -122,10 +122,6 @@ enum soc_type {
   * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
   * @tmu_inten: register containing the different threshold interrupt
   enable bits.
 - * @inten_rise_shift: shift bits of all rising interrupt bits.
 - * @inten_rise_mask: mask bits of all rising interrupt bits.
 - * @inten_fall_shift: shift bits of all rising interrupt bits.
 - * @inten_fall_mask: mask bits of all rising interrupt bits.
   * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
   * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
   * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
 @@ -136,6 +132,10 @@ enum soc_type {
   * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
   * @tmu_intstat: Register containing the interrupt status values.
   * @tmu_intclear: Register for clearing the raised interrupt status.
 + * @intclr_fall_shift: shift bits for interrupt clear fall 0
 + * @intclr_rise_shift: shift bits of all rising interrupt bits.
 + * @intclr_rise_mask: mask bits of all rising interrupt bits.
 + * @intclr_fall_mask: mask bits of all rising interrupt bits.
   * @emul_con: TMU emulation controller register.
   * @emul_temp_shift: shift bits of emulation temperature.
   * @emul_time_shift: shift bits of emulation time.
 @@ -191,10 +191,6 @@ struct exynos_tmu_registers {
   u32 threshold_th3_l0_shift;
  
   u32 tmu_inten;
 - u32 inten_rise_shift;
 - u32 inten_rise_mask;
 - u32 inten_fall_shift;
 - u32 inten_fall_mask;
   u32 inten_rise0_shift;
   u32 inten_rise1_shift;
   u32 inten_rise2_shift;
 @@ -207,6 +203,10 @@ struct exynos_tmu_registers {
   u32 tmu_intstat;
  
   u32 tmu_intclear;
 + u32 intclr_fall_shift;
 + u32 intclr_rise_shift;
 + u32 intclr_fall_mask;
 + u32 intclr_rise_mask;
  
   u32 emul_con;
   u32 emul_temp_shift;
 diff --git 

Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register

2014-01-01 Thread Zhang Rui
On Thu, 2013-11-07 at 18:12 +0530, Naveen Krishna Chatradhi wrote:
 On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
 the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
 should be acompanied by enabling the respective clock.
 
 This patch which allow for a clk_sec clock to be specified in the
 device-tree which will be ungated when accessing the TRIMINFO register.
 
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

Eduardo,

what do you think of this patch?

thanks,
rui
 ---
  drivers/thermal/samsung/exynos_tmu.c |   24 +++-
  1 file changed, 23 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index b54825a..33edd1a 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -47,6 +47,7 @@
   * @irq_work: pointer to the irq work structure.
   * @lock: lock to implement synchronization.
   * @clk: pointer to the clock structure.
 + * @clk_sec: pointer to the clock structure for accessing the base_second.
   * @temp_error1: fused value of the first point trim.
   * @temp_error2: fused value of the second point trim.
   * @regulator: pointer to the TMU regulator structure.
 @@ -61,7 +62,7 @@ struct exynos_tmu_data {
   enum soc_type soc;
   struct work_struct irq_work;
   struct mutex lock;
 - struct clk *clk;
 + struct clk *clk, *clk_sec;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
   struct thermal_sensor_conf *reg_conf;
 @@ -152,6 +153,8 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
  
   mutex_lock(data-lock);
   clk_enable(data-clk);
 + if (!IS_ERR(data-clk_sec))
 + clk_enable(data-clk_sec);
  
   if (TMU_SUPPORTS(pdata, READY_STATUS)) {
   status = readb(data-base + reg-tmu_status);
 @@ -306,6 +309,8 @@ skip_calib_data:
  out:
   clk_disable(data-clk);
   mutex_unlock(data-lock);
 + if (!IS_ERR(data-clk_sec))
 + clk_disable(data-clk_sec);
  
   return ret;
  }
 @@ -457,12 +462,16 @@ static void exynos_tmu_work(struct work_struct *work)
   const struct exynos_tmu_registers *reg = pdata-registers;
   unsigned int val_irq, val_type;
  
 + if (!IS_ERR(data-clk_sec))
 + clk_enable(data-clk_sec);
   /* Find which sensor generated this interrupt */
   if (reg-tmu_irqstatus) {
   val_type = readl(data-base_second + reg-tmu_irqstatus);
   if (!((val_type  data-id)  0x1))
   goto out;
   }
 + if (!IS_ERR(data-clk_sec))
 + clk_disable(data-clk_sec);
  
   exynos_report_trigger(data-reg_conf);
   mutex_lock(data-lock);
 @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   if (ret)
   return ret;
  
 + data-clk_sec = devm_clk_get(pdev-dev, tmu_apbif_sec);
 + if (!IS_ERR(data-clk_sec)) {
 + ret = clk_prepare(data-clk_sec);
 + if (ret) {
 + dev_err(pdev-dev, Failed to get clock\n);
 + return  PTR_ERR(data-clk_sec);
 + }
 + }
 +
   if (pdata-type == SOC_ARCH_EXYNOS4210 ||
   pdata-type == SOC_ARCH_EXYNOS4412 ||
   pdata-type == SOC_ARCH_EXYNOS5250 ||
 @@ -713,6 +731,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   return 0;
  err_clk:
   clk_unprepare(data-clk);
 + if (!IS_ERR(data-clk_sec))
 + clk_unprepare(data-clk_sec);
   return ret;
  }
  
 @@ -725,6 +745,8 @@ static int exynos_tmu_remove(struct platform_device *pdev)
   exynos_unregister_thermal(data-reg_conf);
  
   clk_unprepare(data-clk);
 + if (!IS_ERR(data-clk_sec))
 + clk_unprepare(data-clk_sec);
  
   if (!IS_ERR(data-regulator))
   regulator_disable(data-regulator);


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12

2013-10-13 Thread Zhang, Rui
Eduardo,

What's your opinion on this patch set?
BTW, please send me all the urgent fixes for thermal soc drivers that you think 
should go to 3.12.

Thanks,
rui
 -Original Message-
 From: Lukasz Majewski [mailto:l.majew...@samsung.com]
 Sent: Monday, October 14, 2013 1:47 PM
 To: Zhang, Rui; Eduardo Valentin; kgene@samsung.com
 Cc: Lukasz Majewski; Linux PM list; Lukasz Majewski; linux-kernel;
 Bartlomiej Zolnierkiewicz; devicet...@vger.kernel.org; Amit Daniel
 Kachhap; linux-samsung-soc@vger.kernel.org
 Subject: Re: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12
 Importance: High
 
 Hi Zhang, Eduardo,
 
  This patch series is divided into two parts:
  1. Device tree node definition and enabelement for TMU at Exynos4412
  (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4.
  Several commits were necessary to properly fix regression for TMU
 test
  MUX address setting after reset.
 
  Test HW:
  - Exynos4412 - TRATS2 board (Linux v3.12-rc4)
  SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b
 
 
  Lukasz Majewski (5):
thermal: exynos: Remove check for thermal device pointer at
  exynos_report_trigger()
thermal: exynos: Provide separate TMU data for Exynos4412
thermal: exynos: Provide initial setting for TMU's test MUX address
  at Exynos4412
ARM: dts: exynos4x12: Device tree node definition for TMU on
  Exynos4x12
ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
 
 
 Zhang, Eduardo - any comments?
 
 Would it be possible to add them to v3.12 since they do fix critical
 error and regression on Exynos4412.
 
 
   arch/arm/boot/dts/exynos4412-trats2.dts |5 
   arch/arm/boot/dts/exynos4x12.dtsi   |   10 
   drivers/thermal/samsung/exynos_thermal_common.c |2 --
   drivers/thermal/samsung/exynos_tmu.c|   12 ++---
   drivers/thermal/samsung/exynos_tmu.h|7 +-
   drivers/thermal/samsung/exynos_tmu_data.c   |   30
  ++-
  drivers/thermal/samsung/exynos_tmu_data.h   |   13 +- 7
  files changed, 65 insertions(+), 14 deletions(-)
 
 
 
 
 --
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional

2013-08-27 Thread Zhang Rui
On 二, 2013-08-27 at 23:17 +0200, Rafael J. Wysocki wrote:
 On Tuesday, August 27, 2013 02:26:41 PM Eduardo Valentin wrote:
  On 23-08-2013 19:08, Rafael J. Wysocki wrote:
   On Friday, August 23, 2013 06:03:14 PM Eduardo Valentin wrote:
   When registering a new thermal_device, the thermal framework
   will always add a hwmon sysfs interface.
  
   This patch adds a flag to make this behavior optional. Now
   when registering a new thermal device, the caller needs
   to say if the hwmon interface is required.
  
   In order to keep same behavior as of today, all current
   calls will by default create the hwmon interface.
   
   Well, instead of modifying all of the callers this way, why don't
   you add new versions taking the additional argument as, for example,
   
   thermal_zone_device_register_full()
   
   and redefine the old ones as static inline wrappers, for example
   
   static inline struct thermal_zone_device 
   *thermal_zone_device_register(args)
   {
 return thermal_zone_device_register_full(args, true);
   }
   
   ?
  
  Yeah, that is another way to go and I thought of doing it like that. I
  just could not come out with a good API naming:
  
  thermal_zone_device_register_full(all args)
  
  thermal_zone_device_register(args) /* on hwmon == true */
  thermal_zone_device_register_no_hwmon(args) /* on hwmon == false */
  
  Would this sound reasonable naming?
 
 Yeah, sounds good to me.
 
Well, actually, Tianyu is working on a patch set to move all the
thermal_zone_device_register() parameters to struct thermal_zone_params.

But with that patch set done, what you need to do next is just to
introduce a new field in struct thermal_zone_params and make sure 0
means registering hwmon sysfs I/F.

thanks,
rui

 Thanks,
 Rafael
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] thermal: exynos_tmu: fix wrong error check for mapped memory

2013-08-15 Thread Zhang Rui
On 三, 2013-08-07 at 14:01 +0530, Naveen Krishna Chatradhi wrote:
 The error check is checking for a base mapped memory base
 instead of base_common. Fixing the same.
 
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

applied. Thanks!
BTW, can you rebase the other three exynos patches you submitted?

thanks,
rui
 ---
  drivers/thermal/samsung/exynos_tmu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index ec01dfe..a033dbb 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -592,7 +592,7 @@ static int exynos_map_dt_data(struct platform_device 
 *pdev)
  
   data-base_common = devm_ioremap(pdev-dev, res.start,
   resource_size(res));
 - if (!data-base) {
 + if (!data-base_common) {
   dev_err(pdev-dev, Failed to ioremap memory\n);
   return -ENOMEM;
   }


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH V7 00/30] thermal: exynos: Re-structure driver and add support for exynos5440

2013-06-27 Thread Zhang, Rui


 -Original Message-
 From: amit.kach...@gmail.com [mailto:amit.kach...@gmail.com] On Behalf
 Of amit daniel kachhap
 Sent: Friday, June 28, 2013 1:20 PM
 To: Zhang, Rui
 Cc: Eduardo Valentin; Kukjin Kim; linux...@vger.kernel.org; linux-
 samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: Re: [PATCH V7 00/30] thermal: exynos: Re-structure driver and
 add support for exynos5440
 Importance: High
 
 On Tue, Jun 25, 2013 at 5:23 PM, amit daniel kachhap
 amit.dan...@samsung.com wrote:
  On Tue, Jun 25, 2013 at 1:21 AM, Eduardo Valentin
  eduardo.valen...@ti.com wrote:
  On 24-06-2013 13:13, Kukjin Kim wrote:
  On 06/24/13 19:50, Amit Daniel Kachhap wrote:
  Submitting V7 version with all comments fixed. Most of the patches
  are acked by Eduardo. All the un-acked patches are modified
  according to the review comments.
  If any comments please let me know.
 
  Thanks,
  Amit Daniel
 
  Changes in V7:
  * Fixed all the coding guidelines comments given by Eduardo.
  * Moved the request irq call below the core thermal registration
 as
  per discussion
 with Eduardo.
  * Appropriate logs/TODO's/comments added for some review comments
  which are still
 same as before,
 1) calibration register setting still uses enums.
 2) very few soc check's still left in the driver.
 3) Cooling devices stored in an array in the exynos core
 thermal
  layer.
 
  Changes in V6:
  * Uses ARCH_HAS_BANDGAP config flag which is merged now in arm
 tree.
 
 (http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7758/1).
  * In this version patches 1, 2, 3, 4 and 30 are modified. Others
  are same as V5.
  * Added acked by from Jonghwa Lee.
  * Rebased against Thermal Maintainer next tree.
 
  Changes in V5:
  * Most of the changes in this version is as per suggestion from
  Jonghwa Lee. I
have retained one to one mapping of platform data with TMU
  instances as the
TMU's are different devices. In exynos5440 soc there is some
 register
sharing across multiple TMU's but in exynos5420 there is no
  register between
multiple TMU's, so the current implementation is useful to
  support both of the
above.
This patch uses localized ARCH_HAS_TMU Kconfig option and is a
  temporary solution
until a more generic macro ARCH_HAS_BANDGAP is introduced as per
  discussion in
the link https://patchwork.kernel.org/patch/2659001/.
  * trip type is passed as platform data.
  * HW trip is allowed only for maximum level.
  * Platform data structure is now abstracted inside 1 more
 structure
  to support
 multiple sensor TMU data.
 
  Changes in V4:
Almost all the changes in this version is as per suggestion from
  Eduardo.The
major ones are listed below,
  * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by
  platform. With
 this change existing symbol EXYNOS_TMU_DATA is not needed.
  * Movement of freq_clip_table from exynos_tmu.h to
  exynos_thermal_common.h is
 explained in the commit logs.
  * Wrote all register description documentation.
  * Split 5440 TMU support patch into controller change,
  configuration data and
 feature addition patches.
  * Remove all *LINUX_* in the header files.
  * Still regulator enable is kept optional but a TODO: comment is
  added to fix
 it later.
 
  Changes in V3:
  * Added proper dependency of different exynos thermal Kconfig
 symbols.
  Basically 3
Kconfig can be enabled now and corresponds to tmu driver. exynos
  common part
and exynos configuration data. This issue was raised by Rui
 Zhang.
 
  Changes in V2:
  * Separated SOC data from TMU driver. This is as per suggestion
  from Eduardo.
  * Merged the new file created for exynos5440 TMU controller with
  the existing
TMU controller code.
  * Removed the DT parsing code as now the SOC specific data are
  cleanly put
inside the data specific file.
  * Even the register definations/bitfields are treated as data as
 there is
some variation across SOC's.
 
  This patchset adds TMU(Thermal management Unit) driver support for
  exynos5440 platform. There are 3 instances of the TMU controllers
  so necessary cleanup/re-structure is done to handle multiple
 thermal zone.
 
  Patch (exynos4: Add documentation for Exynos SoC thermal bindings)
  from Lukasz Majewski is already posted to mainline. Using it as it
 is needed.
  (http://www.mail-archive.com/linux-samsung-
 s...@vger.kernel.org/msg1
  7817.html)
 
 
  Patch (thermal: exynos: Support thermal tripping ) from Jonghwan
  Choi is added here with some changes.
  (https://patchwork.kernel.org/patch/1668371/)
 
  Patch (thermal: exynos: Support for TMU regulator defined at
 device
  tree) is a repost of my earlier
  patch(https://patchwork-mail1.kernel.org/patch/2510771/)
  and adds regulator support.
 
  Patch (ARM: dts: Add device tree node for exynos5440 TMU
  controller) and patch (arm: exynos: enable ARCH_HAS_BANDGAP) can
 be
  merged through exynos platform

Re: [PATCH V3 02/21] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

2013-05-07 Thread Zhang Rui
On Tue, 2013-05-07 at 18:30 +0530, Amit Daniel Kachhap wrote:
 This code bifurcates exynos thermal implementation into common and sensor
 specific parts. The common thermal code interacts with core thermal layer and
 core cpufreq cooling parts and is independent of SOC specific driver. This
 change is needed to cleanly add support for new TMU sensors.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/Kconfig |   20 +-
  drivers/thermal/samsung/Makefile|4 +-
  drivers/thermal/samsung/exynos_thermal.c|  421 
 +--
  drivers/thermal/samsung/exynos_thermal_common.c |  389 +
  drivers/thermal/samsung/exynos_thermal_common.h |   83 +
  5 files changed, 498 insertions(+), 419 deletions(-)
  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
 
 diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
 index 2d3d9dc..7857e20 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -1,9 +1,17 @@
  config EXYNOS_THERMAL
 - tristate Temperature sensor on Samsung EXYNOS
 + tristate Exynos thermal management unit driver
   depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
 - depends on CPU_THERMAL
   help
 -   If you say yes here you get support for TMU (Thermal Management
 -   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
 -   the exynos thermal driver with the core thermal layer and cpu
 -   cooling API's.
 +   If you say yes here you get support for the exynos thermal driver
 +   for exynos4 and exynos5 soc. This driver initialises the TMU, reports
 +   temperature and handles cooling action if defined. This driver uses
 +   core thermal API's.
 +
 +config EXYNOS_THERMAL_CORE
 + bool Core thermal framework support for EXYNOS SOC's
 + depends on EXYNOS_THERMAL
 + help
 +   If you say yes here you get support for EXYNOS TMU
 +   (Thermal Management Unit) common registration/unregistration
 +   functions to the core thermal layer and also to use the generic
 +   cpu cooling API's.

I'm still not quite clear what you want to get there.
If EXYNOS_THERMAL=y and EXYNOS_THERMAL_CORE=n, you'll get an Exynos tmu
driver which is not shown in /sys/class/thermal/ and can not be used for
thermal management?

thanks,
rui
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index 1fe6d93..6227d4f 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -1,4 +1,6 @@
  #
  # Samsung thermal specific Makefile
  #
 -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
 +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_soc_thermal.o
 +exynos_soc_thermal-y := exynos_thermal.o
 +exynos_soc_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
 diff --git a/drivers/thermal/samsung/exynos_thermal.c 
 b/drivers/thermal/samsung/exynos_thermal.c
 index d20ce9e..4c85945 100644
 --- a/drivers/thermal/samsung/exynos_thermal.c
 +++ b/drivers/thermal/samsung/exynos_thermal.c
 @@ -21,23 +21,19 @@
   *
   */
  
 -#include linux/module.h
 -#include linux/err.h
 -#include linux/kernel.h
 -#include linux/slab.h
 -#include linux/platform_device.h
 -#include linux/interrupt.h
  #include linux/clk.h
 -#include linux/workqueue.h
 -#include linux/sysfs.h
 -#include linux/kobject.h
  #include linux/io.h
 +#include linux/interrupt.h
 +#include linux/kernel.h
 +#include linux/kobject.h
 +#include linux/module.h
  #include linux/mutex.h
 -#include linux/platform_data/exynos_thermal.h
 -#include linux/thermal.h
 -#include linux/cpufreq.h
 -#include linux/cpu_cooling.h
  #include linux/of.h
 +#include linux/platform_device.h
 +#include linux/platform_data/exynos_thermal.h
 +#include linux/slab.h
 +#include linux/workqueue.h
 +#include exynos_thermal_common.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -88,16 +84,6 @@
  #define EFUSE_MIN_VALUE 40
  #define EFUSE_MAX_VALUE 100
  
 -/* In-kernel thermal framework related macros  definations */
 -#define SENSOR_NAME_LEN  16
 -#define MAX_TRIP_COUNT   8
 -#define MAX_COOLING_DEVICE 4
 -#define MAX_THRESHOLD_LEVS 4
 -
 -#define ACTIVE_INTERVAL 500
 -#define IDLE_INTERVAL 1
 -#define MCELSIUS 1000
 -
  #ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME 0x57F0
  #define EXYNOS_EMUL_TIME_SHIFT   16
 @@ -106,17 +92,6 @@
  #define EXYNOS_EMUL_ENABLE   0x1
  #endif /* CONFIG_THERMAL_EMULATION */
  
 -/* CPU Zone information */
 -#define PANIC_ZONE  4
 -#define WARN_ZONE   3
 -#define MONITOR_ZONE2
 -#define SAFE_ZONE   1
 -
 -#define GET_ZONE(trip) (trip + 2)
 -#define GET_TRIP(zone) (zone - 2)
 -
 -#define EXYNOS_ZONE_COUNT3
 -
  

Re: [PATCH V2 01/20] thermal: exynos: Moving exynos thermal files into samsung directory

2013-05-06 Thread Zhang Rui
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
 This movement of files is done for easy maintenance and adding more
 new sensor's support for exynos platform easily . This will also help in
 bifurcating exynos common, sensor driver and sensor data related parts.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/Kconfig|   13 +
  drivers/thermal/Makefile   |2 +-
  drivers/thermal/samsung/Kconfig|9 +
  drivers/thermal/samsung/Makefile   |4 
  drivers/thermal/{ = samsung}/exynos_thermal.c |0
  5 files changed, 19 insertions(+), 9 deletions(-)
  create mode 100644 drivers/thermal/samsung/Kconfig
  create mode 100644 drivers/thermal/samsung/Makefile
  rename drivers/thermal/{ = samsung}/exynos_thermal.c (100%)
 
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index 5e3c025..081ddc5 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -114,14 +114,6 @@ config KIRKWOOD_THERMAL
 Support for the Kirkwood thermal sensor driver into the Linux thermal
 framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
  
 -config EXYNOS_THERMAL
 - tristate Temperature sensor on Samsung EXYNOS
 - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
 - depends on CPU_THERMAL
 - help
 -   If you say yes here you get support for TMU (Thermal Management
 -   Unit) on SAMSUNG EXYNOS series of SoC.
 -
  config DOVE_THERMAL
   tristate Temperature sensor on Marvell Dove SoCs
   depends on ARCH_DOVE
 @@ -169,4 +161,9 @@ config INTEL_POWERCLAMP
 enforce idle time which results in more package C-state residency. The
 user interface is exposed via generic thermal framework.
  
 +menu Exynos thermal drivers

would it be more proper to use Samsung thermal drivers or Samsung
Exynos thermal drivers instead?

 +depends on PLAT_SAMSUNG
 +source drivers/thermal/samsung/Kconfig
 +endmenu
 +
sorry I know few about arm,
could you tell me the difference between
CONFIG_ARCH_EXYNOS4/CONFIG_ARCH_EXYNOS5 and CONFIG_PLAT_SAMSUNG please,
I do not see the dependency between these in Kconfig file?

thanks,
rui
  endif
 diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
 index c054d41..b3063a9 100644
 --- a/drivers/thermal/Makefile
 +++ b/drivers/thermal/Makefile
 @@ -17,7 +17,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL)   += cpu_cooling.o
  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
  obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
  obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
 +obj-y+= samsung/
  obj-$(CONFIG_DOVE_THERMAL)   += dove_thermal.o
  obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
  obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
 diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
 new file mode 100644
 index 000..2d3d9dc
 --- /dev/null
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -0,0 +1,9 @@
 +config EXYNOS_THERMAL
 + tristate Temperature sensor on Samsung EXYNOS
 + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
 + depends on CPU_THERMAL
 + help
 +   If you say yes here you get support for TMU (Thermal Management
 +   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
 +   the exynos thermal driver with the core thermal layer and cpu
 +   cooling API's.
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 new file mode 100644
 index 000..1fe6d93
 --- /dev/null
 +++ b/drivers/thermal/samsung/Makefile
 @@ -0,0 +1,4 @@
 +#
 +# Samsung thermal specific Makefile
 +#
 +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/samsung/exynos_thermal.c
 similarity index 100%
 rename from drivers/thermal/exynos_thermal.c
 rename to drivers/thermal/samsung/exynos_thermal.c


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 02/20] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

2013-05-06 Thread Zhang Rui
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
 This code bifurcates exynos thermal implementation into common and sensor
 specific parts. The common thermal code interacts with core thermal layer and
 core cpufreq cooling parts and is independent of SOC specific driver. This
 change is needed to cleanly add support for new TMU sensors.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/Kconfig |   26 +-
  drivers/thermal/samsung/Makefile|4 +-
  drivers/thermal/samsung/exynos_thermal.c|  421 
 +--
  drivers/thermal/samsung/exynos_thermal_common.c |  389 +
  drivers/thermal/samsung/exynos_thermal_common.h |   71 
  5 files changed, 491 insertions(+), 420 deletions(-)
  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
 
 diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
 index 2d3d9dc..1e3ba31 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -1,9 +1,21 @@
 -config EXYNOS_THERMAL
 - tristate Temperature sensor on Samsung EXYNOS
 +config EXYNOS_COMMON

EXYNOS_COMMON is misleading here, better use EXYNOS_THERMAL_COMMON?

 + bool Common thermal support for EXYNOS SOC's
   depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
 - depends on CPU_THERMAL
   help
 -   If you say yes here you get support for TMU (Thermal Management
 -   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
 -   the exynos thermal driver with the core thermal layer and cpu
 -   cooling API's.
 +   If you say yes here you get support for EXYNOS TMU
 +   (Thermal Management Unit) common registration/unregistration
 +   functions to the core thermal layer and also to use the generic
 +   cpu cooling API's.
 +
 +if EXYNOS_COMMON
 +
 +config EXYNOS_SOC_THERMAL
 + tristate Temperature sensor on Samsung EXYNOS series SOC
 + depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || 
 SOC_EXYNOS5250)
 + help
 +   If you say yes here you can enable TMU (Thermal Management Unit) on
 +   SAMSUNG EXYNOS 4210, 4412, 4414 and 5250 series of SoC. This option
 +   initialises the TMU controller and registers/unregisters with exynos
 +   common thermal layer.
 +
 +endif
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index 1fe6d93..fcda5b4 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -1,4 +1,6 @@
  #
  # Samsung thermal specific Makefile
  #
 -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
 +obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o
 +exynos_soc_thermal-y := exynos_thermal.o
 +exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON)   += exynos_thermal_common.o

the Makefile suggests that exynos_soc_thermal driver could be built
without CONFIG_EXYNOS_COMMON.
But the Kconfig file shows that exynos_soc_thermal depends on
CONFIG_EXYNOS_COMMON.
If exynos_thermal_common.c contains the code to interact with the
generic thermal layer and you do not want a soc driver without thermal
support, just remove CONFIG_EXYNOS_COMMON and always build it into
exynos_soc_thermal.o.
what do you think?
 
thanks,
rui
 diff --git a/drivers/thermal/samsung/exynos_thermal.c 
 b/drivers/thermal/samsung/exynos_thermal.c
 index d20ce9e..4c85945 100644
 --- a/drivers/thermal/samsung/exynos_thermal.c
 +++ b/drivers/thermal/samsung/exynos_thermal.c
 @@ -21,23 +21,19 @@
   *
   */
  
 -#include linux/module.h
 -#include linux/err.h
 -#include linux/kernel.h
 -#include linux/slab.h
 -#include linux/platform_device.h
 -#include linux/interrupt.h
  #include linux/clk.h
 -#include linux/workqueue.h
 -#include linux/sysfs.h
 -#include linux/kobject.h
  #include linux/io.h
 +#include linux/interrupt.h
 +#include linux/kernel.h
 +#include linux/kobject.h
 +#include linux/module.h
  #include linux/mutex.h
 -#include linux/platform_data/exynos_thermal.h
 -#include linux/thermal.h
 -#include linux/cpufreq.h
 -#include linux/cpu_cooling.h
  #include linux/of.h
 +#include linux/platform_device.h
 +#include linux/platform_data/exynos_thermal.h
 +#include linux/slab.h
 +#include linux/workqueue.h
 +#include exynos_thermal_common.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -88,16 +84,6 @@
  #define EFUSE_MIN_VALUE 40
  #define EFUSE_MAX_VALUE 100
  
 -/* In-kernel thermal framework related macros  definations */
 -#define SENSOR_NAME_LEN  16
 -#define MAX_TRIP_COUNT   8
 -#define MAX_COOLING_DEVICE 4
 -#define MAX_THRESHOLD_LEVS 4
 -
 -#define ACTIVE_INTERVAL 500
 -#define IDLE_INTERVAL 1
 -#define MCELSIUS 1000
 -
  #ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME 0x57F0
  

Re: [PATCH V2 03/20] thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c

2013-05-06 Thread Zhang Rui
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
 This patch renames exynos_thermal.c to exynos_tmu.c. This change is needed as
 this file now just contains exynos tmu driver related codes and thermal zone
 or cpufreq cooling registration related changes are not there anymore.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

This one looks okay to me.

thanks,
rui
 ---
  drivers/thermal/samsung/Makefile   |2 +-
  .../samsung/{exynos_thermal.c = exynos_tmu.c} |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
  rename drivers/thermal/samsung/{exynos_thermal.c = exynos_tmu.c} (99%)
 
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index fcda5b4..75e1f97 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -2,5 +2,5 @@
  # Samsung thermal specific Makefile
  #
  obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o
 -exynos_soc_thermal-y := exynos_thermal.o
 +exynos_soc_thermal-y := exynos_tmu.o
  exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON)   += exynos_thermal_common.o
 diff --git a/drivers/thermal/samsung/exynos_thermal.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 similarity index 99%
 rename from drivers/thermal/samsung/exynos_thermal.c
 rename to drivers/thermal/samsung/exynos_tmu.c
 index 4c85945..3de3e61 100644
 --- a/drivers/thermal/samsung/exynos_thermal.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -1,5 +1,5 @@
  /*
 - * exynos_thermal.c - Samsung EXYNOS TMU (Thermal Management Unit)
 + * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
   *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 05/20] thermal: exynos: Bifurcate exynos tmu driver and configuration data

2013-05-06 Thread Zhang Rui
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
 This code splits the exynos tmu driver code into SOC specific data parts.
 This will simplify adding new SOC specific data to the same TMU controller.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

I'm okay with all the rest patches in this patch series.

thanks,
rui
 ---
  drivers/thermal/samsung/Makefile|1 +
  drivers/thermal/samsung/exynos_thermal_common.h |2 +-
  drivers/thermal/samsung/exynos_tmu.c|   67 +--
  drivers/thermal/samsung/exynos_tmu_data.c   |   78 
 +++
  drivers/thermal/samsung/exynos_tmu_data.h   |   40 
  5 files changed, 124 insertions(+), 64 deletions(-)
  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.h
 
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index 75e1f97..b133255 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,4 +3,5 @@
  #
  obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o
  exynos_soc_thermal-y := exynos_tmu.o
 +exynos_soc_thermal-y += exynos_tmu_data.o
  exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON)   += exynos_thermal_common.o
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index 985b848..6ed9bd9 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -62,7 +62,7 @@ struct freq_clip_table {
  struct   thermal_trip_point_conf {
   int trip_val[MAX_TRIP_COUNT];
   int trip_count;
 - u8 trigger_falling;
 + unsigned char trigger_falling;
  };
  
  struct   thermal_cooling_conf {
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index a02f2c9..05b5068 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -34,6 +34,7 @@
  #include linux/workqueue.h
  #include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include exynos_tmu_data.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -385,66 +386,6 @@ static struct thermal_sensor_conf exynos_sensor_conf = {
   .write_emul_temp= exynos_tmu_set_emulation,
  };
  
 -#if defined(CONFIG_CPU_EXYNOS4210)
 -static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
 - .threshold = 80,
 - .trigger_levels[0] = 5,
 - .trigger_levels[1] = 20,
 - .trigger_levels[2] = 30,
 - .trigger_level0_en = 1,
 - .trigger_level1_en = 1,
 - .trigger_level2_en = 1,
 - .trigger_level3_en = 0,
 - .gain = 15,
 - .reference_voltage = 7,
 - .cal_type = TYPE_ONE_POINT_TRIMMING,
 - .freq_tab[0] = {
 - .freq_clip_max = 800 * 1000,
 - .temp_level = 85,
 - },
 - .freq_tab[1] = {
 - .freq_clip_max = 200 * 1000,
 - .temp_level = 100,
 - },
 - .freq_tab_count = 2,
 - .type = SOC_ARCH_EXYNOS4210,
 -};
 -#define EXYNOS4210_TMU_DRV_DATA (exynos4210_default_tmu_data)
 -#else
 -#define EXYNOS4210_TMU_DRV_DATA (NULL)
 -#endif
 -
 -#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
 -static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
 - .threshold_falling = 10,
 - .trigger_levels[0] = 85,
 - .trigger_levels[1] = 103,
 - .trigger_levels[2] = 110,
 - .trigger_level0_en = 1,
 - .trigger_level1_en = 1,
 - .trigger_level2_en = 1,
 - .trigger_level3_en = 0,
 - .gain = 8,
 - .reference_voltage = 16,
 - .noise_cancel_mode = 4,
 - .cal_type = TYPE_ONE_POINT_TRIMMING,
 - .efuse_value = 55,
 - .freq_tab[0] = {
 - .freq_clip_max = 800 * 1000,
 - .temp_level = 85,
 - },
 - .freq_tab[1] = {
 - .freq_clip_max = 200 * 1000,
 - .temp_level = 103,
 - },
 - .freq_tab_count = 2,
 - .type = SOC_ARCH_EXYNOS,
 -};
 -#define EXYNOS_TMU_DRV_DATA (exynos_default_tmu_data)
 -#else
 -#define EXYNOS_TMU_DRV_DATA (NULL)
 -#endif
 -
  #ifdef CONFIG_OF
  static const struct of_device_id exynos_tmu_match[] = {
   {
 @@ -453,11 +394,11 @@ static const struct of_device_id exynos_tmu_match[] = {
   },
   {
   .compatible = samsung,exynos4412-tmu,
 - .data = (void *)EXYNOS_TMU_DRV_DATA,
 + .data = (void *)EXYNOS5250_TMU_DRV_DATA,
   },
   {
   .compatible = samsung,exynos5250-tmu,
 - .data = (void *)EXYNOS_TMU_DRV_DATA,
 + .data = (void *)EXYNOS5250_TMU_DRV_DATA,
   },
   {},
  };
 @@ -471,7 +412,7 @@ static struct platform_device_id exynos_tmu_driver_ids[] 
 = {
   },
   {
 

Re: [PATCH v2 2/4] Thermal: exynos: Support for TMU regulator defined at device tree

2013-04-26 Thread Zhang Rui
Hi, all,

what is the status now?
which one is preferred, this one or the one from Amit's patch set?

thanks,
rui


On Thu, 2013-04-25 at 18:29 +0200, Lukasz Majewski wrote:
 Hi Eduardo,
 
  Amit, Lukasz,
  
  On 25-04-2013 09:29, Lukasz Majewski wrote:
   Hi Amit,

   Hi Lukasz Majewski,
  
   Sorry for late review but I am currently working on restructuring
   the whole exynos thermal driver and this support of LDO can be
   added as feature as not all socs support this. This is also
   suggested by Eduardo. All your other patches looks fine.  
  
   But this is how it is already done. The VDD_TS is optional, so
   Exynos5440 and Exynos4210 will not be broken.
  
   This shall preserve the correct behavior of the thermal driver.

  
  If you guys plan to move to feature based approach, like suggested in 
  V1, then Id recommend adding a /* TODO: */ entry in your driver.
 
 Ok, nice idea.
 
  
  Amit, are you including this LDO support on your rework?
 
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 14/30] thermal/exynos: remove unnecessary header inclusions

2013-04-11 Thread Zhang Rui
On Wed, 2013-04-10 at 21:19 -0400, Eduardo Valentin wrote:
 Rui, Arnd,
 
 As agreed in [1], I will be helping on the thermal maintenance.
 
 On 10-04-2013 20:04, Arnd Bergmann wrote:
  In multiplatform configurations, we cannot include headers
  provided by only the exynos platform. Fortunately a number
  of drivers that include those headers do not actually need
  them, so we can just remove the inclusions.
 
  Signed-off-by: Arnd Bergmann a...@arndb.de
  Cc: linux...@vger.kernel.org
  Cc: Zhang Rui rui.zh...@intel.com
 
 This patch looks good to me.
 
 You can add my:
 Acked-by: Eduardo Valentin eduardo.valen...@ti.com
 
applied to thermal thermal branch.

thanks,
rui
 
 [1] - http://marc.info/?l=linux-pmm=136560509922173w=2


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] thermal: exynos: fix handling of invalid frequency table entries

2013-04-09 Thread Zhang Rui
Hi, Andrew,

can you please verify
commit  fc35b35cbe24ef021ea9acfba21e54da958df747
commit 57df8106932b57427df1eaaa13871857f75b1194
at
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/log/?h=thermal
fixes the problem for you?

thanks,
rui 

On Tue, 2013-04-09 at 14:59 -0700, Andrew Bresticker wrote:
 Similar to the error described in thermal: cpu_cooling: fix handling
 of invalid frequency table entries, exynos_get_frequency_level() will
 enter an infinite loop if any CPU frequency table entries are invalid.
 This patch fixes the handling of invalid frequency entries so that
 there is no infinite loop and the correct level is returned.
 
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 ---
  drivers/thermal/exynos_thermal.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/exynos_thermal.c
 index d5e6267..524b2a0 100644
 --- a/drivers/thermal/exynos_thermal.c
 +++ b/drivers/thermal/exynos_thermal.c
 @@ -237,7 +237,7 @@ static int exynos_get_crit_temp(struct 
 thermal_zone_device *thermal,
  
  static int exynos_get_frequency_level(unsigned int cpu, unsigned int freq)
  {
 - int i = 0, ret = -EINVAL;
 + int i, level = 0, ret = -EINVAL;
   struct cpufreq_frequency_table *table = NULL;
  #ifdef CONFIG_CPU_FREQ
   table = cpufreq_frequency_get_table(cpu);
 @@ -245,12 +245,12 @@ static int exynos_get_frequency_level(unsigned int cpu, 
 unsigned int freq)
   if (!table)
   return ret;
  
 - while (table[i].frequency != CPUFREQ_TABLE_END) {
 + for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
   if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
   continue;
   if (table[i].frequency == freq)
 - return i;
 - i++;
 + return level;
 + level++;
   }
   return ret;
  }


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V3 1/2] Thermal: exynos: Add support for temperature falling interrupt.

2013-02-19 Thread Zhang Rui
On Thu, 2013-02-07 at 17:13 -0800, Amit Daniel Kachhap wrote:
 From: Jonghwa Lee jonghwa3@samsung.com
 
 This patch introduces using temperature falling interrupt in exynos
 thermal driver. Former patch, it only use polling way to check
 whether if system themperature is fallen. However, exynos SOC also
 provides temperature falling interrupt way to do same things by hw.
 This feature is not supported in exynos4210.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

applied to thermal -next.

thanks,
rui
 ---
 Hi,
 
 Submitting these patches again as they got lost somewhere and was not merged.
 
 Changes since V2:
 * Rebased against Rui Zhang next tree.
 * Added Kukjin Kim acked by.
 
 Changes since V1: Used the new thermal trend type macro
 
 All these patches are based on thermal maintainer next branch.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git thermal
 
  drivers/thermal/exynos_thermal.c |   81 
 +++---
  include/linux/platform_data/exynos_thermal.h |3 +
  2 files changed, 49 insertions(+), 35 deletions(-)
 
 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/exynos_thermal.c
 index 3a1b01e..65f69cf 100644
 --- a/drivers/thermal/exynos_thermal.c
 +++ b/drivers/thermal/exynos_thermal.c
 @@ -94,6 +94,7 @@
  #define SENSOR_NAME_LEN  16
  #define MAX_TRIP_COUNT   8
  #define MAX_COOLING_DEVICE 4
 +#define MAX_THRESHOLD_LEVS 4
  
  #define ACTIVE_INTERVAL 500
  #define IDLE_INTERVAL 1
 @@ -133,6 +134,7 @@ struct exynos_tmu_data {
  struct   thermal_trip_point_conf {
   int trip_val[MAX_TRIP_COUNT];
   int trip_count;
 + u8 trigger_falling;
  };
  
  struct   thermal_cooling_conf {
 @@ -183,7 +185,8 @@ static int exynos_set_mode(struct thermal_zone_device 
 *thermal,
  
   mutex_lock(th_zone-therm_dev-lock);
  
 - if (mode == THERMAL_DEVICE_ENABLED)
 + if (mode == THERMAL_DEVICE_ENABLED 
 + !th_zone-sensor_conf-trip_data.trigger_falling)
   th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
   else
   th_zone-therm_dev-polling_delay = 0;
 @@ -447,7 +450,8 @@ static void exynos_report_trigger(void)
   break;
   }
  
 - if (th_zone-mode == THERMAL_DEVICE_ENABLED) {
 + if (th_zone-mode == THERMAL_DEVICE_ENABLED 
 + !th_zone-sensor_conf-trip_data.trigger_falling) {
   if (i  0)
   th_zone-therm_dev-polling_delay = ACTIVE_INTERVAL;
   else
 @@ -486,7 +490,8 @@ static int exynos_register_thermal(struct 
 thermal_sensor_conf *sensor_conf)
  
   th_zone-therm_dev = thermal_zone_device_register(sensor_conf-name,
   EXYNOS_ZONE_COUNT, 0, NULL, exynos_dev_ops, NULL, 0,
 - IDLE_INTERVAL);
 + sensor_conf-trip_data.trigger_falling ?
 + 0 : IDLE_INTERVAL);
  
   if (IS_ERR(th_zone-therm_dev)) {
   pr_err(Failed to register thermal zone device\n);
 @@ -593,8 +598,9 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
  {
   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
   struct exynos_tmu_platform_data *pdata = data-pdata;
 - unsigned int status, trim_info, rising_threshold;
 - int ret = 0, threshold_code;
 + unsigned int status, trim_info;
 + unsigned int rising_threshold = 0, falling_threshold = 0;
 + int ret = 0, threshold_code, i, trigger_levs = 0;
  
   mutex_lock(data-lock);
   clk_enable(data-clk);
 @@ -619,6 +625,11 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   (data-temp_error2 != 0))
   data-temp_error1 = pdata-efuse_value;
  
 + /* Count trigger levels to be enabled */
 + for (i = 0; i  MAX_THRESHOLD_LEVS; i++)
 + if (pdata-trigger_levels[i])
 + trigger_levs++;
 +
   if (data-soc == SOC_ARCH_EXYNOS4210) {
   /* Write temperature code for threshold */
   threshold_code = temp_to_code(data, pdata-threshold);
 @@ -628,44 +639,38 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   }
   writeb(threshold_code,
   data-base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
 -
 - writeb(pdata-trigger_levels[0],
 - data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL0);
 - writeb(pdata-trigger_levels[1],
 - data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL1);
 - writeb(pdata-trigger_levels[2],
 - data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL2);
 - writeb(pdata-trigger_levels[3],
 - data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL3);
 + for (i = 0; i  trigger_levs; i++)
 + writeb(pdata-trigger_levels[i],
 +  

Re: [PATCH V3 2/2] thermal: exynos: Use the new thermal trend type for quick cooling action.

2013-02-19 Thread Zhang Rui
On Thu, 2013-02-07 at 17:13 -0800, Amit Daniel Kachhap wrote:
 This patch uses the quick thermal cooling trend type macros. This is needed
 as exynos5 and other thermal sensors now supports only interrupt method for
 thresold temperature check.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

applied to thermal -next.

thanks,
rui
 ---
 
 Hi,
 
 Submitting these patches again as they got lost somewhere and was not merged.
 
 Changes since V2:
 * Rebased against Rui Zhang next tree.
 * Added Kukjin Kim acked by.
 
 All these patches are based on thermal maintainer next branch.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git thermal
 
  drivers/thermal/exynos_thermal.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/exynos_thermal.c
 index 65f69cf..030bba3 100644
 --- a/drivers/thermal/exynos_thermal.c
 +++ b/drivers/thermal/exynos_thermal.c
 @@ -296,7 +296,7 @@ static int exynos_bind(struct thermal_zone_device 
 *thermal,
   case MONITOR_ZONE:
   case WARN_ZONE:
   if (thermal_zone_bind_cooling_device(thermal, i, cdev,
 - level, level)) {
 + level, 0)) {
   pr_err(error binding cdev inst %d\n, i);
   ret = -EINVAL;
   }
 @@ -399,9 +399,9 @@ static int exynos_get_trend(struct thermal_zone_device 
 *thermal,
   return ret;
  
   if (thermal-temperature = trip_temp)
 - *trend = THERMAL_TREND_RAISING;
 + *trend = THERMAL_TREND_RAISE_FULL;
   else
 - *trend = THERMAL_TREND_DROPPING;
 + *trend = THERMAL_TREND_DROP_FULL;
  
   return 0;
  }


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support

2013-02-07 Thread Zhang Rui
On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
 On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
  This removes the driver specific sysfs support of the temperature
  emulation and uses the newly added core thermal framework for thermal
  emulation. A platform specific handler is added to support this.
  
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
  Acked-by: Kukjin Kim kgene@samsung.com
  ---
  Changes in V2:
  * Added config option CONFIG_THERMAL_EMULATION instead of
   CONFIG_EXYNOS_THERMAL_EMUL 
  
  This patchset is based on thermal maintainer next tree.
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next 
  
   Documentation/thermal/exynos_thermal_emulation |8 +-
   drivers/thermal/Kconfig|9 --
   drivers/thermal/exynos_thermal.c   |  158 
  ++--
   3 files changed, 67 insertions(+), 108 deletions(-)
  
  diff --git a/Documentation/thermal/exynos_thermal_emulation 
  b/Documentation/thermal/exynos_thermal_emulation
  index b73bbfb..36a3e79 100644
  --- a/Documentation/thermal/exynos_thermal_emulation
  +++ b/Documentation/thermal/exynos_thermal_emulation
  @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for 
  TMU's operation. User can set
   manually with software code and TMU will read current temperature from 
  user value not from
   sensor's value.
   
  -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in 
  available.
  -When it's enabled, sysfs node will be created under
  -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
  +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
  +When it's enabled, sysfs node will be created as
  +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
   
  -The sysfs node, 'emulation', will contain value 0 for the initial state. 
  When you input any
  +The sysfs node, 'emul_node', will contain value 0 for the initial state. 
  When you input any
   temperature you want to update to sysfs node, it automatically enable 
  emulation mode and
   current temperature will be changed into it.
   (Exynos also supports user changable delay time which would be used to 
  delay of
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index e4cf7fb..2a79510 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
   
  -config EXYNOS_THERMAL_EMUL
  -   bool EXYNOS TMU emulation mode support
  -   depends on EXYNOS_THERMAL
  -   help
  - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
  - Enable this option will be make sysfs node in exynos thermal platform
  - device directory to support emulation mode. With emulation mode sysfs
  - node, you can manually input temperature to TMU for simulation 
  purpose.
  -
   config DB8500_THERMAL
  bool DB8500 thermal management
  depends on ARCH_U8500
  diff --git a/drivers/thermal/exynos_thermal.c 
  b/drivers/thermal/exynos_thermal.c
  index 327102a..afe9c2a 100644
  --- a/drivers/thermal/exynos_thermal.c
  +++ b/drivers/thermal/exynos_thermal.c
  @@ -99,13 +99,13 @@
   #define IDLE_INTERVAL 1
   #define MCELSIUS   1000
   
  -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
  +#ifdef CONFIG_THERMAL_EMULATION
   #define EXYNOS_EMUL_TIME   0x57F0
   #define EXYNOS_EMUL_TIME_SHIFT 16
   #define EXYNOS_EMUL_DATA_SHIFT 8
   #define EXYNOS_EMUL_DATA_MASK  0xFF
   #define EXYNOS_EMUL_ENABLE 0x1
  -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
  +#endif /* CONFIG_THERMAL_EMULATION */
   
   /* CPU Zone information */
   #define PANIC_ZONE  4
  @@ -143,6 +143,7 @@ struct  thermal_cooling_conf {
   struct thermal_sensor_conf {
  char name[SENSOR_NAME_LEN];
  int (*read_temperature)(void *data);
  +   int (*write_emul_temp)(void *data, unsigned long temp);
  struct thermal_trip_point_conf trip_data;
  struct thermal_cooling_conf cooling_data;
  void *private_data;
  @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device 
  *thermal,
  return 0;
   }
   
  +/* Get temperature callback functions for thermal zone */
  +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
  +   unsigned long temp)
  +{
  +   void *data;
  +   int ret = -EINVAL;
  +
  +   if (!th_zone-sensor_conf) {
  +   pr_info(Temperature sensor not initialised\n);
  +   return -EINVAL;
  +   }
  +   data = th_zone-sensor_conf-private_data;
  +   if (th_zone-sensor_conf-write_emul_temp)
  +   ret = th_zone-sensor_conf-write_emul_temp(data, temp);
  +   return ret;
  +}
  +
 
   /* Get the temperature trend */
   static int exynos_get_trend(struct thermal_zone_device *thermal,
  int trip, enum

Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support

2013-02-03 Thread Zhang Rui
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
 This removes the driver specific sysfs support of the temperature
 emulation and uses the newly added core thermal framework for thermal
 emulation. A platform specific handler is added to support this.
 
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 ---
 Changes in V2:
 * Added config option CONFIG_THERMAL_EMULATION instead of
  CONFIG_EXYNOS_THERMAL_EMUL 
 
 This patchset is based on thermal maintainer next tree.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next 
 
  Documentation/thermal/exynos_thermal_emulation |8 +-
  drivers/thermal/Kconfig|9 --
  drivers/thermal/exynos_thermal.c   |  158 
 ++--
  3 files changed, 67 insertions(+), 108 deletions(-)
 
 diff --git a/Documentation/thermal/exynos_thermal_emulation 
 b/Documentation/thermal/exynos_thermal_emulation
 index b73bbfb..36a3e79 100644
 --- a/Documentation/thermal/exynos_thermal_emulation
 +++ b/Documentation/thermal/exynos_thermal_emulation
 @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for TMU's 
 operation. User can set
  manually with software code and TMU will read current temperature from user 
 value not from
  sensor's value.
  
 -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in 
 available.
 -When it's enabled, sysfs node will be created under
 -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
 +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
 +When it's enabled, sysfs node will be created as
 +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
  
 -The sysfs node, 'emulation', will contain value 0 for the initial state. 
 When you input any
 +The sysfs node, 'emul_node', will contain value 0 for the initial state. 
 When you input any
  temperature you want to update to sysfs node, it automatically enable 
 emulation mode and
  current temperature will be changed into it.
  (Exynos also supports user changable delay time which would be used to delay 
 of
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index e4cf7fb..2a79510 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
 If you say yes here you get support for TMU (Thermal Management
 Unit) on SAMSUNG EXYNOS series of SoC.
  
 -config EXYNOS_THERMAL_EMUL
 - bool EXYNOS TMU emulation mode support
 - depends on EXYNOS_THERMAL
 - help
 -   Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
 -   Enable this option will be make sysfs node in exynos thermal platform
 -   device directory to support emulation mode. With emulation mode sysfs
 -   node, you can manually input temperature to TMU for simulation 
 purpose.
 -
  config DB8500_THERMAL
   bool DB8500 thermal management
   depends on ARCH_U8500
 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/exynos_thermal.c
 index 327102a..afe9c2a 100644
 --- a/drivers/thermal/exynos_thermal.c
 +++ b/drivers/thermal/exynos_thermal.c
 @@ -99,13 +99,13 @@
  #define IDLE_INTERVAL 1
  #define MCELSIUS 1000
  
 -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
 +#ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME 0x57F0
  #define EXYNOS_EMUL_TIME_SHIFT   16
  #define EXYNOS_EMUL_DATA_SHIFT   8
  #define EXYNOS_EMUL_DATA_MASK0xFF
  #define EXYNOS_EMUL_ENABLE   0x1
 -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
 +#endif /* CONFIG_THERMAL_EMULATION */
  
  /* CPU Zone information */
  #define PANIC_ZONE  4
 @@ -143,6 +143,7 @@ structthermal_cooling_conf {
  struct thermal_sensor_conf {
   char name[SENSOR_NAME_LEN];
   int (*read_temperature)(void *data);
 + int (*write_emul_temp)(void *data, unsigned long temp);
   struct thermal_trip_point_conf trip_data;
   struct thermal_cooling_conf cooling_data;
   void *private_data;
 @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device 
 *thermal,
   return 0;
  }
  
 +/* Get temperature callback functions for thermal zone */
 +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
 + unsigned long temp)
 +{
 + void *data;
 + int ret = -EINVAL;
 +
 + if (!th_zone-sensor_conf) {
 + pr_info(Temperature sensor not initialised\n);
 + return -EINVAL;
 + }
 + data = th_zone-sensor_conf-private_data;
 + if (th_zone-sensor_conf-write_emul_temp)
 + ret = th_zone-sensor_conf-write_emul_temp(data, temp);
 + return ret;
 +}
 +

  /* Get the temperature trend */
  static int exynos_get_trend(struct thermal_zone_device *thermal,
   int trip, enum thermal_trend *trend)
 @@ -382,6 +400,7 @@ static struct thermal_zone_device_ops const 
 exynos_dev_ops = {
   

Re: [PATCH V3 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation

2013-02-03 Thread Zhang Rui
On Sun, 2013-02-03 at 16:30 -0800, Amit Daniel Kachhap wrote:
 This patch adds support to set the emulated temperature method in
 thermal zone (sensor). After setting this feature thermal zone may
 report this temperature and not the actual temperature. The emulation
 implementation may be based on sensor capability through platform
 specific handler or pure software emulation if no platform handler defined.
 
 This is useful in debugging different temperature threshold and its
 associated cooling action. Critical threshold's cannot be emulated.
 Writing 0 on this node should disable emulation.
 
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com

applied to thermal -next.

thanks,
rui
 ---
 Changes in V3:
 * Removed the un-necessary get_temp pointer check.
 * Added the read temp code in #ifdef EMULATION macros
 
 Changes in V2:
 * Added config option for enabling emulation support.
 * Added s/w emulation if no platform handler registered.
 * skip the critical trip point emulation
 
 This patchset is based on thermal maintainer next tree.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next 
 
  Documentation/thermal/sysfs-api.txt |   13 ++
  drivers/thermal/Kconfig |8 
  drivers/thermal/thermal_sys.c   |   79 
 ++-
  include/linux/thermal.h |2 +
  4 files changed, 91 insertions(+), 11 deletions(-)
 
 diff --git a/Documentation/thermal/sysfs-api.txt 
 b/Documentation/thermal/sysfs-api.txt
 index 526d4b9..6859661 100644
 --- a/Documentation/thermal/sysfs-api.txt
 +++ b/Documentation/thermal/sysfs-api.txt
 @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
   .get_trip_type: get the type of certain trip point.
   .get_trip_temp: get the temperature above which the certain trip point
   will be fired.
 + .set_emul_temp: set the emulation temperature which helps in debugging
 + different threshold temperature points.
  
  1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
  
 @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered:
  |---trip_point_[0-*]_temp:   Trip point temperature
  |---trip_point_[0-*]_type:   Trip point type
  |---trip_point_[0-*]_hyst:   Hysteresis value for this trip point
 +|---emul_temp:   Emulated temperature set node
  
  Thermal cooling device sys I/F, created once it's registered:
  /sys/class/thermal/cooling_device[0-*]:
 @@ -252,6 +255,16 @@ passive
   Valid values: 0 (disabled) or greater than 1000
   RW, Optional
  
 +emul_temp
 + Interface to set the emulated temperature method in thermal zone
 + (sensor). After setting this temperature, the thermal zone may pass
 + this temperature to platform emulation function if registered or
 + cache it locally. This is useful in debugging different temperature
 + threshold and its associated cooling action. This is write only node
 + and writing 0 on this node should disable emulation.
 + Unit: millidegree Celsius
 + WO, Optional
 +
  *
  * Cooling device attributes *
  *
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index faf38c5..e4cf7fb 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -78,6 +78,14 @@ config CPU_THERMAL
 and not the ACPI interface.
 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.
 +
  config SPEAR_THERMAL
   bool SPEAr thermal sensor driver
   depends on PLAT_SPEAR
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 0a1bf6b..0675687 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -378,24 +378,54 @@ static void handle_thermal_trip(struct 
 thermal_zone_device *tz, int trip)
   monitor_thermal_zone(tz);
  }
  
 +static int thermal_zone_get_temp(struct thermal_zone_device *tz,
 + unsigned long *temp)
 +{
 + int ret = 0, count;
 + unsigned long crit_temp = -1UL;
 + enum thermal_trip_type type;
 +
 + mutex_lock(tz-lock);
 +
 + ret = tz-ops-get_temp(tz, temp);
 +#ifdef CONFIG_THERMAL_EMULATION
 + if (!tz-emul_temperature)
 + goto skip_emul;
 +
 + for (count = 0; count  tz-trips; count++) {
 + ret = tz-ops-get_trip_type(tz, count, type);
 + if (!ret  type == THERMAL_TRIP_CRITICAL) {
 + ret = tz-ops-get_trip_temp(tz, count, crit_temp);
 

Re: [PATCH V2 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation

2013-02-01 Thread Zhang Rui
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
 This patch adds support to set the emulated temperature method in
 thermal zone (sensor). After setting this feature thermal zone may
 report this temperature and not the actual temperature. The emulation
 implementation may be based on sensor capability through platform
 specific handler or pure software emulation if no platform handler defined.
 
 This is useful in debugging different temperature threshold and its
 associated cooling action. Critical threshold's cannot be emulated.
 Writing 0 on this node should disable emulation.
 
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 ---
 
 Changes in V2:
 * Added config option for enabling emulation support.
 * Added s/w emulation if no platform handler registered.
 * skip the critical trip point emulation
 
 This patchset is based on thermal maintainer next tree.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next 
 
  Documentation/thermal/sysfs-api.txt |   13 ++
  drivers/thermal/Kconfig |8 +++
  drivers/thermal/thermal_sys.c   |   82 
 ++-
  include/linux/thermal.h |2 +
  4 files changed, 94 insertions(+), 11 deletions(-)
 
 diff --git a/Documentation/thermal/sysfs-api.txt 
 b/Documentation/thermal/sysfs-api.txt
 index 526d4b9..6859661 100644
 --- a/Documentation/thermal/sysfs-api.txt
 +++ b/Documentation/thermal/sysfs-api.txt
 @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
   .get_trip_type: get the type of certain trip point.
   .get_trip_temp: get the temperature above which the certain trip point
   will be fired.
 + .set_emul_temp: set the emulation temperature which helps in debugging
 + different threshold temperature points.
  
  1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
  
 @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered:
  |---trip_point_[0-*]_temp:   Trip point temperature
  |---trip_point_[0-*]_type:   Trip point type
  |---trip_point_[0-*]_hyst:   Hysteresis value for this trip point
 +|---emul_temp:   Emulated temperature set node
  
  Thermal cooling device sys I/F, created once it's registered:
  /sys/class/thermal/cooling_device[0-*]:
 @@ -252,6 +255,16 @@ passive
   Valid values: 0 (disabled) or greater than 1000
   RW, Optional
  
 +emul_temp
 + Interface to set the emulated temperature method in thermal zone
 + (sensor). After setting this temperature, the thermal zone may pass
 + this temperature to platform emulation function if registered or
 + cache it locally. This is useful in debugging different temperature
 + threshold and its associated cooling action. This is write only node
 + and writing 0 on this node should disable emulation.
 + Unit: millidegree Celsius
 + WO, Optional
 +
  *
  * Cooling device attributes *
  *
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index faf38c5..e4cf7fb 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -78,6 +78,14 @@ config CPU_THERMAL
 and not the ACPI interface.
 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.
 +
  config SPEAR_THERMAL
   bool SPEAr thermal sensor driver
   depends on PLAT_SPEAR
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 0a1bf6b..59ba709 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -378,24 +378,57 @@ static void handle_thermal_trip(struct 
 thermal_zone_device *tz, int trip)
   monitor_thermal_zone(tz);
  }
  
 +static int thermal_zone_get_temp(struct thermal_zone_device *tz,
 + unsigned long *temp)
 +{
 + int ret = 0, count;
 + unsigned long crit_temp = -1UL;
 + enum thermal_trip_type type;
 +
 + mutex_lock(tz-lock);
 +
 + if (tz-ops-get_temp)
 + ret = tz-ops-get_temp(tz, temp);
we do not need to do this check, .get_temp() should always be available.

#ifdef CONFIG_THERMAL_EMUL
 + else
 + ret = -EPERM;
 +
 + if (!tz-emul_temperature)
 + goto skip_emul;
 +


 + for (count = 0; count  tz-trips; count++) {
 + ret = tz-ops-get_trip_type(tz, count, type);
 + if (!ret  type == THERMAL_TRIP_CRITICAL) {
 + ret = tz-ops-get_trip_temp(tz, count, crit_temp);
 +   

Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp

2013-01-21 Thread Zhang Rui
On Wed, 2013-01-16 at 11:30 -0800, amit kachhap wrote:
 Hi Rui,
 
 Thanks for the review comments,
 On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui rui.zh...@intel.com wrote:
  Hi, Amit,
 
  On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
  This patch adds support to set the emulated temperature method in
  thermal zone (sensor). After setting this feature thermal zone must
  report this temperature and not the actual temperature. The actual
  implementation of this emulated temperature is based on sensor
  capability or platform specific. This is useful in debugging different
  temperature threshold and its associated cooling action. Writing 0 on
  this node should disable emulation.
 
  Question:
  will this bring hardware issue? Say, critical temperature reached while
  in emulation mode?
 No emulation does cause any h/w issue.
 
  As this is for debug purpose, I'd prefer to have a seperate Kconfig
  option for this feature.
 Yes agreed. Will re-submit with kconfig option.
 
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
  ---
   Documentation/thermal/sysfs-api.txt |   14 ++
   drivers/thermal/thermal_sys.c   |   26 ++
   include/linux/thermal.h |1 +
   3 files changed, 41 insertions(+), 0 deletions(-)
 
  diff --git a/Documentation/thermal/sysfs-api.txt 
  b/Documentation/thermal/sysfs-api.txt
  index 88c0233..e8f2ee4 100644
  --- a/Documentation/thermal/sysfs-api.txt
  +++ b/Documentation/thermal/sysfs-api.txt
  @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip 
  point
will be fired.
  + .set_emul_temp: set the emulation temperature which helps in 
  debugging
  + different threshold temperature points.
 
   1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
 
  @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's 
  registered:
   |---trip_point_[0-*]_temp:   Trip point temperature
   |---trip_point_[0-*]_type:   Trip point type
   |---trip_point_[0-*]_hyst:   Hysteresis value for this trip point
  +|---emul_temp:   Emulated temperature set node
 
   Thermal cooling device sys I/F, created once it's registered:
   /sys/class/thermal/cooling_device[0-*]:
  @@ -252,6 +255,17 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
 
  +emul_temp
  + Interface to set the emulated temperature method in thermal zone
  + (sensor). After setting this feature thermal zone must report
  + this temperature and not the actual temperature. The actual
  + implementation of this emulated temperature is platform specific.
 
  can we have a pure software temperature emulation method?
  say, the generic thermal layer caches the emulated temperature value,
  and hook it in update_temperature()?
  This is also useful for testing in polling mode, and it does not require
  platform specific callback support. I mean thermal_ops-set_emul_temp is
  optional, but thermal emulation is always available for all platforms.
 Yes It makes sense and we can have pure software emulation and use the
 cached temperature when no platform call is registered. In my case I
 needed this in h/w so to have the same sensor trigger interrupts
 behaviour.
 
 So the code flow can be like this,
 
 #ifdef CONFIG_THERMAL_EMULATION
 if (thermal_ops-set_emul_temp)
 then pass emul_temp to platform and use the normal platform
 thermal_ops-get_temp
 else
 Store it locally and use emul_temp  instead of calling platform
 thermal_ops-get_temp
 #endif
 
No.
We should not support emulation is CONFIG_THERMAL_EMULATION is cleared.
And further more, for pure software emulation, we should check if the
real temperature reaches critical trip point.

thanks,
rui
 I will re-submit with this change.
 
 Thanks,
 Amit
 
  thanks,
  rui
  + This is useful in debugging different temperature threshold and its
  + associated cooling action. Writing 0 on this node should disable
  + emulation.
  + Unit: millidegree Celsius
  + WO, Optional
  +
   *
   * Cooling device attributes *
   *
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index 8c8ce80..ecdfc7d 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct 
  device_attribute *devattr, char *buf)
return sprintf(buf, %s\n, tz-governor-name);
   }
 
  +static ssize_t
  +emul_temp_store(struct device *dev, struct device_attribute *attr,
  +  const char *buf, size_t count)
  +{
  + struct thermal_zone_device *tz = to_thermal_zone(dev);
  + int ret;
  + unsigned long temperature;
  +
  + if (!tz-ops

Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp

2013-01-15 Thread Zhang Rui
Hi, Amit,

On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
 This patch adds support to set the emulated temperature method in
 thermal zone (sensor). After setting this feature thermal zone must
 report this temperature and not the actual temperature. The actual
 implementation of this emulated temperature is based on sensor
 capability or platform specific. This is useful in debugging different
 temperature threshold and its associated cooling action. Writing 0 on
 this node should disable emulation.

Question:
will this bring hardware issue? Say, critical temperature reached while
in emulation mode?

As this is for debug purpose, I'd prefer to have a seperate Kconfig
option for this feature.

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  Documentation/thermal/sysfs-api.txt |   14 ++
  drivers/thermal/thermal_sys.c   |   26 ++
  include/linux/thermal.h |1 +
  3 files changed, 41 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/thermal/sysfs-api.txt 
 b/Documentation/thermal/sysfs-api.txt
 index 88c0233..e8f2ee4 100644
 --- a/Documentation/thermal/sysfs-api.txt
 +++ b/Documentation/thermal/sysfs-api.txt
 @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
   .get_trip_type: get the type of certain trip point.
   .get_trip_temp: get the temperature above which the certain trip point
   will be fired.
 + .set_emul_temp: set the emulation temperature which helps in debugging
 + different threshold temperature points.
  
  1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
  
 @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered:
  |---trip_point_[0-*]_temp:   Trip point temperature
  |---trip_point_[0-*]_type:   Trip point type
  |---trip_point_[0-*]_hyst:   Hysteresis value for this trip point
 +|---emul_temp:   Emulated temperature set node
  
  Thermal cooling device sys I/F, created once it's registered:
  /sys/class/thermal/cooling_device[0-*]:
 @@ -252,6 +255,17 @@ passive
   Valid values: 0 (disabled) or greater than 1000
   RW, Optional
  
 +emul_temp
 + Interface to set the emulated temperature method in thermal zone
 + (sensor). After setting this feature thermal zone must report
 + this temperature and not the actual temperature. The actual
 + implementation of this emulated temperature is platform specific.

can we have a pure software temperature emulation method?
say, the generic thermal layer caches the emulated temperature value,
and hook it in update_temperature()?
This is also useful for testing in polling mode, and it does not require
platform specific callback support. I mean thermal_ops-set_emul_temp is
optional, but thermal emulation is always available for all platforms.

thanks,
rui
 + This is useful in debugging different temperature threshold and its
 + associated cooling action. Writing 0 on this node should disable
 + emulation.
 + Unit: millidegree Celsius
 + WO, Optional
 +
  *
  * Cooling device attributes *
  *
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 8c8ce80..ecdfc7d 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct device_attribute 
 *devattr, char *buf)
   return sprintf(buf, %s\n, tz-governor-name);
  }
  
 +static ssize_t
 +emul_temp_store(struct device *dev, struct device_attribute *attr,
 +  const char *buf, size_t count)
 +{
 + struct thermal_zone_device *tz = to_thermal_zone(dev);
 + int ret;
 + unsigned long temperature;
 +
 + if (!tz-ops-set_emul_temp)
 + return -EPERM;
 +
 + if (kstrtoul(buf, 10, temperature))
 + return -EINVAL;
 +
 + ret = tz-ops-set_emul_temp(tz, temperature);
 +
 + return ret ? ret : count;
 +}
 +
  static DEVICE_ATTR(type, 0444, type_show, NULL);
  static DEVICE_ATTR(temp, 0444, temp_show, NULL);
  static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
  static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
  static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
 +static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
  
  /* sys I/F for cooling device */
  #define to_cooling_device(_dev)  \
 @@ -1592,6 +1612,12 @@ struct thermal_zone_device 
 *thermal_zone_device_register(const char *type,
   goto unregister;
   }
  
 + if (ops-set_emul_temp) {
 + result = device_create_file(tz-device, dev_attr_emul_temp);
 + if (result)
 + goto unregister;
 + }
 +
   /* Create policy attribute */
   result = device_create_file(tz-device, dev_attr_policy);
   if (result)
 

Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-22 Thread Zhang Rui
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
 On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
  On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
  This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
  and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
  jump to the upper or lower cooling level instead of incremental increase
  or decrease. This is needed for temperature sensors which support 
  rising/falling
  threshold interrupts and polling can be totally avoided.
 
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
  Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
  ---
   drivers/thermal/step_wise.c |   19 +++
   include/linux/thermal.h |2 ++
   2 files changed, 17 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
  index 1242cff..0d2d8d6 100644
  --- a/drivers/thermal/step_wise.c
  +++ b/drivers/thermal/step_wise.c
  @@ -35,6 +35,10 @@
*   state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
*   state for this trip point
  + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
  + *   state for this trip point
  + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
  + *   state for this trip point
*/
   static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
  @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
  thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state  instance-lower ?
(cur_state - 1) : instance-lower;
  - }
  + } else if (trend == THERMAL_TREND_RAISE_FULL)
  + cur_state = instance-upper;
  + else if (trend == THERMAL_TREND_DROP_FULL)
  + cur_state = instance-lower;
 
return cur_state;
   }
  @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
  thermal_zone_device *tz,
   }
 
   static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
  - int trip, enum thermal_trip_type trip_type)
  + int trip, enum thermal_trip_type trip_type,
  + enum thermal_trend trend)
   {
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
  @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
  thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
 
  - instance-target = cur_state  instance-lower ?
  + if (trend == THERMAL_TREND_DROP_FULL)
  + instance-target = instance-lower;
  + else
  + instance-target = cur_state  instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
 
  what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
  this time?
 
 Hi Rui,
 
 I suppose this is dethrotle routine and hence this will be called when
 only drop in temperature happens. Also I did not used get_target_state
 here because I thought it might cause regression in the other existing
 thermal drivers(I am not sure) But I guess calling get_target_state is
 the good way to know next target state and is fine if you agree.
 Also one suggestion, 2 functions for throttle/dethrottle can be merged
 as both look same and just get_target_state can be used in that
 function
 
agree.
patches have been refreshed, please review.

thanks,
rui

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-22 Thread Zhang Rui
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
 This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
 and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
 jump to the upper or lower cooling level instead of incremental increase
 or decrease. This is needed for temperature sensors which support 
 rising/falling
 threshold interrupts and polling can be totally avoided.
 
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 ---
  drivers/thermal/step_wise.c |   19 +++
  include/linux/thermal.h |2 ++
  2 files changed, 17 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
 index 1242cff..0d2d8d6 100644
 --- a/drivers/thermal/step_wise.c
 +++ b/drivers/thermal/step_wise.c
 @@ -35,6 +35,10 @@
   *   state for this trip point
   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
   *   state for this trip point
 + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
 + *   state for this trip point
 + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
 + *   state for this trip point
   */
  static unsigned long get_target_state(struct thermal_instance *instance,
   enum thermal_trend trend)
 @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
 thermal_instance *instance,
   } else if (trend == THERMAL_TREND_DROPPING) {
   cur_state = cur_state  instance-lower ?
   (cur_state - 1) : instance-lower;
 - }
 + } else if (trend == THERMAL_TREND_RAISE_FULL)
 + cur_state = instance-upper;
 + else if (trend == THERMAL_TREND_DROP_FULL)
 + cur_state = instance-lower;
  
   return cur_state;
  }
 @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
 thermal_zone_device *tz,
  }
  
  static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
 - int trip, enum thermal_trip_type trip_type)
 + int trip, enum thermal_trip_type trip_type,
 + enum thermal_trend trend)
  {
   struct thermal_instance *instance;
   struct thermal_cooling_device *cdev;
 @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
 thermal_zone_device *tz,
   cdev = instance-cdev;
   cdev-ops-get_cur_state(cdev, cur_state);
  
 - instance-target = cur_state  instance-lower ?
 + if (trend == THERMAL_TREND_DROP_FULL)
 + instance-target = instance-lower;
 + else
 + instance-target = cur_state  instance-lower ?
   (cur_state - 1) : THERMAL_NO_TARGET;
  
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?

thanks,
rui

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-22 Thread Zhang Rui
On Fri, 2012-11-23 at 09:35 +0530, Amit Kachhap wrote:
 On 22 November 2012 13:42, Zhang Rui rui.zh...@intel.com wrote:
  On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
  On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
   On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
   This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
   and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
   jump to the upper or lower cooling level instead of incremental increase
   or decrease. This is needed for temperature sensors which support 
   rising/falling
   threshold interrupts and polling can be totally avoided.
  
   Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
   Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
   ---
drivers/thermal/step_wise.c |   19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
  
   diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
   index 1242cff..0d2d8d6 100644
   --- a/drivers/thermal/step_wise.c
   +++ b/drivers/thermal/step_wise.c
   @@ -35,6 +35,10 @@
 *   state for this trip point
 *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
 *   state for this trip point
   + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
   + *   state for this trip point
   + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
   + *   state for this trip point
 */
static unsigned long get_target_state(struct thermal_instance 
   *instance,
 enum thermal_trend trend)
   @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
   thermal_instance *instance,
 } else if (trend == THERMAL_TREND_DROPPING) {
 cur_state = cur_state  instance-lower ?
 (cur_state - 1) : instance-lower;
   - }
   + } else if (trend == THERMAL_TREND_RAISE_FULL)
   + cur_state = instance-upper;
   + else if (trend == THERMAL_TREND_DROP_FULL)
   + cur_state = instance-lower;
  
 return cur_state;
}
   @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
   thermal_zone_device *tz,
}
  
static void update_instance_for_dethrottle(struct thermal_zone_device 
   *tz,
   - int trip, enum thermal_trip_type 
   trip_type)
   + int trip, enum thermal_trip_type 
   trip_type,
   + enum thermal_trend trend)
{
 struct thermal_instance *instance;
 struct thermal_cooling_device *cdev;
   @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
   thermal_zone_device *tz,
 cdev = instance-cdev;
 cdev-ops-get_cur_state(cdev, cur_state);
  
   - instance-target = cur_state  instance-lower ?
   + if (trend == THERMAL_TREND_DROP_FULL)
   + instance-target = instance-lower;
   + else
   + instance-target = cur_state  instance-lower ?
 (cur_state - 1) : THERMAL_NO_TARGET;
  
   what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
   this time?
  
  Hi Rui,
 
  I suppose this is dethrotle routine and hence this will be called when
  only drop in temperature happens. Also I did not used get_target_state
  here because I thought it might cause regression in the other existing
  thermal drivers(I am not sure) But I guess calling get_target_state is
  the good way to know next target state and is fine if you agree.
  Also one suggestion, 2 functions for throttle/dethrottle can be merged
  as both look same and just get_target_state can be used in that
  function
 
  agree.
  patches have been refreshed, please review.
 
 Thanks Rui, Your patches looks nice. I will re-base my patches against
 your implementation and submit them shortly.
 
great. please rebase your patch on top of thermal-thermal tree.

thanks,
rui

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 0/4] thermal: Add support for interrupt based notification to thermal layer

2012-11-21 Thread Zhang, Rui
Hi, Amit,

As THERMAL_TREND_RAISE_FULL/THERMAL_TREND_DROP_FULL
has been introduced to thermal next tree,
I'd like to get your plan about this patch set?

Thanks,
Rui

 -Original Message-
 From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
 ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
 Sent: Thursday, November 08, 2012 12:26 PM
 To: linux...@lists.linux-foundation.org
 Cc: linux-samsung-soc@vger.kernel.org; linux-ker...@vger.kernel.org; R,
 Durgadoss; l...@kernel.org; Zhang, Rui; linux-a...@vger.kernel.org;
 amit.kach...@linaro.org; jonghwa3@samsung.com
 Subject: [PATCH 0/4] thermal: Add support for interrupt based
 notification to thermal layer
 Importance: High
 
 The patch submitted by Jonghwa Lee
 (https://patchwork.kernel.org/patch/1683441/)
 adds support for interrupt based notification to thermal layer. This is
 a good feature but the current thermal framework needs polling/regular
 notification for invoking suitable cooling action. So adding 2 new
 thermal trend type to implement this feature.
 
 All these patches are based on thermal maintainer next tree.
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
 
 Amit Daniel Kachhap (3):
   thermal: Add new thermal trend type to support quick cooling
   thermal: exynos: Miscellaneous fixes to support falling threshold
 interrupt
   thermal: exynos: Use the new thermal trend type for quick cooling
 action.
 
 Jonghwa Lee (1):
   Thermal: exynos: Add support for temperature falling interrupt.
 
  drivers/thermal/exynos_thermal.c |  105 +++---
 
  drivers/thermal/step_wise.c  |   19 -
  include/linux/platform_data/exynos_thermal.h |3 +
  include/linux/thermal.h  |2 +
  4 files changed, 80 insertions(+), 49 deletions(-)
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-acpi
 in the body of a message to majord...@vger.kernel.org More majordomo
 info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH-Resend] thermal: Exynos: Add missing dependency

2012-11-14 Thread Zhang Rui
On Thu, 2012-11-15 at 12:31 +0530, Amit Kachhap wrote:
 On 15 November 2012 12:09, Sachin Kamat sachin.ka...@linaro.org wrote:
  CPU_FREQ_TABLE depends on CPU_FREQ. Selecting CPU_FREQ_TABLE without 
  checking
  for dependencies gives the following compilation warnings:
  warning: (ARCH_TEGRA_2x_SOC  ARCH_TEGRA_3x_SOC  UX500_SOC_DB8500 
  CPU_THERMAL  EXYNOS_THERMAL) selects CPU_FREQ_TABLE which has unmet
  direct dependencies (ARCH_HAS_CPUFREQ  CPU_FREQ)
 
  Cc: Amit Daniel Kachhap amit.kach...@linaro.org
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
  ---
   drivers/thermal/Kconfig |3 +--
   1 files changed, 1 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index 266c15e..6124c4b 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -50,8 +50,7 @@ config RCAR_THERMAL
 
   config EXYNOS_THERMAL
  tristate Temperature sensor on Samsung EXYNOS
  -   depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)  THERMAL
  -   select CPU_FREQ_TABLE
 Hi Sachin/Rui,
 
 select CPU_FREQ_TABLE should be there even if CONFIG_CPU_FREQ is
 enabled. Only some governors enable it.

But CPU_THERMAL will select it, right?

  See drivers/cpufreq/Kconfig
 Also depends THERMAL should be there otherwise menuconfig
 parent/child relationship is broken.
 
this should be solved by my patch 1/2. :)

thanks,
rui

 Thanks,
 Amit Daniel
 
  +   depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)  CPU_THERMAL
  help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
  --
  1.7.4.1
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-11 Thread Zhang Rui
On Fri, 2012-11-09 at 11:51 +0530, Amit Kachhap wrote:
 On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
  On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
  On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
   On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
   This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
   and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
   jump to the upper or lower cooling level instead of incremental increase
   or decrease.
  
   IMO, what we need is a new more aggressive cooling governor which always
   uses upper limit when the temperature is raising and lower limit when
   the temperature is dropping.
  Yes I agree that a new aggressive governor is the best approach but
  then i thought adding a new trend type is a simple solution to achieve
  this and since most of the governor logic might be same as the
  step-wise governor. I have no objection in doing it through governor.
  
  hmmm,
  I think a more proper way is to set the cooling state to upper limit
  when it overheats and reduce the cooling state step by step when the
  temperature drops.
 
 No actually I was thinking of having a  simple governor with a feature
 like it only sets to upper level and lower level. Also since the
 temperature sensor is capable of interrupting for both increase in
 threshold(say 100C)  and fall in threshold (say 90C), so polling or
 step increments is not needed at all.
 Currently stepwise governor governor does that so we might change the
 macro name as,
 THERMAL_TREND_RAISE_STEP,
 THERMAL_TREND_DROP_STEP,
 THERMAL_TREND_RAISE_MAX,
 THERMAL_TREND_DROP_MAX,
 
 and file step_wise.c can be named as state_wise.c or trend_wise.c.
 
 I am not sure if it is the best way . How do you feel ?
 
this sounds good to me.
I'd like to see Durga' comments on this as well.

thanks,
rui
  what do you think?
 
  thanks,
  rui
 
   I can write such a governor if you do not have time to.
  ok. thanks
  
   thanks,
   rui
This is needed for temperature sensors which support rising/falling
   threshold interrupts and polling can be totally avoided.
  
  
  
   Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
   Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
   ---
drivers/thermal/step_wise.c |   19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
  
   diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
   index 1242cff..0d2d8d6 100644
   --- a/drivers/thermal/step_wise.c
   +++ b/drivers/thermal/step_wise.c
   @@ -35,6 +35,10 @@
 *   state for this trip point
 *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
 *   state for this trip point
   + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
   + *   state for this trip point
   + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
   + *   state for this trip point
 */
static unsigned long get_target_state(struct thermal_instance 
   *instance,
 enum thermal_trend trend)
   @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
   thermal_instance *instance,
 } else if (trend == THERMAL_TREND_DROPPING) {
 cur_state = cur_state  instance-lower ?
 (cur_state - 1) : instance-lower;
   - }
   + } else if (trend == THERMAL_TREND_RAISE_FULL)
   + cur_state = instance-upper;
   + else if (trend == THERMAL_TREND_DROP_FULL)
   + cur_state = instance-lower;
  
 return cur_state;
}
   @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
   thermal_zone_device *tz,
}
  
static void update_instance_for_dethrottle(struct thermal_zone_device 
   *tz,
   - int trip, enum thermal_trip_type 
   trip_type)
   + int trip, enum thermal_trip_type 
   trip_type,
   + enum thermal_trend trend)
{
 struct thermal_instance *instance;
 struct thermal_cooling_device *cdev;
   @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
   thermal_zone_device *tz,
 cdev = instance-cdev;
 cdev-ops-get_cur_state(cdev, cur_state);
  
   - instance-target = cur_state  instance-lower ?
   + if (trend == THERMAL_TREND_DROP_FULL)
   + instance-target = instance-lower;
   + else
   + instance-target = cur_state  instance-lower ?
 (cur_state - 1) : THERMAL_NO_TARGET;
  
 /* Deactivate a passive thermal instance */
   @@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
   thermal_zone_device *tz, int trip)
 if (tz-temperature = trip_temp

RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-11 Thread Zhang Rui
On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
 Hi Amit/Rui,
 
  -Original Message-
  From: Amit Kachhap [mailto:amit.kach...@linaro.org]
  Sent: Friday, November 09, 2012 11:52 AM
  To: Zhang, Rui
  Cc: linux...@lists.linux-foundation.org; linux-samsung-
  s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
  l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
  Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
  quick cooling
  
  On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
   On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
   On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
  THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
  quickly
jump to the upper or lower cooling level instead of incremental
  increase
or decrease.
   
IMO, what we need is a new more aggressive cooling governor which
  always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
   Yes I agree that a new aggressive governor is the best approach but
   then i thought adding a new trend type is a simple solution to achieve
   this and since most of the governor logic might be same as the
   step-wise governor. I have no objection in doing it through governor.
   
   hmmm,
   I think a more proper way is to set the cooling state to upper limit
   when it overheats and reduce the cooling state step by step when the
   temperature drops.
  
  No actually I was thinking of having a  simple governor with a feature
  like it only sets to upper level and lower level. Also since the
  temperature sensor is capable of interrupting for both increase in
  threshold(say 100C)  and fall in threshold (say 90C), so polling or
  step increments is not needed at all.
  Currently stepwise governor governor does that so we might change the
  macro name as,
  THERMAL_TREND_RAISE_STEP,
  THERMAL_TREND_DROP_STEP,
  THERMAL_TREND_RAISE_MAX,
  THERMAL_TREND_DROP_MAX,
  
  and file step_wise.c can be named as state_wise.c or trend_wise.c.
 
 Yes, in this particular case, we neither need to poll nor do step wise
 operations. But, most of the other sensors need at least one of them.
 
 So, I think we can try it this way:
   if (sensor supports interrupt) {
   'always' use RAISE_MAX and DROP_MAX;
   } else {
   Do Step wise operations
   }
 
why should the generic thermal layer be aware of this?

IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.

and the step_wise governor just takes action based on the return value
of .get_trend() callback.

thanks,
rui

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-08 Thread Zhang Rui
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
 On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
  On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
  This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
  and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
  jump to the upper or lower cooling level instead of incremental increase
  or decrease.
 
  IMO, what we need is a new more aggressive cooling governor which always
  uses upper limit when the temperature is raising and lower limit when
  the temperature is dropping.
 Yes I agree that a new aggressive governor is the best approach but
 then i thought adding a new trend type is a simple solution to achieve
 this and since most of the governor logic might be same as the
 step-wise governor. I have no objection in doing it through governor.
 
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
what do you think?

thanks,
rui

  I can write such a governor if you do not have time to.
 ok. thanks
 
  thanks,
  rui
   This is needed for temperature sensors which support rising/falling
  threshold interrupts and polling can be totally avoided.
 
 
 
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
  Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
  ---
   drivers/thermal/step_wise.c |   19 +++
   include/linux/thermal.h |2 ++
   2 files changed, 17 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
  index 1242cff..0d2d8d6 100644
  --- a/drivers/thermal/step_wise.c
  +++ b/drivers/thermal/step_wise.c
  @@ -35,6 +35,10 @@
*   state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
*   state for this trip point
  + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
  + *   state for this trip point
  + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
  + *   state for this trip point
*/
   static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
  @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
  thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state  instance-lower ?
(cur_state - 1) : instance-lower;
  - }
  + } else if (trend == THERMAL_TREND_RAISE_FULL)
  + cur_state = instance-upper;
  + else if (trend == THERMAL_TREND_DROP_FULL)
  + cur_state = instance-lower;
 
return cur_state;
   }
  @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
  thermal_zone_device *tz,
   }
 
   static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
  - int trip, enum thermal_trip_type trip_type)
  + int trip, enum thermal_trip_type trip_type,
  + enum thermal_trend trend)
   {
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
  @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
  thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
 
  - instance-target = cur_state  instance-lower ?
  + if (trend == THERMAL_TREND_DROP_FULL)
  + instance-target = instance-lower;
  + else
  + instance-target = cur_state  instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
 
/* Deactivate a passive thermal instance */
  @@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
  thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
  - update_instance_for_dethrottle(tz, trip, trip_type);
  + update_instance_for_dethrottle(tz, trip, trip_type, trend);
 
mutex_unlock(tz-lock);
   }
  diff --git a/include/linux/thermal.h b/include/linux/thermal.h
  index 807f214..8bce3ec 100644
  --- a/include/linux/thermal.h
  +++ b/include/linux/thermal.h
  @@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
  + THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
  + THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
   };
 
   /* Events supported by Thermal Netlink */
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org

Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

2012-11-07 Thread Zhang Rui
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
 This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
 and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
 jump to the upper or lower cooling level instead of incremental increase
 or decrease.

IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.

I can write such a governor if you do not have time to.

thanks,
rui
  This is needed for temperature sensors which support rising/falling
 threshold interrupts and polling can be totally avoided.
 


 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 ---
  drivers/thermal/step_wise.c |   19 +++
  include/linux/thermal.h |2 ++
  2 files changed, 17 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
 index 1242cff..0d2d8d6 100644
 --- a/drivers/thermal/step_wise.c
 +++ b/drivers/thermal/step_wise.c
 @@ -35,6 +35,10 @@
   *   state for this trip point
   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
   *   state for this trip point
 + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
 + *   state for this trip point
 + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
 + *   state for this trip point
   */
  static unsigned long get_target_state(struct thermal_instance *instance,
   enum thermal_trend trend)
 @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
 thermal_instance *instance,
   } else if (trend == THERMAL_TREND_DROPPING) {
   cur_state = cur_state  instance-lower ?
   (cur_state - 1) : instance-lower;
 - }
 + } else if (trend == THERMAL_TREND_RAISE_FULL)
 + cur_state = instance-upper;
 + else if (trend == THERMAL_TREND_DROP_FULL)
 + cur_state = instance-lower;
  
   return cur_state;
  }
 @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
 thermal_zone_device *tz,
  }
  
  static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
 - int trip, enum thermal_trip_type trip_type)
 + int trip, enum thermal_trip_type trip_type,
 + enum thermal_trend trend)
  {
   struct thermal_instance *instance;
   struct thermal_cooling_device *cdev;
 @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
 thermal_zone_device *tz,
   cdev = instance-cdev;
   cdev-ops-get_cur_state(cdev, cur_state);
  
 - instance-target = cur_state  instance-lower ?
 + if (trend == THERMAL_TREND_DROP_FULL)
 + instance-target = instance-lower;
 + else
 + instance-target = cur_state  instance-lower ?
   (cur_state - 1) : THERMAL_NO_TARGET;
  
   /* Deactivate a passive thermal instance */
 @@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
 thermal_zone_device *tz, int trip)
   if (tz-temperature = trip_temp)
   update_instance_for_throttle(tz, trip, trip_type, trend);
   else
 - update_instance_for_dethrottle(tz, trip, trip_type);
 + update_instance_for_dethrottle(tz, trip, trip_type, trend);
  
   mutex_unlock(tz-lock);
  }
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 807f214..8bce3ec 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -68,6 +68,8 @@ enum thermal_trend {
   THERMAL_TREND_STABLE, /* temperature is stable */
   THERMAL_TREND_RAISING, /* temperature is raising */
   THERMAL_TREND_DROPPING, /* temperature is dropping */
 + THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
 + THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
  };
  
  /* Events supported by Thermal Netlink */


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RESEND] thermal: add generic cpufreq cooling implementation

2012-09-10 Thread Zhang Rui
Refreshed to remove the notifier mechanism as we do not have a real user of it.
if there is no problem, I'll apply the whole patch set to thermal next tree.

From: Amit Daniel Kachhap amit.kach...@linaro.org
Date: Thu, 16 Aug 2012 17:11:40 +0530

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.

Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
 Documentation/thermal/cpu-cooling-api.txt |   33 ++
 drivers/thermal/Kconfig   |   11 +
 drivers/thermal/Makefile  |1 +
 drivers/thermal/cpu_cooling.c |  450 +
 include/linux/cpu_cooling.h   |   58 
 5 files changed, 553 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/thermal/cpu-cooling-api.txt
 create mode 100644 drivers/thermal/cpu_cooling.c
 create mode 100644 include/linux/cpu_cooling.h

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
new file mode 100644
index 000..6fe9cdb
--- /dev/null
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -0,0 +1,33 @@
+CPU cooling APIs How To
+===
+
+Written by Amit Daniel Kachhap amit.kach...@linaro.org
+
+Updated: 12 May 2012
+
+Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
+
+0. Introduction
+
+The generic cpu cooling(freq clipping) provides registration/unregistration 
APIs
+to the caller. The binding of the cooling devices to the trip point is left for
+the user. The registration APIs returns the cooling device pointer.
+
+1. cpu cooling APIs
+
+1.1 cpufreq registration/unregistration APIs
+1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
+   struct cpumask *clip_cpus)
+
+This interface function registers the cpufreq cooling device with the name
+thermal-cpufreq-%x. This api can support multiple instances of cpufreq
+cooling devices.
+
+   clip_cpus: cpumask of cpus where the frequency constraints will happen.
+
+1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+
+This interface function unregisters the thermal-cpufreq-%x

Re: [PATCH RESEND] thermal: add generic cpufreq cooling implementation

2012-09-10 Thread Zhang Rui
On 一, 2012-09-10 at 09:50 +0300, Valentin, Eduardo wrote:
 Hello Rui and Amit,
 
 On Mon, Sep 10, 2012 at 9:25 AM, Zhang Rui rui.zh...@intel.com wrote:
  Refreshed to remove the notifier mechanism as we do not have a real user of 
  it.
  if there is no problem, I'll apply the whole patch set to thermal next tree.
 
  From: Amit Daniel Kachhap amit.kach...@linaro.org
  Date: Thu, 16 Aug 2012 17:11:40 +0530
 
  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.
 
  Cc: Guenter Roeck guenter.ro...@ericsson.com
  Cc: SangWook Ju sw...@samsung.com
  Cc: Durgadoss durgados...@intel.com
  Cc: Len Brown l...@kernel.org
  Cc: Jean Delvare kh...@linux-fr.org
  Cc: Kyungmin Park kmp...@infradead.org
  Cc: Kukjin Kim kgene@samsung.com
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  Signed-off-by: Andrew Morton a...@linux-foundation.org
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 
 
 can you please include my Reviewed-by? Also on your patch series I
 have reviewed.
 
sure.

 Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
 
thanks!

-rui
 
 
  ---
   Documentation/thermal/cpu-cooling-api.txt |   33 ++
   drivers/thermal/Kconfig   |   11 +
   drivers/thermal/Makefile  |1 +
   drivers/thermal/cpu_cooling.c |  450 
  +
   include/linux/cpu_cooling.h   |   58 
   5 files changed, 553 insertions(+), 0 deletions(-)
   create mode 100644 Documentation/thermal/cpu-cooling-api.txt
   create mode 100644 drivers/thermal/cpu_cooling.c
   create mode 100644 include/linux/cpu_cooling.h
 
  diff --git a/Documentation/thermal/cpu-cooling-api.txt 
  b/Documentation/thermal/cpu-cooling-api.txt
  new file mode 100644
  index 000..6fe9cdb
  --- /dev/null
  +++ b/Documentation/thermal/cpu-cooling-api.txt
  @@ -0,0 +1,33 @@
  +CPU cooling APIs How To
  +===
  +
  +Written by Amit Daniel Kachhap amit.kach...@linaro.org
  +
  +Updated: 12 May 2012
  +
  +Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
  +
  +0. Introduction
  +
  +The generic cpu cooling(freq clipping) provides 
  registration/unregistration APIs
  +to the caller. The binding of the cooling devices to the trip point is 
  left for
  +the user. The registration APIs returns the cooling device pointer.
  +
  +1. cpu cooling APIs
  +
  +1.1 cpufreq

Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

2012-08-19 Thread Zhang Rui
On 五, 2012-08-17 at 11:56 +0300, Valentin, Eduardo wrote:
 Hello,

  +
  +
  +1.2 CPU cooling action notifier register/unregister interface
  +1.2.1 int cputherm_register_notifier(struct notifier_block *nb,
  + unsigned int list)
  +
  +This interface registers a driver with cpu cooling layer. The driver 
  will
  +be notified when any cpu cooling action is called.
  +
  +nb: notifier function to register
  +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
  +
  +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb,
  + unsigned int list)
  +
  +This interface registers a driver with cpu cooling layer. The driver 
  will
  +be notified when any cpu cooling action is called.
  +
  +nb: notifier function to register
  +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
 
  what are these two APIs used for?
  I did not see they are used in your patch set, do I miss something?
  No currently they are not used by my patches. I added them on request
  from Eduardo and others
 
 Yeah, this was a suggestion as we didn't really know how the FW part
 would evolve by that time.
 
 The reasoning is to allow any interested user (in kernel) to be
 notified when max frequency changes.

in this case, the cooling device should be updated.
Say all the target of the thermal_instances of a cooling devices is 0,
which means they want the cpu to run at maximum frequency, when the max
frequency changes, we should set the processor to the new max frequency
as well.
Using notification is not a good idea as user can not handle this
without interacting with the thermal framework.

IMO, we should introduce a new API to handle this, rather than just
notifications to users.

  Actually, the use case behind
 this is to allow such users to perform some handshaking or stop their
 activities or even change some paramenters, in case the max frequency
 would change.

It is the cooling device driver that notice this change first, and it
should invoke something like thermal_cooling_device_update/rebind() to
tell the thermal framework this change.

  Ideally it would be possible to nack the cooling
 transition. But that is yet a wider discussion. So far we don't have
 users for this.
 
yep.
I thought about this before, but I'd prefer to do this when there is a
real user. Or else, we are kind of over-designing here.
how about removing this piece of code for now?

thanks,
rui

 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index 7dd8c34..996003b 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -19,6 +19,17 @@ config THERMAL_HWMON
depends on HWMON=y || HWMON=THERMAL
default y
 
  +config CPU_THERMAL
  + bool generic cpu cooling support
  + depends on THERMAL  CPU_FREQ
  + help
  +   This implements the generic cpu cooling mechanism through 
  frequency
  +   reduction, cpu hotplug and any other ways of reducing 
  temperature. An
  +   ACPI version of this already 
  exists(drivers/acpi/processor_thermal.c).
  +   This will be useful for platforms using the generic thermal 
  interface
  +   and not the ACPI interface.
  +   If you want this support, you should say Y here.
  +
   config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on THERMAL
  diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
  index fd9369a..aae59ad 100644
  --- a/drivers/thermal/Makefile
  +++ b/drivers/thermal/Makefile
  @@ -3,5 +3,6 @@
   #
 
   obj-$(CONFIG_THERMAL)+= thermal_sys.o
  +obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
   obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
   obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
  diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
  new file mode 100644
  index 000..c42e557
  --- /dev/null
  +++ b/drivers/thermal/cpu_cooling.c
  @@ -0,0 +1,512 @@
  +/*
  + *  linux/drivers/thermal/cpu_cooling.c
  + *
  + *  Copyright (C) 2012   Samsung Electronics Co., 
  Ltd(http://www.samsung.com)
  + *  Copyright (C) 2012  Amit Daniel amit.kach...@linaro.org
  + *
  + * 
  ~~
  + *  This program is free software; you can redistribute it and/or modify
  + *  it under the terms of the GNU General Public License as published by
  + *  the Free Software Foundation; version 2 of the License.
  + *
  + *  This program is distributed in the hope that it will be useful, but
  + *  WITHOUT ANY WARRANTY; without even the implied warranty of
  + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  + *  General Public License for more details.
  + *
  + *  You should have received a copy of the GNU General Public License 
  along
  + *  with this program; if not, write to the Free Software Foundation, 
  Inc.,
  + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
  + *
  + * 
  

Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

2012-08-17 Thread Zhang Rui
On 四, 2012-08-16 at 17:11 +0530, Amit Daniel Kachhap wrote:
 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.
 
 [a...@linux-foundation.org: fix comment layout]
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 Cc: Guenter Roeck guenter.ro...@ericsson.com
 Cc: SangWook Ju sw...@samsung.com
 Cc: Durgadoss durgados...@intel.com
 Cc: Len Brown l...@kernel.org
 Cc: Jean Delvare kh...@linux-fr.org
 Cc: Kyungmin Park kmp...@infradead.org
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  Documentation/thermal/cpu-cooling-api.txt |   52 +++
  drivers/thermal/Kconfig   |   11 +
  drivers/thermal/Makefile  |1 +
  drivers/thermal/cpu_cooling.c |  512 
 +
  include/linux/cpu_cooling.h   |   79 +
  5 files changed, 655 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
  create mode 100644 drivers/thermal/cpu_cooling.c
  create mode 100644 include/linux/cpu_cooling.h
 
 diff --git a/Documentation/thermal/cpu-cooling-api.txt 
 b/Documentation/thermal/cpu-cooling-api.txt
 new file mode 100644
 index 000..a1f2a6b
 --- /dev/null
 +++ b/Documentation/thermal/cpu-cooling-api.txt
 @@ -0,0 +1,52 @@
 +CPU cooling APIs How To
 +===
 +
 +Written by Amit Daniel Kachhap amit.kach...@linaro.org
 +
 +Updated: 12 May 2012
 +
 +Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
 +
 +0. Introduction
 +
 +The generic cpu cooling(freq clipping) provides registration/unregistration 
 APIs
 +to the caller. The binding of the cooling devices to the trip point is left 
 for
 +the user. The registration APIs returns the cooling device pointer.
 +
 +1. cpu cooling APIs
 +
 +1.1 cpufreq registration/unregistration APIs
 +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
 + struct cpumask *clip_cpus)
 +
 +This interface function registers the cpufreq cooling device with the 
 name
 +thermal-cpufreq-%x. This api can support multiple instances of cpufreq
 +cooling devices.
 +
 +   clip_cpus: cpumask of cpus where the frequency constraints will happen.
 +
 +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 +
 +This interface function unregisters the thermal-cpufreq-%x cooling 

RE: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform

2012-05-08 Thread Zhang, Rui
Hi, Amit,

Sorry for the late response as I'm in a travel recently.

I think the generic cpufreq cooling patches are good.

But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that 
1. from thermal zone point of view, when the temperature is higher than a trip 
point, either ACTIVE or PASSIVE, what we should do is to set device cooling 
state to cur_state+1, right?
  The only difference is that if we should take passive cooling actions or 
active cooling actions based on the policy.
  So my question would be if it is possible to combine these two kind of trip 
points together. Maybe something like this:

  In thermal_zone_device_update(),

  ...
  case THERMAL_TRIP_PASSIVE:
  if (passive cooling not allowed)
   continue;
  if (tc1)
   thermal_zone_device_passive();
  else
   thermal_set_cooling_state();
  break;
  case THERMAL_TRIP_ACTIVE:
 if (active cooling not allowed)
  continue;
 thermal_set_cooling_state();
 break;
  ...

and thermal_set_cooling_state() {
   list_for_each_entry(instance, tz-cooling_devices, node) {
  if (instance-trip != count)
 continue;

  cdev = instance-cdev;

  if (temp = trip_temp)
  cdev-ops-set_cur_state(cdev, 1);
  else
  cdev-ops-set_cur_state(cdev, 0);
   }
}

2. use only one cooling_device instance for a thermal_zone, and introduce 
cdev-trips which shows the trip points this cooling device is bind to.
  And we may use multiple cooling devices states for one active trip point.

Then, thermal_set_cooling_state() would be look like

list_for_each_entry(instance, tz-cooling_devices, node) {
   cdev = instance-cdev;
   /* check whether this cooling device is bind to the trip point */
   if (!(cdev-trips  1count))
  continue;
   cdev-ops-get_max_state(cdev, max_state);
   cdev-ops-get_cur_state(cdev, cur_state);

   if (temp = trip_temp) {
  if (cur_state++ = max_state))
cdev-ops-set_cur_state(cdev, cur_state);
   } else if ((temp  trip_temp)  (cur_state-- = 0))
  cdev-ops-set_cur_state(cdev, cur_state);
}
}

With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be registered 
as two PASSIVE trip points in the generic thermal layer, right?
Actually, this is one thing in my TODO list. And I'd glad to make it high 
priority if this solves the problem you have.

Thanks,
rui

-Original Message-
From: linux-acpi-ow...@vger.kernel.org 
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
Sent: Tuesday, May 08, 2012 9:18 AM
To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui; 
amit.kach...@linaro.org; linaro-...@lists.linaro.org; 
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-samsung-soc@vger.kernel.org; patc...@linaro.org
Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos 
platform
Importance: High

Hi Andrew,

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:

 * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal)
 * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
 * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git 
imx6q_thermal)

These patches have been reviewed by Rui Zhang 
(https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting 
them merged, perhaps a lack of maintainer bandwidth.

ACPI platforms currently have such a mechanism but it is wrapped in ACPI'isms 
that we don't have on ARM platforms. If this is accepted, I'm proposing to 
convert over the ACPI thermal driver to use this common code too.

Can you please merge these patches for 3.5?

Thanks,
Amit Daniel


Changes since V2:
*Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5 
TMU  driver was internally developed by SangWook Ju sw...@samsung.com.
*Removed cpuhotplug cooling code in this patchset.
*Rebased the patches against 3.4-rc6 kernel.

Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon folder  as 
suggested by Mark Brown and Guenter Roeck *Added notifier support to notify the 
registered drivers of any cpu cooling  action. The driver can modify the 
default cooling behaviour(eg set different  max clip frequency).
*The percentage based frequency replaced with absolute clipped frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to  
THERMAL_TRIP_STATE_INSTANCE *Many review comments from R, Durgadoss 
durgados...@intel.com and  eduardo.valen...@ti.com implemented.
*Removed cooling stats through debugfs patch *The V1 based can be found here,
 https://lkml.org/lkml/2012/2/22

Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform

2012-04-15 Thread Zhang Rui
On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
 Hi Rui,
 
 Thanks for looking into the patches.
 
 On 10 April 2012 06:28, Zhang Rui rui.zh...@intel.com wrote:
  Hi, Amit,
 
  On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
  Hi Len/Rui,
 
  Any comment or feedback from your side about the status of this patch?
  Is it merge-able or major re-work is needed? I have fixed most of the
  comments in this patchset and currently working on some of the minor
  comments received and will submit them shortly.
 
  Sorry for the late response.
 
  First of all, it makes sense to me to introduce the generic cpufrq
  cooling implementation.
 ok thanks
  But I still have some questions.
  I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
  that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
  current passive handling in the generic thermal layer well, right?
  e.g. there is no tc1/tc2 on exynos4.
 
  If yes, is it possible that we can enhance the passive cooling to
  support the generic processor cooling?
  say, introduce another way to throttle the processor in
  thermal_zone_device_passive when tc1 and tc2 are not available?
 
 I agree that this new trip type code can be moved into passive trip
 type when tc1 and tc2 are 0. but this is special type of cooling
 devices behaviour where only instances of the same cooling device is
 binded to a trip point. The order of mapping is the only
 differentiating criteria and there are some checks used to implement
 this like
 1) The trip points should be in ascending order.(This is missing in my
 original patch, so I added below)
 2) The set_cur_state has to be called for the exact temp range so
 get_cur_state(state) and set_cur_state(state ++/state--) logic is not
 possible.
 3) set_cur_state is called as set_cur_state(cdev_instance).

Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?

I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?

thanks,
rui

 There is a chance that people might confuse that these checks are
 applicable for passive trip types also which is not the case here.
 
 @@ -1187,6 +1228,21 @@ struct thermal_zone_device
 *thermal_zone_device_register(char *type,
 tz-ops-get_trip_type(tz, count, trip_type);
 if (trip_type == THERMAL_TRIP_PASSIVE)
 passive = 1;
 +   /*
 +* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
 +* be in ascending order.
 +   */
 +   if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
 +   tz-ops-get_trip_temp(tz, count, trip_temp);
 +   if (first_trip_temp == 0)
 +   first_trip_temp = trip_temp;
 +   else if (first_trip_temp  trip_temp)
 +   first_trip_temp = trip_temp;
 +   else if (first_trip_temp  trip_temp) {
 +   pr_warn(Zone trip points should be in
 ascending order\n);
 +   goto unregister;
 +   }
 +   }
 }
 
 if (!passive)
 
 Anyway there is other alternative where this new trip type is not
 needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
 and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
 I had thought to make this generic and just to manage with 1 cooling
 device.
 What is your view?
 
 Thanks,
 Amit Daniel
 
 
 
  thanks,
  rui
 
  Regards,
  Amit Daniel
 
  On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org 
  wrote:
   Changes since V1:
   *Moved the sensor driver to driver/thermal folder from driver/hwmon 
   folder
as suggested by Mark Brown and Guenter Roeck
   *Added notifier support to notify the registered drivers of any cpu 
   cooling
action. The driver can modify the default cooling behaviour(eg set 
   different
max clip frequency).
   *The percentage based frequency replaced with absolute clipped frequency.
   *Some more conditional checks when setting max frequency.
   *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
   *Many review comments from R, Durgadoss durgados...@intel.com and
eduardo.valen...@ti.com implemented.
   *Removed cooling stats through debugfs patch
   *The V1 based can be found here,
https://lkml.org/lkml/2012/2/22/123
http://lkml.org/lkml/2012/3/3/32
  
   Changes since RFC:
   *Changed the cpu cooling registration/unregistration API's to instance 
   based
   *Changed the STATE_ACTIVE trip type to pass correct instance id
   *Adding support to restore back the policy-max_freq after doing 
   frequency
clipping.
   *Moved the trip cooling stats from sysfs

Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform

2012-04-09 Thread Zhang Rui
Hi, Amit,

On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
 Hi Len/Rui,
 
 Any comment or feedback from your side about the status of this patch?
 Is it merge-able or major re-work is needed? I have fixed most of the
 comments in this patchset and currently working on some of the minor
 comments received and will submit them shortly.
 
Sorry for the late response.

First of all, it makes sense to me to introduce the generic cpufrq
cooling implementation.
But I still have some questions.
I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
current passive handling in the generic thermal layer well, right?
e.g. there is no tc1/tc2 on exynos4.

If yes, is it possible that we can enhance the passive cooling to
support the generic processor cooling?
say, introduce another way to throttle the processor in
thermal_zone_device_passive when tc1 and tc2 are not available?

thanks,
rui

 Regards,
 Amit Daniel
 
 On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
  Changes since V1:
  *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
   as suggested by Mark Brown and Guenter Roeck
  *Added notifier support to notify the registered drivers of any cpu cooling
   action. The driver can modify the default cooling behaviour(eg set 
  different
   max clip frequency).
  *The percentage based frequency replaced with absolute clipped frequency.
  *Some more conditional checks when setting max frequency.
  *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
   THERMAL_TRIP_STATE_INSTANCE
  *Many review comments from R, Durgadoss durgados...@intel.com and
   eduardo.valen...@ti.com implemented.
  *Removed cooling stats through debugfs patch
  *The V1 based can be found here,
   https://lkml.org/lkml/2012/2/22/123
   http://lkml.org/lkml/2012/3/3/32
 
  Changes since RFC:
  *Changed the cpu cooling registration/unregistration API's to instance based
  *Changed the STATE_ACTIVE trip type to pass correct instance id
  *Adding support to restore back the policy-max_freq after doing frequency
   clipping.
  *Moved the trip cooling stats from sysfs node to debugfs node as suggested
   by Greg KH g...@kroah.com
  *Incorporated several review comments from eduardo.valen...@ti.com
  *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
   as discussed with Guenter Roeck guenter.ro...@ericsson.com and
   Donggeun Kim dg77@samsung.com (https://lkml.org/lkml/2012/1/5/7)
  *Some changes according to the changes in common cpu cooling APIs
  *The RFC based patches can be found here,
   https://lkml.org/lkml/2011/12/13/186
   https://lkml.org/lkml/2011/12/21/169
 
 
  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
  codes is architecture independent.
 
  2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which 
  passes
  cooling device instance number and may be helpful for cpufreq cooling 
  devices
  to take the correct cooling action. This trip type avoids the temperature
  comparision check again inside the cooling handler.
 
  3) This patchset adds generic cpu cooling low level implementation through
  frequency clipping and cpu hotplug. 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 freq_clip_table *tab_ptr, unsigned int tab_size,
 const struct cpumask *mask_val)
b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 
  4) 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.
 
  All this patchset is based on Kernel version 3.3-rc7
 
  A simple data/control flow diagrams is shown below,
 
  Core Linux thermal -  Exynos thermal interface - Temperature 
  Sensor
   | |
  \|/|
   Cpufreq cooling device ---
 
 
  Amit Daniel Kachhap (6):
   thermal: Add a new trip type to use cooling device instance number
   thermal: Add generic cpufreq cooling implementation
   thermal: Add generic cpuhotplug cooling implementation
   hwmon: exynos4: Move thermal sensor driver to driver/thermal
 directory
   thermal: exynos4: Register the tmu sensor