Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

[Eduardo Valentin]

 = THERMAL_DEVICE_ENABLED;
 +
 + pr_info(Exynos: Kernel Thermal management registered\n);
 +
 + return 0;
 +
 +err_unregister:
 + exynos_unregister_thermal();
 + return ret;
 +}
 +
 +/* Un-Register with the in-kernel thermal management */
 +void exynos_unregister_thermal(void)
 +{
 + int i;
 +
 + if (!th_zone)
 + return;
 +
 + if (th_zone-therm_dev)
 + thermal_zone_device_unregister(th_zone-therm_dev);
 +
 + for (i = 0; i  th_zone-cool_dev_size; i++) {
 + if (th_zone-cool_dev[i])
 + cpufreq_cooling_unregister(th_zone-cool_dev[i]);
 + }
 +
 + kfree(th_zone);
 + pr_info(Exynos: Kernel Thermal management unregistered\n);
 +}
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 new file mode 100644
 index 000..8df1848
 --- /dev/null
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -0,0 +1,83 @@
 +/*
 + * exynos_thermal_common.h - Samsung EXYNOS common header file
 + *
 + *  Copyright (C) 2013 Samsung Electronics
 + *  Amit Daniel Kachhap amit.dan...@samsung.com
 + *
 + * 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; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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
 + *
 + */
 +
 +#ifndef _EXYNOS_THERMAL_COMMON_H
 +#define _EXYNOS_THERMAL_COMMON_H
 +
 +/* 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
 +
 +/* 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
 +
 +struct   thermal_trip_point_conf {
 + int trip_val[MAX_TRIP_COUNT];
 + int trip_count;
 + unsigned char trigger_falling;
 +};
 +
 +struct   thermal_cooling_conf {
 + struct freq_clip_table freq_data[MAX_TRIP_COUNT];
 + int freq_clip_count;
 +};
 +
 +struct thermal_sensor_conf {
 + char name[SENSOR_NAME_LEN];
 + int (*read_temperature)(void *data);
 + int (*write_emul_temp)(void *drv_data, unsigned long temp);
 + struct thermal_trip_point_conf trip_data;
 + struct thermal_cooling_conf cooling_data;
 + void *private_data;
 +};
 +
 +/*Functions used exynos based thermal sensor driver*/
 +#ifdef CONFIG_EXYNOS_THERMAL_CORE
 +void exynos_unregister_thermal(void);
 +int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
 +void exynos_report_trigger(void);
 +#else
 +static inline void
 +exynos_unregister_thermal(void) { return; }
 +
 +static inline int
 +exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return 0; 
 }
 +
 +static inline void
 +exynos_report_trigger(void) { return; }
 +
 +#endif /* CONFIG_EXYNOS_THERMAL_CORE */
 +#endif /* _EXYNOS_THERMAL_COMMON_H */
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 06/30] thermal: exynos: Move exynos_thermal.h from include/* to driver/* folder

[Eduardo Valentin]

 include list of exynos_tmu.h (this file).

A part from this minor issue, you can add my acked:

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

   unsigned int freq_tab_count;
  };
 -#endif /* _LINUX_EXYNOS_THERMAL_H */
 +#endif /* _EXYNOS_TMU_H */
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 06/30] thermal: exynos: Move exynos_thermal.h from include/* to driver/* folder

[Eduardo Valentin]

On 19-06-2013 15:18, Eduardo Valentin wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch renames and moves include/linux/platform_data/exynos_thermal.h to
 drivers/thermal/samsung/exynos_tmu.h. This file movement is needed as exynos
 SOC's are not supporting non-DT based platforms and this file now just 
 contains
 exynos tmu driver related definations.
 Also struct freq_clip_table is now moved to exynos_thermal_common.c as it 
 fixes
 the compilation issue occuring because now this new tmu header file is 
 included
 in tmu driver c file and not in the common thermal header file.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.c|1 -
  drivers/thermal/samsung/exynos_thermal_common.h|   15 
  drivers/thermal/samsung/exynos_tmu.c   |2 +-
  .../thermal/samsung/exynos_tmu.h   |   24 
 ---
  4 files changed, 21 insertions(+), 21 deletions(-)
  rename include/linux/platform_data/exynos_thermal.h = 
 drivers/thermal/samsung/exynos_tmu.h (84%)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 92e50bc..dd49c9f 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -21,7 +21,6 @@
   */
  
  #include linux/cpu_cooling.h
 -#include linux/platform_data/exynos_thermal.h
  #include linux/slab.h
  #include linux/thermal.h
  
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index 8df1848..068f56c 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -44,6 +44,21 @@
  
  #define EXYNOS_ZONE_COUNT   3
  
 +/**
 + * struct freq_clip_table
 + * @freq_clip_max: maximum frequency allowed for this cooling state.
 + * @temp_level: Temperature level at which the temperature clipping will
 + *  happen.
 + * @mask_val: cpumask of the allowed cpu's where the clipping will take 
 place.
 + *
 + * This structure is required to be filled and passed to the
 + * cpufreq_cooling_unregister function.
 + */
 +struct freq_clip_table {
 +unsigned int freq_clip_max;
 +unsigned int temp_level;
 +const struct cpumask *mask_val;
 +};

Another minor: add an empty line here.

  struct  thermal_trip_point_conf {
  int trip_val[MAX_TRIP_COUNT];
  int trip_count;
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 22a8874..6aa2fd2 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -27,9 +27,9 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/platform_device.h
 -#include linux/platform_data/exynos_thermal.h
  
  #include exynos_thermal_common.h
 +#include exynos_tmu.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO 0x0
 diff --git a/include/linux/platform_data/exynos_thermal.h 
 b/drivers/thermal/samsung/exynos_tmu.h
 similarity index 84%
 rename from include/linux/platform_data/exynos_thermal.h
 rename to drivers/thermal/samsung/exynos_tmu.h
 index da7e627..9e0f887 100644
 --- a/include/linux/platform_data/exynos_thermal.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -1,8 +1,9 @@
  /*
 - * exynos_thermal.h - Samsung EXYNOS TMU (Thermal Management Unit)
 + * exynos_tmu.h - Samsung EXYNOS TMU (Thermal Management Unit)
   *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com
 + *  Amit Daniel Kachhap amit.dan...@samsung.com
   *
   * 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
 @@ -19,8 +20,8 @@
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
   */
  
 -#ifndef _LINUX_EXYNOS_THERMAL_H
 -#define _LINUX_EXYNOS_THERMAL_H
 +#ifndef _EXYNOS_TMU_H
 +#define _EXYNOS_TMU_H
  #include linux/cpu_cooling.h
  
  enum calibration_type {
 @@ -33,21 +34,6 @@ enum soc_type {
  SOC_ARCH_EXYNOS4210 = 1,
  SOC_ARCH_EXYNOS,
  };
 -/**
 - * struct freq_clip_table
 - * @freq_clip_max: maximum frequency allowed for this cooling state.
 - * @temp_level: Temperature level at which the temperature clipping will
 - *  happen.
 - * @mask_val: cpumask of the allowed cpu's where the clipping will take 
 place.
 - *
 - * This structure is required to be filled and passed to the
 - * cpufreq_cooling_unregister function.
 - */
 -struct freq_clip_table {
 -unsigned int freq_clip_max;
 -unsigned int temp_level;
 -const struct cpumask *mask_val;
 -};
  
  /**
   * struct exynos_tmu_platform_data
 @@ -116,4 +102,4 @@ struct exynos_tmu_platform_data {
  struct freq_clip_table freq_tab[4];
 
 Because you have this struct right here

Re: [PATCH V6 07/30] thermal: exynos: Bifurcate exynos tmu driver and configuration data

[Eduardo Valentin]

Rui,

On 17-06-2013 02:46, 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
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

This patch looks good to me, you may want to add my:

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/Kconfig   |3 +-
  drivers/thermal/samsung/Makefile  |1 +
  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, 125 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/Kconfig b/drivers/thermal/samsung/Kconfig
 index f8100b1..b653f15 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -5,7 +5,8 @@ config EXYNOS_THERMAL
 If you say yes here you get support for the TMU (Thermal Management
 Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
 the TMU, reports temperature and handles cooling action if defined.
 -   This driver uses the exynos core thermal API's.
 +   This driver uses the exynos core thermal API's and TMU configuration
 +   data from the supported soc's.
  
  config EXYNOS_THERMAL_CORE
   bool Core thermal framework support for EXYNOS SOC's
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index 22528d6..c09d830 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,4 +3,5 @@
  #
  obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
  exynos_thermal-y := exynos_tmu.o
 +exynos_thermal-y += exynos_tmu_data.o
  exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 6aa2fd2..5df04a1 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -30,6 +30,7 @@
  
  #include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include exynos_tmu_data.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -381,66 +382,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[] = {
   {
 @@ -449,11 +390,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

Re: [PATCH V6 07/30] thermal: exynos: Bifurcate exynos tmu driver and configuration data

[Eduardo Valentin]

On 19-06-2013 15:35, Eduardo Valentin wrote:
 Rui,
 
 On 17-06-2013 02:46, 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
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 
 This patch looks good to me, you may want to add my:
 
 Acked-by: Eduardo Valentin eduardo.valen...@ti.com

Yet another minor before adding my ack, sorry this one almost fell into
the cracks (see below):

 
 ---
  drivers/thermal/samsung/Kconfig   |3 +-
  drivers/thermal/samsung/Makefile  |1 +
  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, 125 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/Kconfig 
 b/drivers/thermal/samsung/Kconfig
 index f8100b1..b653f15 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -5,7 +5,8 @@ config EXYNOS_THERMAL
If you say yes here you get support for the TMU (Thermal Management
Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
the TMU, reports temperature and handles cooling action if defined.
 -  This driver uses the exynos core thermal API's.
 +  This driver uses the exynos core thermal API's and TMU configuration
 +  data from the supported soc's.
  
  config EXYNOS_THERMAL_CORE
  bool Core thermal framework support for EXYNOS SOC's
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index 22528d6..c09d830 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,4 +3,5 @@
  #
  obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
  exynos_thermal-y:= exynos_tmu.o
 +exynos_thermal-y+= exynos_tmu_data.o
  exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+= 
 exynos_thermal_common.o
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 6aa2fd2..5df04a1 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -30,6 +30,7 @@
  
  #include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include exynos_tmu_data.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO 0x0
 @@ -381,66 +382,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[] = {
  {
 @@ -449,11 +390,11 @@ static const struct of_device_id exynos_tmu_match[] = {
  },
  {
  .compatible = samsung,exynos4412-tmu,
 -.data = (void *)EXYNOS_TMU_DRV_DATA,
 +.data

Re: [PATCH V6 08/30] thermal: exynos: Add missing definations and code cleanup

[Eduardo Valentin]

 |=
 + interrupt_en  EXYNOS_TMU_INTEN_FALL0_SHIFT;
   } else {
 - con |= EXYNOS_TMU_CORE_OFF;
 + con = ~(1  EXYNOS_TMU_CORE_EN_SHIFT);


Before, in order to turno core off you had:
con = con | 2;

now you do:
con = con  ~(1  0);

To me, before you would set bit 2, now you clear bit 0.

Using the approach on this patch looks correct to me if you have 1 bit
core_en for instance.

so, Is this a fix?

Just to be clear, is this what you want ?

   interrupt_en = 0; /* Disable all interrupts */
   }
   writel(interrupt_en, data-base + EXYNOS_TMU_REG_INTEN);
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V2] thermal: exynos: Support for TMU regulator defined at device tree

[Eduardo Valentin]

On 02-05-2013 06:18, Amit Daniel Kachhap wrote:
 TMU probe function now checks for a device tree defined regulator.
 For compatibility reasons it is allowed to probe driver even without
 this regulator defined.
 
 Signed-off-by: Luk asz Majewski l.majew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

I assume this one got superseeded by the same patch on your 30 patch
series, right?
https://patchwork.kernel.org/patch/2731031/


 ---
 
 Changes in V2:
 * Added log message in regulator_get failure as suggested by Sylwester.
 * Used IS_ERR for checking regulator pointer as suggested by Sylwester.
 
 This patch is repost of the patch posted by Lukasz Majewski
 (https://patchwork.kernel.org/patch/2488211/). I have rebased this
 patch on top of my TMU re-structured patch series
 (http://lwn.net/Articles/548634/). Although I thought of handling
 regulator as one type of feature (newly added) but could not do
 so as regulator is a board/platform property and not SOC property so
 leaving the device tree to define and handle it.
 
  .../devicetree/bindings/thermal/exynos-thermal.txt |4 
  drivers/thermal/samsung/exynos_tmu.c   |   19 +++
  2 files changed, 23 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index 970eeba..ff62f7a 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -14,6 +14,9 @@
  - interrupts : Should contain interrupt for thermal system
  - clocks : The main clock for TMU device
  - clock-names : Thermal system clock name
 +- vtmu-supply: This entry is optional and provides the regulator node 
 supplying
 + voltage to TMU. If needed this entry can be placed inside
 + board/platform specific dts file.
  
  Example 1):
  
 @@ -25,6 +28,7 @@ Example 1):
   clocks = clock 383;
   clock-names = tmu_apbif;
   status = disabled;
 + vtmu-supply = tmu_regulator_node;
   };
  
  Example 2):
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 72446c9..b7c609a 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -32,6 +32,7 @@
  #include linux/of_address.h
  #include linux/of_irq.h
  #include linux/platform_device.h
 +#include linux/regulator/consumer.h
  #include linux/slab.h
  #include linux/workqueue.h
  #include exynos_thermal_common.h
 @@ -52,6 +53,7 @@
   * @clk: pointer to the clock structure.
   * @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.
   * @reg_conf: pointer to structure to register with core thermal.
   */
  struct exynos_tmu_data {
 @@ -65,6 +67,7 @@ struct exynos_tmu_data {
   struct mutex lock;
   struct clk *clk;
   u8 temp_error1, temp_error2;
 + struct regulator *regulator;
   struct thermal_sensor_conf *reg_conf;
  };
  
 @@ -501,10 +504,23 @@ static int exynos_map_dt_data(struct platform_device 
 *pdev)
   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
   struct exynos_tmu_platform_data *pdata = data-pdata;
   struct resource res;
 + int ret;
  
   if (!data)
   return -ENODEV;
  
 + /* Try enabling the regulator if found */
 + data-regulator = devm_regulator_get(pdev-dev, vtmu);
 + if (!IS_ERR(data-regulator)) {
 + ret = regulator_enable(data-regulator);
 + if (ret) {
 + dev_err(pdev-dev, failed to enable vtmu\n);
 + return ret;
 + }
 + } else {
 + dev_info(pdev-dev, Regulator node (vtmu) not found\n);
 + }
 +
   data-id = of_alias_get_id(pdev-dev.of_node, tmuctrl);
   if (data-id  0)
   data-id = 0;
 @@ -669,6 +685,9 @@ static int exynos_tmu_remove(struct platform_device *pdev)
  
   clk_unprepare(data-clk);
  
 + if (!IS_ERR(data-regulator))
 + regulator_disable(data-regulator);
 +
   platform_set_drvdata(pdev, NULL);
  
   return 0;
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 09/30] thermal: exynos: Add extra entries in the tmu platform data

[Eduardo Valentin]

 exynos_tmu.h
 +#include exynos_tmu_data.h

This change needs to be moved to the patch that you added this file.
Check comment on patch 07/30.
  
  #if defined(CONFIG_CPU_EXYNOS4210)
  struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
 @@ -29,13 +30,22 @@ struct exynos_tmu_platform_data const 
 exynos4210_default_tmu_data = {
   .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,
 + .trigger_enable[0] = 1,
 + .trigger_enable[1] = 1,
 + .trigger_enable[2] = 1,
 + .trigger_enable[3] = 0,
 + .trigger_type[0] = THROTTLE_ACTIVE,
 + .trigger_type[1] = THROTTLE_ACTIVE,
 + .trigger_type[2] = SW_TRIP,

is there any issues if trigger_type[3] is 0? there is no defined value
for 0. (0 means undefined on your enum definition).


 + .max_trigger_level = 4,
   .gain = 15,
   .reference_voltage = 7,
   .cal_type = TYPE_ONE_POINT_TRIMMING,
 + .min_efuse_value = 40,
 + .max_efuse_value = 100,
 + .first_point_trim = 25,
 + .second_point_trim = 85,
 + .default_temp_offset = 50,
   .freq_tab[0] = {
   .freq_clip_max = 800 * 1000,
   .temp_level = 85,
 @@ -55,15 +65,24 @@ struct exynos_tmu_platform_data const 
 exynos5250_default_tmu_data = {
   .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,
 + .trigger_enable[0] = 1,
 + .trigger_enable[1] = 1,
 + .trigger_enable[2] = 1,
 + .trigger_enable[3] = 0,
 + .trigger_type[0] = THROTTLE_ACTIVE,
 + .trigger_type[1] = THROTTLE_ACTIVE,
 + .trigger_type[2] = SW_TRIP,
 + .max_trigger_level = 4,
   .gain = 8,
   .reference_voltage = 16,
   .noise_cancel_mode = 4,
   .cal_type = TYPE_ONE_POINT_TRIMMING,
   .efuse_value = 55,
 + .min_efuse_value = 40,
 + .max_efuse_value = 100,
 + .first_point_trim = 25,
 + .second_point_trim = 85,
 + .default_temp_offset = 50,
   .freq_tab[0] = {
   .freq_clip_max = 800 * 1000,
   .temp_level = 85,
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 09/30] thermal: exynos: Add extra entries in the tmu platform data

[Eduardo Valentin]

On 19-06-2013 16:19, Eduardo Valentin wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds entries min_efuse_value, max_efuse_value, 
 default_temp_offset,
 trigger_type, cal_type, trim_first_point, trim_second_point, 
 max_trigger_level
 trigger_enable in the TMU platform data structure. Also the driver is 
 modified
 to use the data passed by these new platform memebers instead of the constant
 macros. All these changes helps in separating the SOC specific data part from
 the TMU driver.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.h |7 +++
  drivers/thermal/samsung/exynos_tmu.c|   43 ++--
  drivers/thermal/samsung/exynos_tmu.h|   49 
 ++
  drivers/thermal/samsung/exynos_tmu_data.c   |   35 
  4 files changed, 86 insertions(+), 48 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index 068f56c..fd789a5 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -44,6 +44,13 @@
  
  #define EXYNOS_ZONE_COUNT   3
  
 +enum trigger_type {
 +THROTTLE_ACTIVE = 1,
 +THROTTLE_PASSIVE,
 +SW_TRIP,
 +HW_TRIP,
 +};
 +
  /**
   * struct freq_clip_table
   * @freq_clip_max: maximum frequency allowed for this cooling state.
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index fa33a48..401ec98 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -49,7 +49,6 @@
  #define EXYNOS_TMU_BUF_SLOPE_SEL_MASK   0xf
  #define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT  8
  #define EXYNOS_TMU_CORE_EN_SHIFT0
 -#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET  50
  
  /* Exynos4210 specific registers */
  #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP   0x44
 @@ -94,9 +93,6 @@
  #define EXYNOS_TMU_INTEN_FALL1_SHIFT20
  #define EXYNOS_TMU_INTEN_FALL2_SHIFT24
  
 -#define EFUSE_MIN_VALUE 40
 -#define EFUSE_MAX_VALUE 100
 -
  #ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME0x57F0
  #define EXYNOS_EMUL_TIME_MASK   0x
 @@ -136,15 +132,16 @@ static int temp_to_code(struct exynos_tmu_data *data, 
 u8 temp)
  
  switch (pdata-cal_type) {
  case TYPE_TWO_POINT_TRIMMING:
 -temp_code = (temp - 25) *
 -(data-temp_error2 - data-temp_error1) /
 -(85 - 25) + data-temp_error1;
 +temp_code = (temp - pdata-first_point_trim) *
 +(data-temp_error2 - data-temp_error1) /
 +(pdata-second_point_trim - pdata-first_point_trim) +
 +data-temp_error1;
  break;
  case TYPE_ONE_POINT_TRIMMING:
 -temp_code = temp + data-temp_error1 - 25;
 +temp_code = temp + data-temp_error1 - pdata-first_point_trim;
  break;
  default:
 -temp_code = temp + EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
 +temp_code = temp + pdata-default_temp_offset;
  break;
  }
  out:
 @@ -169,14 +166,16 @@ static int code_to_temp(struct exynos_tmu_data *data, 
 u8 temp_code)
  
  switch (pdata-cal_type) {
  case TYPE_TWO_POINT_TRIMMING:
 -temp = (temp_code - data-temp_error1) * (85 - 25) /
 -(data-temp_error2 - data-temp_error1) + 25;
 +temp = (temp_code - data-temp_error1) *
 +(pdata-second_point_trim - pdata-first_point_trim) /
 +(data-temp_error2 - data-temp_error1) +
 +pdata-first_point_trim;
  break;
  case TYPE_ONE_POINT_TRIMMING:
 -temp = temp_code - data-temp_error1 + 25;
 +temp = temp_code - data-temp_error1 + pdata-first_point_trim;
  break;
  default:
 -temp = temp_code - EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
 +temp = temp_code - pdata-default_temp_offset;
  break;
  }
  out:
 @@ -209,8 +208,8 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
  data-temp_error1 = trim_info  EXYNOS_TMU_TRIM_TEMP_MASK;
  data-temp_error2 = ((trim_info  8)  EXYNOS_TMU_TRIM_TEMP_MASK);
  
 -if ((EFUSE_MIN_VALUE  data-temp_error1) ||
 -(data-temp_error1  EFUSE_MAX_VALUE) ||
 +if ((pdata-min_efuse_value  data-temp_error1) ||
 +(data-temp_error1  pdata-max_efuse_value) ||
  (data-temp_error2 != 0))
  data-temp_error1 = pdata-efuse_value;
  
 @@ -300,10 +299,10 @@ static void exynos_tmu_control(struct platform_device 
 *pdev, bool on)
  if (on) {
  con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
  interrupt_en =
 -pdata-trigger_level3_en

Re: [PATCH V6 10/30] thermal: exynos: Move register definitions from driver to data file

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch migrates the TMU register definition/bitfields to data file. This
 is needed to support SoC's which use the same TMU controller but register
 validity, offsets or bitfield may slightly vary across SOC's.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_tmu.c  |  172 +---
  drivers/thermal/samsung/exynos_tmu.h  |  133 ++
  drivers/thermal/samsung/exynos_tmu_data.c |   59 ++
  drivers/thermal/samsung/exynos_tmu_data.h |   68 +++
  4 files changed, 315 insertions(+), 117 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 401ec98..6fd776f 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -32,76 +32,6 @@
  #include exynos_tmu.h
  #include exynos_tmu_data.h
  
 -/* Exynos generic registers */
 -#define EXYNOS_TMU_REG_TRIMINFO  0x0
 -#define EXYNOS_TMU_REG_CONTROL   0x20
 -#define EXYNOS_TMU_REG_STATUS0x28
 -#define EXYNOS_TMU_REG_CURRENT_TEMP  0x40
 -#define EXYNOS_TMU_REG_INTEN 0x70
 -#define EXYNOS_TMU_REG_INTSTAT   0x74
 -#define EXYNOS_TMU_REG_INTCLEAR  0x78
 -
 -#define EXYNOS_TMU_TRIM_TEMP_MASK0xff
 -#define EXYNOS_TMU_GAIN_SHIFT8
 -#define EXYNOS_TMU_GAIN_MASK 0xf
 -#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
 -#define EXYNOS_TMU_REF_VOLTAGE_MASK  0x1f
 -#define EXYNOS_TMU_BUF_SLOPE_SEL_MASK0xf
 -#define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT   8
 -#define EXYNOS_TMU_CORE_EN_SHIFT 0
 -
 -/* Exynos4210 specific registers */
 -#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44
 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL0   0x50
 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL1   0x54
 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL2   0x58
 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL3   0x5C
 -#define EXYNOS4210_TMU_REG_PAST_TEMP00x60
 -#define EXYNOS4210_TMU_REG_PAST_TEMP10x64
 -#define EXYNOS4210_TMU_REG_PAST_TEMP20x68
 -#define EXYNOS4210_TMU_REG_PAST_TEMP30x6C
 -
 -#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK  0x1
 -#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK  0x10
 -#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK  0x100
 -#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK  0x1000
 -#define EXYNOS4210_TMU_TRIG_LEVEL_MASK   0x
 -#define EXYNOS4210_TMU_INTCLEAR_VAL  0x
 -
 -/* Exynos5250 and Exynos4412 specific registers */
 -#define EXYNOS_TMU_TRIMINFO_CON  0x14
 -#define EXYNOS_THD_TEMP_RISE 0x50
 -#define EXYNOS_THD_TEMP_FALL 0x54
 -#define EXYNOS_EMUL_CON  0x80
 -
 -#define EXYNOS_TRIMINFO_RELOAD   0x1
 -#define EXYNOS_TRIMINFO_SHIFT0x0
 -#define EXYNOS_TMU_RISE_INT_MASK 0x111
 -#define EXYNOS_TMU_RISE_INT_SHIFT0
 -#define EXYNOS_TMU_FALL_INT_MASK 0x111
 -#define EXYNOS_TMU_FALL_INT_SHIFT12
 -#define EXYNOS_TMU_CLEAR_RISE_INT0x111
 -#define EXYNOS_TMU_CLEAR_FALL_INT(0x111  12)
 -#define EXYNOS_TMU_TRIP_MODE_SHIFT   13
 -#define EXYNOS_TMU_TRIP_MODE_MASK0x7
 -
 -#define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
 -#define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
 -#define EXYNOS_TMU_INTEN_RISE2_SHIFT 8
 -#define EXYNOS_TMU_INTEN_RISE3_SHIFT 12
 -#define EXYNOS_TMU_INTEN_FALL0_SHIFT 16
 -#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20
 -#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24
 -
 -#ifdef CONFIG_THERMAL_EMULATION
 -#define EXYNOS_EMUL_TIME 0x57F0
 -#define EXYNOS_EMUL_TIME_MASK0x
 -#define EXYNOS_EMUL_TIME_SHIFT   16
 -#define EXYNOS_EMUL_DATA_SHIFT   8
 -#define EXYNOS_EMUL_DATA_MASK0xFF
 -#define EXYNOS_EMUL_ENABLE   0x1
 -#endif /* CONFIG_THERMAL_EMULATION */
 -
  struct exynos_tmu_data {
   struct exynos_tmu_platform_data *pdata;
   struct resource *mem;
 @@ -186,6 +116,7 @@ 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;
 + const struct exynos_tmu_registers *reg = pdata-registers;
   unsigned int status, trim_info;
   unsigned int rising_threshold = 0, falling_threshold = 0;
   int ret = 0, threshold_code, i, trigger_levs = 0;
 @@ -193,20 +124,20 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   mutex_lock(data-lock);
   clk_enable(data-clk);
  
 - status = readb(data-base + EXYNOS_TMU_REG_STATUS);
 + status = readb(data-base + reg-tmu_status);
   if (!status) {
   ret = -EBUSY;
   goto out;
   }
  
 - if (data-soc == SOC_ARCH_EXYNOS) {
 - __raw_writel(EXYNOS_TRIMINFO_RELOAD

Re: [PATCH V6 11/30] thermal: exynos: Support thermal tripping

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 TMU urgently sends active-high signal (thermal trip) to PMU, and thermal
 tripping by hardware logic. Thermal tripping means that PMU cuts off the
 whole power of SoC by controlling external voltage regulator.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_tmu.c  |   45 +---
  drivers/thermal/samsung/exynos_tmu_data.c |2 +
  drivers/thermal/samsung/exynos_tmu_data.h |2 +
  3 files changed, 44 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 6fd776f..33f494e 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -117,7 +117,7 @@ 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;
   const struct exynos_tmu_registers *reg = pdata-registers;
 - unsigned int status, trim_info;
 + unsigned int status, trim_info = 0, con;
   unsigned int rising_threshold = 0, falling_threshold = 0;
   int ret = 0, threshold_code, i, trigger_levs = 0;
  
 @@ -144,10 +144,26 @@ 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])
 + if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
 + dev_err(pdev-dev, Invalid max trigger level\n);
 + goto out;
 + }
 +
 + for (i = 0; i  pdata-max_trigger_level; i++) {
 + if (!pdata-trigger_levels[i])
 + continue;
 +
 + if ((pdata-trigger_type[i] == HW_TRIP) 
 + (!pdata-trigger_levels[pdata-max_trigger_level - 1])) {
 + dev_err(pdev-dev, Invalid hw trigger level\n);
 + ret = -EINVAL;
 + goto out;
 + }
 +
 + /* Count trigger levels except the HW trip*/
 + if (!(pdata-trigger_type[i] == HW_TRIP))
   trigger_levs++;
 + }
  
   if (data-soc == SOC_ARCH_EXYNOS4210) {
   /* Write temperature code for threshold */
 @@ -165,7 +181,8 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
   } else if (data-soc == SOC_ARCH_EXYNOS) {
   /* Write temperature code for rising and falling threshold */
 - for (i = 0; i  trigger_levs; i++) {
 + for (i = 0;
 + i  trigger_levs  i  EXYNOS_MAX_TRIGGER_PER_REG; i++) {
   threshold_code = temp_to_code(data,
   pdata-trigger_levels[i]);
   if (threshold_code  0) {
 @@ -191,6 +208,24 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   writel((reg-inten_rise_mask  reg-inten_rise_shift) |
   (reg-inten_fall_mask  reg-inten_fall_shift),
   data-base + reg-tmu_intclear);
 +
 + /* if last threshold limit is also present */
 + i = pdata-max_trigger_level - 1;
 + if (pdata-trigger_levels[i] 
 + (pdata-trigger_type[i] == HW_TRIP)) {
 + threshold_code = temp_to_code(data,
 + pdata-trigger_levels[i]);
 + if (threshold_code  0) {
 + ret = threshold_code;
 + goto out;
 + }
 + rising_threshold |= threshold_code  8 * i;
 + writel(rising_threshold,
 + data-base + reg-threshold_th0);
 + con = readl(data-base + reg-tmu_ctrl);
 + con |= (1  reg-therm_trip_en_shift);
 + writel(con, data-base + reg-tmu_ctrl);
 + }
   }
  out:
   clk_disable(data-clk);
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index 589a519..e7cb1cc 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -123,6 +123,7 @@ struct exynos_tmu_platform_data const 
 exynos5250_default_tmu_data = {
   .trigger_levels[0] = 85,
   .trigger_levels[1] = 103,
   .trigger_levels[2] = 110,
 + .trigger_levels[3] = 120,
   .trigger_enable[0] = 1

Re: [PATCH V6 12/30] thermal: exynos: Fix to clear only the generated interrupts

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch uses the TMU status register to know the generated interrupts
 and only clear them in the interrupt handler.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

  drivers/thermal/samsung/exynos_tmu.c  |   11 +--
  drivers/thermal/samsung/exynos_tmu_data.c |2 ++
  2 files changed, 7 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 33f494e..f6f63ca 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -351,17 +351,16 @@ static void exynos_tmu_work(struct work_struct *work)
   struct exynos_tmu_data, irq_work);
   struct exynos_tmu_platform_data *pdata = data-pdata;
   const struct exynos_tmu_registers *reg = pdata-registers;
 + unsigned int val_irq;
  
   exynos_report_trigger();
   mutex_lock(data-lock);
   clk_enable(data-clk);
  
 - if (data-soc == SOC_ARCH_EXYNOS)
 - writel((reg-inten_rise_mask  reg-inten_rise_shift) |
 - (reg-inten_fall_mask  reg-inten_fall_shift),
 - data-base + reg-tmu_intclear);
 - else
 - writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
 + /* TODO: take action based on particular interrupt */
 + val_irq = readl(data-base + reg-tmu_intstat);
 + /* clear the interrupts */
 + writel(val_irq, data-base + reg-tmu_intclear);
  
   clk_disable(data-clk);
   mutex_unlock(data-lock);
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index e7cb1cc..7fcf183 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -45,6 +45,7 @@ static const struct exynos_tmu_registers 
 exynos4210_tmu_registers = {
   .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
   .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
   .inten_rise3_shift = EXYNOS_TMU_INTEN_RISE3_SHIFT,
 + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
  };
  struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
 @@ -112,6 +113,7 @@ static const struct exynos_tmu_registers 
 exynos5250_tmu_registers = {
   .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
   .inten_rise3_shift = EXYNOS_TMU_INTEN_RISE3_SHIFT,
   .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
 + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
   .emul_con = EXYNOS_EMUL_CON,
   .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 13/30] thermal: exynos: Add support for instance based register/unregister

[Eduardo Valentin]

Hi,

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This code modifies the thermal driver to have multiple thermal zone
 support by replacing the global thermal zone variable with device data
 member of thermal_zone_device.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_thermal_common.c |   36 ++
  drivers/thermal/samsung/exynos_thermal_common.h |9 +++--
  drivers/thermal/samsung/exynos_tmu.c|   15 +
  3 files changed, 36 insertions(+), 24 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index dd49c9f..2af1e3b 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -36,12 +36,11 @@ struct exynos_thermal_zone {
   bool bind;
  };
  
 -static struct exynos_thermal_zone *th_zone;
 -
  /* Get mode callback functions for thermal zone */
  static int exynos_get_mode(struct thermal_zone_device *thermal,
   enum thermal_device_mode *mode)
  {
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
   if (th_zone)
   *mode = th_zone-mode;
   return 0;
 @@ -51,25 +50,26 @@ static int exynos_get_mode(struct thermal_zone_device 
 *thermal,
  static int exynos_set_mode(struct thermal_zone_device *thermal,
   enum thermal_device_mode mode)
  {
 - if (!th_zone-therm_dev) {
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
 + if (!th_zone) {
   pr_notice(thermal zone not registered\n);
   return 0;
   }
  
 - mutex_lock(th_zone-therm_dev-lock);
 + mutex_lock(thermal-lock);
  
   if (mode == THERMAL_DEVICE_ENABLED 
   !th_zone-sensor_conf-trip_data.trigger_falling)
 - th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
 + thermal-polling_delay = IDLE_INTERVAL;
   else
 - th_zone-therm_dev-polling_delay = 0;
 + thermal-polling_delay = 0;
  
 - mutex_unlock(th_zone-therm_dev-lock);
 + mutex_unlock(thermal-lock);
  
   th_zone-mode = mode;
 - thermal_zone_device_update(th_zone-therm_dev);
 + thermal_zone_device_update(thermal);
   pr_info(thermal polling set for duration=%d msec\n,
 - th_zone-therm_dev-polling_delay);
 + thermal-polling_delay);
   return 0;
  }
  
 @@ -96,6 +96,8 @@ static int exynos_get_trip_type(struct thermal_zone_device 
 *thermal, int trip,
  static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int 
 trip,
   unsigned long *temp)
  {
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
 +
   if (trip  GET_TRIP(MONITOR_ZONE) || trip  GET_TRIP(PANIC_ZONE))
   return -EINVAL;
  
 @@ -122,6 +124,7 @@ static int exynos_bind(struct thermal_zone_device 
 *thermal,
  {
   int ret = 0, i, tab_size, level;
   struct freq_clip_table *tab_ptr, *clip_data;
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
   struct thermal_sensor_conf *data = th_zone-sensor_conf;
  
   tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
 @@ -168,6 +171,7 @@ static int exynos_unbind(struct thermal_zone_device 
 *thermal,
   struct thermal_cooling_device *cdev)
  {
   int ret = 0, i, tab_size;
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
   struct thermal_sensor_conf *data = th_zone-sensor_conf;
  
   if (th_zone-bind == false)
 @@ -210,6 +214,7 @@ static int exynos_unbind(struct thermal_zone_device 
 *thermal,
  static int exynos_get_temp(struct thermal_zone_device *thermal,
   unsigned long *temp)
  {
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
   void *data;
  
   if (!th_zone-sensor_conf) {
 @@ -229,6 +234,7 @@ static int exynos_set_emul_temp(struct 
 thermal_zone_device *thermal,
  {
   void *data;
   int ret = -EINVAL;
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
  
   if (!th_zone-sensor_conf) {
   pr_info(Temperature sensor not initialised\n);
 @@ -276,11 +282,12 @@ static struct thermal_zone_device_ops const 
 exynos_dev_ops = {
   * This function may be called from interrupt based temperature sensor
   * when threshold is changed.
   */
 -void exynos_report_trigger(void)
 +void exynos_report_trigger(struct thermal_sensor_conf *conf)
  {
   unsigned int i;
   char data[10];
   char *envp[] = { data, NULL };
 + struct exynos_thermal_zone *th_zone = conf-pzone_data;
  
   if (!th_zone || !th_zone-therm_dev)
   return;
 @@ -321,6 +328,7 @@ int exynos_register_thermal(struct thermal_sensor_conf

Re: [PATCH V6 14/30] thermal: exynos: Modify private_data to appropriate name driver_data

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch renames member private_data to driver_data of the thermal
 zone registration structure as this item stores the driver related
 data and uses it to call the driver related callbacks.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
  drivers/thermal/samsung/exynos_thermal_common.h |2 +-
  drivers/thermal/samsung/exynos_tmu.c|2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 2af1e3b..7064eb7 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -221,7 +221,7 @@ static int exynos_get_temp(struct thermal_zone_device 
 *thermal,
   pr_info(Temperature sensor not initialised\n);
   return -EINVAL;
   }
 - data = th_zone-sensor_conf-private_data;
 + data = th_zone-sensor_conf-driver_data;
   *temp = th_zone-sensor_conf-read_temperature(data);
   /* convert the temperature into millicelsius */
   *temp = *temp * MCELSIUS;
 @@ -240,7 +240,7 @@ static int exynos_set_emul_temp(struct 
 thermal_zone_device *thermal,
   pr_info(Temperature sensor not initialised\n);
   return -EINVAL;
   }
 - data = th_zone-sensor_conf-private_data;
 + data = th_zone-sensor_conf-driver_data;
   if (th_zone-sensor_conf-write_emul_temp)
   ret = th_zone-sensor_conf-write_emul_temp(data, temp);
   return ret;
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index a845c2d..1e9a326 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -83,7 +83,7 @@ struct thermal_sensor_conf {
   int (*write_emul_temp)(void *drv_data, unsigned long temp);
   struct thermal_trip_point_conf trip_data;
   struct thermal_cooling_conf cooling_data;
 - void *private_data;
 + void *driver_data;
   void *pzone_data;
  };
  
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index a7bba69..40e0cfd 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -504,7 +504,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   exynos_tmu_control(pdev, true);
  
   /* Register the sensor with thermal management interface */
 - (exynos_sensor_conf)-private_data = data;
 + (exynos_sensor_conf)-driver_data = data;
   exynos_sensor_conf.trip_data.trip_count = pdata-trigger_enable[0] +
   pdata-trigger_enable[1] + pdata-trigger_enable[2]+
   pdata-trigger_enable[3];
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 15/30] thermal: exynos: Return success even if no cooling data supplied

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch removes the error return in the bind/unbind routine
 as the platform may not register any cpufreq cooling data.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 7064eb7..86d39aa 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -131,7 +131,7 @@ static int exynos_bind(struct thermal_zone_device 
 *thermal,
   tab_size = data-cooling_data.freq_clip_count;
  
   if (tab_ptr == NULL || tab_size == 0)
 - return -EINVAL;
 + return 0;
  
   /* find the cooling device registered*/
   for (i = 0; i  th_zone-cool_dev_size; i++)
 @@ -180,7 +180,7 @@ static int exynos_unbind(struct thermal_zone_device 
 *thermal,
   tab_size = data-cooling_data.freq_clip_count;
  
   if (tab_size == 0)
 - return -EINVAL;
 + return 0;
  
   /* find the cooling device registered*/
   for (i = 0; i  th_zone-cool_dev_size; i++)
 

I have one question before acking this one: what happens if one
registers a TMU with no freq tab? Say the case where you have three
sensors, just like SOC_ARCH_EXYNOS5440. Would you register
cpufreq_cooling device for all of them? In other way, are you having 3
cpufreq_cooling devices?


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 16/30] thermal: exynos: Make the zone handling use trip information

[Eduardo Valentin]

 thermal zone device\n);
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index 1e9a326..dd0077e 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -42,8 +42,6 @@
  #define GET_ZONE(trip) (trip + 2)
  #define GET_TRIP(zone) (zone - 2)
  
 -#define EXYNOS_ZONE_COUNT3
 -
  enum trigger_type {
   THROTTLE_ACTIVE = 1,
   THROTTLE_PASSIVE,
 @@ -68,6 +66,7 @@ struct freq_clip_table {
  };
  struct   thermal_trip_point_conf {
   int trip_val[MAX_TRIP_COUNT];
 + int trip_type[MAX_TRIP_COUNT];
   int trip_count;
   unsigned char trigger_falling;
  };
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 40e0cfd..acbd295 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -509,9 +509,12 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   pdata-trigger_enable[1] + pdata-trigger_enable[2]+
   pdata-trigger_enable[3];
  
 - for (i = 0; i  exynos_sensor_conf.trip_data.trip_count; i++)
 + for (i = 0; i  exynos_sensor_conf.trip_data.trip_count; i++) {
   exynos_sensor_conf.trip_data.trip_val[i] =
   pdata-threshold + pdata-trigger_levels[i];
 + exynos_sensor_conf.trip_data.trip_type[i] =
 + pdata-trigger_type[i];
 + }
  
   exynos_sensor_conf.trip_data.trigger_falling = pdata-threshold_falling;
  
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 15/30] thermal: exynos: Return success even if no cooling data supplied

[Eduardo Valentin]

On 19-06-2013 18:54, Eduardo Valentin wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch removes the error return in the bind/unbind routine
 as the platform may not register any cpufreq cooling data.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 7064eb7..86d39aa 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -131,7 +131,7 @@ static int exynos_bind(struct thermal_zone_device 
 *thermal,
  tab_size = data-cooling_data.freq_clip_count;
  
  if (tab_ptr == NULL || tab_size == 0)
 -return -EINVAL;
 +return 0;
  
  /* find the cooling device registered*/
  for (i = 0; i  th_zone-cool_dev_size; i++)
 @@ -180,7 +180,7 @@ static int exynos_unbind(struct thermal_zone_device 
 *thermal,
  tab_size = data-cooling_data.freq_clip_count;
  
  if (tab_size == 0)
 -return -EINVAL;
 +return 0;
  
  /* find the cooling device registered*/
  for (i = 0; i  th_zone-cool_dev_size; i++)

 
 I have one question before acking this one: what happens if one
 registers a TMU with no freq tab? Say the case where you have three
 sensors, just like SOC_ARCH_EXYNOS5440. Would you register
 cpufreq_cooling device for all of them? In other way, are you having 3
 cpufreq_cooling devices?

I am actually fine with this patch. just saw that you adjust things on
patch 16.

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 17/30] thermal: exynos: Remove non DT based support

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 Recently non DT support from Exynos platform is removed and hence
 removing non DT support from the driver also. This will help in easy
 maintainence.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_tmu.c |   17 +
  1 files changed, 1 insertions(+), 16 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index acbd295..4356118 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -403,19 +403,6 @@ static const struct of_device_id exynos_tmu_match[] = {
  MODULE_DEVICE_TABLE(of, exynos_tmu_match);
  #endif
  
 -static struct platform_device_id exynos_tmu_driver_ids[] = {
 - {
 - .name   = exynos4210-tmu,
 - .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
 - },
 - {
 - .name   = exynos5250-tmu,
 - .driver_data= (kernel_ulong_t)EXYNOS5250_TMU_DRV_DATA,
 - },
 - { },
 -};
 -MODULE_DEVICE_TABLE(platform, exynos_tmu_driver_ids);
 -
  static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
   struct platform_device *pdev)
  {
 @@ -428,8 +415,7 @@ static inline struct  exynos_tmu_platform_data 
 *exynos_get_driver_data(
   return (struct exynos_tmu_platform_data *) match-data;
   }
  #endif
 - return (struct exynos_tmu_platform_data *)
 - platform_get_device_id(pdev)-driver_data;
 + return NULL;
  }
  
  static int exynos_tmu_probe(struct platform_device *pdev)
 @@ -586,7 +572,6 @@ static struct platform_driver exynos_tmu_driver = {
   },
   .probe = exynos_tmu_probe,
   .remove = exynos_tmu_remove,
 - .id_table = exynos_tmu_driver_ids,
  };
  
  module_platform_driver(exynos_tmu_driver);
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 18/30] thermal: exynos: Add support to handle many instances of TMU

[Eduardo Valentin]

,
 + },
   },
 - .freq_tab_count = 2,
 - .type = SOC_ARCH_EXYNOS4210,
 - .registers = exynos4210_tmu_registers,
 + .tmu_count = 1,
  };
  #endif
  
 @@ -120,41 +126,48 @@ static const struct exynos_tmu_registers 
 exynos5250_tmu_registers = {
   .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
   .emul_time_mask = EXYNOS_EMUL_TIME_MASK,
  };
 -struct exynos_tmu_platform_data const exynos5250_default_tmu_data = {
 - .threshold_falling = 10,
 - .trigger_levels[0] = 85,
 - .trigger_levels[1] = 103,
 - .trigger_levels[2] = 110,
 - .trigger_levels[3] = 120,
 - .trigger_enable[0] = 1,
 - .trigger_enable[1] = 1,
 - .trigger_enable[2] = 1,
 - .trigger_enable[3] = 0,
 - .trigger_type[0] = THROTTLE_ACTIVE,
 - .trigger_type[1] = THROTTLE_ACTIVE,
 - .trigger_type[2] = SW_TRIP,
 - .trigger_type[3] = HW_TRIP,
 - .max_trigger_level = 4,
 - .gain = 8,
 - .reference_voltage = 16,
 - .noise_cancel_mode = 4,
 - .cal_type = TYPE_ONE_POINT_TRIMMING,
 - .efuse_value = 55,
 - .min_efuse_value = 40,
 - .max_efuse_value = 100,
 - .first_point_trim = 25,
 - .second_point_trim = 85,
 - .default_temp_offset = 50,
 - .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 EXYNOS5250_TMU_DATA \
 + .threshold_falling = 10, \
 + .trigger_levels[0] = 85, \
 + .trigger_levels[1] = 103, \
 + .trigger_levels[2] = 110, \
 + .trigger_levels[3] = 120, \
 + .trigger_enable[0] = 1, \
 + .trigger_enable[1] = 1, \
 + .trigger_enable[2] = 1, \
 + .trigger_enable[3] = 0, \
 + .trigger_type[0] = THROTTLE_ACTIVE, \
 + .trigger_type[1] = THROTTLE_ACTIVE, \
 + .trigger_type[2] = SW_TRIP, \
 + .trigger_type[3] = HW_TRIP, \
 + .max_trigger_level = 4, \
 + .gain = 8, \
 + .reference_voltage = 16, \
 + .noise_cancel_mode = 4, \
 + .cal_type = TYPE_ONE_POINT_TRIMMING, \
 + .efuse_value = 55, \
 + .min_efuse_value = 40, \
 + .max_efuse_value = 100, \
 + .first_point_trim = 25, \
 + .second_point_trim = 85, \
 + .default_temp_offset = 50, \
 + .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, \
   .registers = exynos5250_tmu_registers,
 +
 +struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
 + .tmu_data = {
 + { EXYNOS5250_TMU_DATA },
 + },
 + .tmu_count = 1,
  };
  #endif
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
 b/drivers/thermal/samsung/exynos_tmu_data.h
 index 4acf070..139dbbb 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.h
 +++ b/drivers/thermal/samsung/exynos_tmu_data.h
 @@ -94,14 +94,14 @@
  #define EXYNOS_MAX_TRIGGER_PER_REG   4
  
  #if defined(CONFIG_CPU_EXYNOS4210)
 -extern struct exynos_tmu_platform_data const exynos4210_default_tmu_data;
 +extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
  #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))
 -extern struct exynos_tmu_platform_data const exynos5250_default_tmu_data;
 +extern struct exynos_tmu_init_data const exynos5250_default_tmu_data;
  #define EXYNOS5250_TMU_DRV_DATA (exynos5250_default_tmu_data)
  #else
  #define EXYNOS5250_TMU_DRV_DATA (NULL)
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 19/30] thermal: exynos: Add TMU features to check instead of using SOC type

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds several features supported by TMU as bitfields.
 This features varies across different SOC type and comparing
 the features present in the TMU is more logical than comparing
 the soc itself.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_tmu.c  |   26 +++-
  drivers/thermal/samsung/exynos_tmu.h  |   31 
 +
  drivers/thermal/samsung/exynos_tmu_data.c |6 -
  3 files changed, 52 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 1880c4e..877dab8 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -142,13 +142,15 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   mutex_lock(data-lock);
   clk_enable(data-clk);
  
 - status = readb(data-base + reg-tmu_status);
 - if (!status) {
 - ret = -EBUSY;
 - goto out;
 + if (TMU_SUPPORTS(pdata, READY_STATUS)) {
 + status = readb(data-base + reg-tmu_status);
 + if (!status) {
 + ret = -EBUSY;
 + goto out;
 + }
   }
  
 - if (data-soc == SOC_ARCH_EXYNOS)
 + if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
   __raw_writel(1, data-base + reg-triminfo_ctrl);
  
   /* Save trimming info in order to perform calibration */
 @@ -287,7 +289,7 @@ static void exynos_tmu_control(struct platform_device 
 *pdev, bool on)
   pdata-trigger_enable[2]  reg-inten_rise2_shift |
   pdata-trigger_enable[1]  reg-inten_rise1_shift |
   pdata-trigger_enable[0]  reg-inten_rise0_shift;
 - if (pdata-threshold_falling)
 + if (TMU_SUPPORTS(pdata, FALLING_TRIP))
   interrupt_en |=
   interrupt_en  reg-inten_fall0_shift;
   } else {
 @@ -329,7 +331,7 @@ static int exynos_tmu_set_emulation(void *drv_data, 
 unsigned long temp)
   unsigned int val;
   int ret = -EINVAL;
  
 - if (data-soc == SOC_ARCH_EXYNOS4210)
 + if (!TMU_SUPPORTS(pdata, EMULATION))
   goto out;
  
   if (temp  temp  MCELSIUS)
 @@ -343,9 +345,13 @@ static int exynos_tmu_set_emulation(void *drv_data, 
 unsigned long temp)
   if (temp) {
   temp /= MCELSIUS;
  
 - val = (EXYNOS_EMUL_TIME  reg-emul_time_shift) |
 - (temp_to_code(data, temp)
 -   reg-emul_temp_shift) | EXYNOS_EMUL_ENABLE;
 + if (TMU_SUPPORTS(pdata, EMUL_TIME)) {
 + val = ~(EXYNOS_EMUL_TIME_MASK  reg-emul_time_shift);
 + val |= (EXYNOS_EMUL_TIME  reg-emul_time_shift);
 + }
 + val = ~(EXYNOS_EMUL_DATA_MASK  reg-emul_temp_shift);
 + val |= (temp_to_code(data, temp)  reg-emul_temp_shift) |
 + EXYNOS_EMUL_ENABLE;
   } else {
   val = ~EXYNOS_EMUL_ENABLE;
   }
 diff --git a/drivers/thermal/samsung/exynos_tmu.h 
 b/drivers/thermal/samsung/exynos_tmu.h
 index b614407..6f55673 100644
 --- a/drivers/thermal/samsung/exynos_tmu.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -41,6 +41,34 @@ enum soc_type {
  };
  
  /**
 + * EXYNOS TMU supported features.
 + * TMU_SUPPORT_EMULATION - This features is used to set user defined
 + *   temperature to the TMU controller.
 + * TMU_SUPPORT_MULTI_INST - This features denotes that the soc
 + *   has many instances of TMU.
 + * TMU_SUPPORT_TRIM_RELOAD - This features shows that trimming can
 + *   be reloaded.
 + * TMU_SUPPORT_FALLING_TRIP - This features shows that interrupt can
 + *   be registered for falling trips also.
 + * TMU_SUPPORT_READY_STATUS - This feature tells that the TMU current
 + *   state(active/idle) can be checked.
 + * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
 + *   sample time.
 + * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
 + *   sensors shares some common registers.
 + * TMU_SUPPORT - macro to compare the above features with the supplied.
 + */
 +#define TMU_SUPPORT_EMULATIONBIT(0)
 +#define TMU_SUPPORT_MULTI_INST   BIT(1)
 +#define TMU_SUPPORT_TRIM_RELOAD  BIT(2)
 +#define TMU_SUPPORT_FALLING_TRIP BIT(3)
 +#define TMU_SUPPORT_READY_STATUS BIT(4)
 +#define TMU_SUPPORT_EMUL_TIMEBIT(5)
 +#define TMU_SUPPORT_SHARED_MEMORYBIT(6)
 +
 +#define TMU_SUPPORTS(a, b)   (a-features

Re: [PATCH V6 20/30] thermal: exynos: use device resource management infrastructure

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch uses the device pointer stored in the configuration structure
 and converts to dev_* prints and devm API's.
 
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com


Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_thermal_common.c |   39 ++
  1 files changed, 25 insertions(+), 14 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 2873ca3..59b47e3 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -52,7 +52,8 @@ static int exynos_set_mode(struct thermal_zone_device 
 *thermal,
  {
   struct exynos_thermal_zone *th_zone = thermal-devdata;
   if (!th_zone) {
 - pr_notice(thermal zone not registered\n);
 + dev_err(th_zone-sensor_conf-dev,
 + thermal zone not registered\n);
   return 0;
   }
  
 @@ -68,8 +69,9 @@ static int exynos_set_mode(struct thermal_zone_device 
 *thermal,
  
   th_zone-mode = mode;
   thermal_zone_device_update(thermal);
 - pr_info(thermal polling set for duration=%d msec\n,
 - thermal-polling_delay);
 + dev_dbg(th_zone-sensor_conf-dev,
 + thermal polling set for duration=%d msec\n,
 + thermal-polling_delay);
   return 0;
  }
  
 @@ -159,7 +161,8 @@ static int exynos_bind(struct thermal_zone_device 
 *thermal,
   case WARN_ZONE:
   if (thermal_zone_bind_cooling_device(thermal, i, cdev,
   level, 0)) {
 - pr_err(error binding cdev inst %d\n, i);
 + dev_err(data-dev,
 + error unbinding cdev inst=%d\n, i);
   ret = -EINVAL;
   }
   th_zone-bind = true;
 @@ -204,7 +207,8 @@ static int exynos_unbind(struct thermal_zone_device 
 *thermal,
   case WARN_ZONE:
   if (thermal_zone_unbind_cooling_device(thermal, i,
   cdev)) {
 - pr_err(error unbinding cdev inst=%d\n, i);
 + dev_err(data-dev,
 + error unbinding cdev inst=%d\n, i);
   ret = -EINVAL;
   }
   th_zone-bind = false;
 @@ -224,7 +228,8 @@ static int exynos_get_temp(struct thermal_zone_device 
 *thermal,
   void *data;
  
   if (!th_zone-sensor_conf) {
 - pr_info(Temperature sensor not initialised\n);
 + dev_err(th_zone-sensor_conf-dev,
 + Temperature sensor not initialised\n);
   return -EINVAL;
   }
   data = th_zone-sensor_conf-driver_data;
 @@ -243,7 +248,8 @@ static int exynos_set_emul_temp(struct 
 thermal_zone_device *thermal,
   struct exynos_thermal_zone *th_zone = thermal-devdata;
  
   if (!th_zone-sensor_conf) {
 - pr_info(Temperature sensor not initialised\n);
 + dev_err(th_zone-sensor_conf-dev,
 + Temperature sensor not initialised\n);
   return -EINVAL;
   }
   data = th_zone-sensor_conf-driver_data;
 @@ -337,11 +343,13 @@ int exynos_register_thermal(struct thermal_sensor_conf 
 *sensor_conf)
   struct exynos_thermal_zone *th_zone;
  
   if (!sensor_conf || !sensor_conf-read_temperature) {
 - pr_err(Temperature sensor not initialised\n);
 + dev_err(sensor_conf-dev,
 + Temperature sensor not initialised\n);
   return -EINVAL;
   }
  
 - th_zone = kzalloc(sizeof(struct exynos_thermal_zone), GFP_KERNEL);
 + th_zone = devm_kzalloc(sensor_conf-dev,
 + sizeof(struct exynos_thermal_zone), GFP_KERNEL);
   if (!th_zone)
   return -ENOMEM;
  
 @@ -350,7 +358,8 @@ int exynos_register_thermal(struct thermal_sensor_conf 
 *sensor_conf)
   cpumask_set_cpu(0, mask_val);
   th_zone-cool_dev[0] = cpufreq_cooling_register(mask_val);
   if (IS_ERR(th_zone-cool_dev[0])) {
 - pr_err(Failed to register cpufreq cooling device\n);
 + dev_err(sensor_conf-dev,
 + Failed to register cpufreq cooling device\n);
   ret = -EINVAL;
   goto err_unregister;
   }
 @@ -364,14 +373,16 @@ int exynos_register_thermal(struct thermal_sensor_conf 
 *sensor_conf)
   IDLE_INTERVAL);
  
   if (IS_ERR(th_zone-therm_dev

Re: [PATCH V6 21/30] ARM: dts: thermal: exynos4: Add documentation for Exynos SoC thermal bindings

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 From: Lukasz Majewski l.majew...@samsung.com
 
 Proper description for Exynos4 bindings added to Documentation/devicetree/
 bindings
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |   25 
 
  1 files changed, 25 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 
 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 new file mode 100644
 index 000..535fd0e
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -0,0 +1,25 @@
 +* Exynos Thermal Management Unit (TMU)
 +
 +** Required properties:
 +
 +- compatible : One of the following:
 +samsung,exynos4412-tmu
 +samsung,exynos4210-tmu
 +samsung,exynos5250-tmu
 +- interrupt-parent : The phandle for the interrupt controller
 +- reg : Address range of the thermal registers
 +- interrupts : Should contain interrupt for thermal system
 +- clocks : The main clock for TMU device
 +- clock-names : Thermal system clock name

Should this include the documentation on the alias needed by patch 18?
tmuctrl?


 +
 +Example:
 +
 + tmu@100C {
 + compatible = samsung,exynos4412-tmu;
 + interrupt-parent = combiner;
 + reg = 0x100C 0x100;
 + interrupts = 2 4;
 + clocks = clock 383;
 + clock-names = tmu_apbif;
 + status = disabled;
 + };
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 22/30] thermal: exynos: Add support to access common register for multistance

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds support to parse one more common set of TMU register. First
 set of register belongs to each instance of TMU and second set belongs to
 common TMU registers.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

This patch is fine:

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

But please read my concern on next patch.

 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |6 +-
  drivers/thermal/samsung/exynos_tmu.c   |   20 
 
  2 files changed, 25 insertions(+), 1 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index 535fd0e..0ea33f7 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -7,7 +7,11 @@
  samsung,exynos4210-tmu
  samsung,exynos5250-tmu
  - interrupt-parent : The phandle for the interrupt controller
 -- reg : Address range of the thermal registers
 +- reg : Address range of the thermal registers. For soc's which has multiple
 + instances of TMU and some registers are shared across all TMU's like
 + interrupt related then 2 set of register has to supplied. First set
 + belongs to each instance of TMU and second set belongs to common TMU
 + registers.
  - interrupts : Should contain interrupt for thermal system
  - clocks : The main clock for TMU device
  - clock-names : Thermal system clock name
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 877dab8..150a869 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -40,6 +40,7 @@
   * @id: identifier of the one instance of the TMU controller.
   * @pdata: pointer to the tmu platform/configuration data
   * @base: base address of the single instance of the TMU controller.
 + * @base_common: base address of the common registers of the TMU controller.
   * @irq: irq number of the TMU controller.
   * @soc: id of the SOC type.
   * @irq_work: pointer to the irq work structure.
 @@ -53,6 +54,7 @@ struct exynos_tmu_data {
   int id;
   struct exynos_tmu_platform_data *pdata;
   void __iomem *base;
 + void __iomem *base_common;
   int irq;
   enum soc_type soc;
   struct work_struct irq_work;
 @@ -478,6 +480,24 @@ static int exynos_map_dt_data(struct platform_device 
 *pdev)
   return -ENODEV;
   }
   data-pdata = pdata;
 + /*
 +  * Check if the TMU shares some registers and then try to map the
 +  * memory of common registers.
 +  */
 + if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
 + return 0;
 +
 + if (of_address_to_resource(pdev-dev.of_node, 1, res)) {
 + dev_err(pdev-dev, failed to get Resource 1\n);
 + return -ENODEV;
 + }
 +
 + data-base_common = devm_ioremap(pdev-dev, res.start,
 + resource_size(res));
 + if (!data-base) {
 + dev_err(pdev-dev, Failed to ioremap memory\n);
 + return -ENOMEM;
 + }
  
   return 0;
  }
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 23/30] thermal: exynos: Add driver support for exynos5440 TMU sensor

[Eduardo Valentin]

 EXYNOS5440_TMU_S0_7_IRQEN0x210
 +#define EXYNOS5440_TMU_S0_7_IRQ  0x230
 +/* exynos5440 common registers */
 +#define EXYNOS5440_TMU_IRQ_STATUS0x000
 +#define EXYNOS5440_TMU_PMIN  0x004
 +#define EXYNOS5440_TMU_TEMP  0x008
 +
 +#define EXYNOS5440_TMU_RISE_INT_MASK 0xf
 +#define EXYNOS5440_TMU_RISE_INT_SHIFT0
 +#define EXYNOS5440_TMU_FALL_INT_MASK 0xf
 +#define EXYNOS5440_TMU_FALL_INT_SHIFT4
 +#define EXYNOS5440_TMU_INTEN_RISE0_SHIFT 0
 +#define EXYNOS5440_TMU_INTEN_RISE1_SHIFT 1
 +#define EXYNOS5440_TMU_INTEN_RISE2_SHIFT 2
 +#define EXYNOS5440_TMU_INTEN_RISE3_SHIFT 3
 +#define EXYNOS5440_TMU_INTEN_FALL0_SHIFT 4
 +#define EXYNOS5440_TMU_INTEN_FALL1_SHIFT 5
 +#define EXYNOS5440_TMU_INTEN_FALL2_SHIFT 6
 +#define EXYNOS5440_TMU_INTEN_FALL3_SHIFT 7
 +#define EXYNOS5440_TMU_TH_RISE0_SHIFT0
 +#define EXYNOS5440_TMU_TH_RISE1_SHIFT8
 +#define EXYNOS5440_TMU_TH_RISE2_SHIFT16
 +#define EXYNOS5440_TMU_TH_RISE3_SHIFT24
 +#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
 +#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
 +
  #if defined(CONFIG_CPU_EXYNOS4210)
  extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
  #define EXYNOS4210_TMU_DRV_DATA (exynos4210_default_tmu_data)
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 24/30] thermal: exynos: Add thermal configuration data for exynos5440 TMU sensor

[Eduardo Valentin]

 +143,11 @@ extern struct exynos_tmu_init_data const 
 exynos5250_default_tmu_data;
  #define EXYNOS5250_TMU_DRV_DATA (NULL)
  #endif
  
 +#if defined(CONFIG_SOC_EXYNOS5440)
 +extern struct exynos_tmu_init_data const exynos5440_default_tmu_data;
 +#define EXYNOS5440_TMU_DRV_DATA (exynos5440_default_tmu_data)
 +#else
 +#define EXYNOS5440_TMU_DRV_DATA (NULL)
 +#endif
 +
  #endif /*_EXYNOS_TMU_DATA_H*/
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 25/30] thermal: exynos: Fix to set the second point correction value

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch sets the second point trimming value according to the platform
 data if the register value is 0.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/exynos_tmu.c |   13 +
  1 files changed, 9 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index a4dbc84..af0e6ca 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -180,10 +180,15 @@ static int exynos_tmu_initialize(struct platform_device 
 *pdev)
   data-temp_error2 = ((trim_info  reg-triminfo_85_shift) 
   EXYNOS_TMU_TEMP_MASK);
  
 - if ((pdata-min_efuse_value  data-temp_error1) ||
 - (data-temp_error1  pdata-max_efuse_value) ||
 - (data-temp_error2 != 0))
 - data-temp_error1 = pdata-efuse_value;
 + if (!data-temp_error1 ||
 + (pdata-min_efuse_value  data-temp_error1) ||
 + (data-temp_error1  pdata-max_efuse_value))
 + data-temp_error1 = pdata-efuse_value  EXYNOS_TMU_TEMP_MASK;
 +
 + if (!data-temp_error2)
 + data-temp_error2 =
 + (pdata-efuse_value  reg-triminfo_85_shift) 
 + EXYNOS_TMU_TEMP_MASK;
  
   if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
   dev_err(pdev-dev, Invalid max trigger level\n);
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 26/30] thermal: exynos: Add hardware mode thermal calibration support

[Eduardo Valentin]

 +++ b/drivers/thermal/samsung/exynos_tmu_data.h
 @@ -75,6 +75,8 @@
  #define EXYNOS_TMU_TRIP_MODE_SHIFT   13
  #define EXYNOS_TMU_TRIP_MODE_MASK0x7
  #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT   12
 +#define EXYNOS_TMU_CALIB_MODE_SHIFT  4
 +#define EXYNOS_TMU_CALIB_MODE_MASK   0x3
  
  #define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
  #define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 27/30] Documentation: thermal: Explain the exynos thermal driver model

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch updates the documentation to explain the driver model
 and file layout.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  Documentation/thermal/exynos_thermal |   43 ++---
  1 files changed, 34 insertions(+), 9 deletions(-)
 
 diff --git a/Documentation/thermal/exynos_thermal 
 b/Documentation/thermal/exynos_thermal
 index 2b46f67..9010c44 100644
 --- a/Documentation/thermal/exynos_thermal
 +++ b/Documentation/thermal/exynos_thermal
 @@ -1,17 +1,17 @@
 -Kernel driver exynos4_tmu
 +Kernel driver exynos_tmu
  =
  
  Supported chips:
 -* ARM SAMSUNG EXYNOS4 series of SoC
 -  Prefix: 'exynos4-tmu'
 +* ARM SAMSUNG EXYNOS4, EXYNOS5 series of SoC
Datasheet: Not publicly available
  
  Authors: Donggeun Kim dg77@samsung.com
 +Authors: Amit Daniel amit.dan...@samsung.com
  
 -Description
 
 +TMU controller Description:
 +---
  
 -This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
 +This driver allows to read temperature inside SAMSUNG EXYNOS4/5 series of 
 SoC.
  
  The chip only exposes the measured 8-bit temperature code value
  through a register.
 @@ -34,9 +34,9 @@ The three equations are:
TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
 Temperature code measured at 85 degree Celsius which is unchanged
  
 -TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
 +TMU(Thermal Management Unit) in EXYNOS4/5 generates interrupt
  when temperature exceeds pre-defined levels.
 -The maximum number of configurable threshold is four.
 +The maximum number of configurable threshold is five.
  The threshold levels are defined as follows:
Level_0: current temperature  trigger_level_0 + threshold
Level_1: current temperature  trigger_level_1 + threshold
 @@ -47,6 +47,31 @@ The threshold levels are defined as follows:
through the corresponding registers.
  
  When an interrupt occurs, this driver notify kernel thermal framework
 -with the function exynos4_report_trigger.
 +with the function exynos_report_trigger.
  Although an interrupt condition for level_0 can be set,
  it can be used to synchronize the cooling action.
 +
 +TMU driver description:
 +---
 +
 +The exynos thermal driver is structured as,
 +
 + Kernel Core thermal framework
 + (thermal_core.c, step_wise.c, cpu_cooling.c)
 + ^
 + |
 + |
 +TMU configuration data --- TMU Driver  -- Exynos Core thermal 
 wrapper
 +(exynos_tmu_data.c)(exynos_tmu.c)   (exynos_thermal_common.c)
 +(exynos_tmu_data.h)(exynos_tmu.h)   (exynos_thermal_common.h)
 +
 +a) TMU configuration data: This consist of TMU register offsets/bitfields
 + described through structure exynos_tmu_registers. Also several
 + other platform data (struct exynos_tmu_platform_data) members
 + are used to configure the TMU.
 +b) TMU driver: This component initialises the TMU controller and sets 
 different
 + thresholds. It invokes core thermal implementation with the call
 + exynos_report_trigger.
 +c) Exynos Core thermal wrapper: This provides 3 wrapper function to use the
 + Kernel core thermal framework. They are 
 exynos_unregister_thermal,
 + exynos_register_thermal and exynos_report_trigger.
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 28/30] thermal: exynos: Support for TMU regulator defined at device tree

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 TMU probe function now checks for a device tree defined regulator.
 For compatibility reasons it is allowed to probe driver even without
 this regulator defined.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |4 +++
  drivers/thermal/samsung/exynos_tmu.c   |   23 
 
  2 files changed, 27 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index e6386ea..284f530 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -16,6 +16,9 @@
  - interrupts : Should contain interrupt for thermal system
  - clocks : The main clock for TMU device
  - clock-names : Thermal system clock name
 +- vtmu-supply: This entry is optional and provides the regulator node 
 supplying
 + voltage to TMU. If needed this entry can be placed inside
 + board/platform specific dts file.
  
  Example 1):
  
 @@ -27,6 +30,7 @@ Example 1):
   clocks = clock 383;
   clock-names = tmu_apbif;
   status = disabled;
 + vtmu-supply = tmu_regulator_node;
   };
  
  Example 2):
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 7a259f4..441efd5 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -29,6 +29,7 @@
  #include linux/of_address.h
  #include linux/of_irq.h
  #include linux/platform_device.h
 +#include linux/regulator/consumer.h
  
  #include exynos_thermal_common.h
  #include exynos_tmu.h
 @@ -48,6 +49,7 @@
   * @clk: pointer to the clock structure.
   * @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.
   * @reg_conf: pointer to structure to register with core thermal.
   */
  struct exynos_tmu_data {
 @@ -61,6 +63,7 @@ struct exynos_tmu_data {
   struct mutex lock;
   struct clk *clk;
   u8 temp_error1, temp_error2;
 + struct regulator *regulator;
   struct thermal_sensor_conf *reg_conf;
  };
  
 @@ -510,10 +513,27 @@ static int exynos_map_dt_data(struct platform_device 
 *pdev)
   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
   struct exynos_tmu_platform_data *pdata;
   struct resource res;
 + int ret;
  
   if (!data)
   return -ENODEV;
  
 + /*
 +  * Try enabling the regulator if found
 +  * TODO: Add regulator as an SOC feature, so that regulator enable
 +  * is a compulsory call.
 +  */
 + data-regulator = devm_regulator_get(pdev-dev, vtmu);
 + if (!IS_ERR(data-regulator)) {
 + ret = regulator_enable(data-regulator);
 + if (ret) {
 + dev_err(pdev-dev, failed to enable vtmu\n);
 + return ret;
 + }
 + } else {
 + dev_info(pdev-dev, Regulator node (vtmu) not found\n);
 + }
 +
   data-id = of_alias_get_id(pdev-dev.of_node, tmuctrl);
   if (data-id  0)
   data-id = 0;
 @@ -680,6 +700,9 @@ static int exynos_tmu_remove(struct platform_device *pdev)
  
   clk_unprepare(data-clk);
  
 + if (!IS_ERR(data-regulator))
 + regulator_disable(data-regulator);
 +
   return 0;
  }
  
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 29/30] ARM: dts: Add device tree node for exynos5440 TMU controller

[Eduardo Valentin]

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds device node for TMU controller. There are 3
 instances of the controllers so 3 nodes are created.
 
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

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

 ---
  arch/arm/boot/dts/exynos5440.dtsi |   30 ++
  1 files changed, 30 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index f6b1c89..716e90c 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -16,6 +16,12 @@
  
   interrupt-parent = gic;
  
 + aliases {
 + tmuctrl0 = tmuctrl_0;
 + tmuctrl1 = tmuctrl_1;
 + tmuctrl2 = tmuctrl_2;
 + };
 +
   clock: clock-controller@0x16 {
   compatible = samsung,exynos5440-clock;
   reg = 0x16 0x1000;
 @@ -216,4 +222,28 @@
   clock-names = rtc;
   status = disabled;
   };
 +
 + tmuctrl_0: tmuctrl@160118 {
 + compatible = samsung,exynos5440-tmu;
 + reg = 0x160118 0x230, 0x160368 0x10;
 + interrupts = 0 58 0;
 + clocks = clock 21;
 + clock-names = tmu_apbif;
 + };
 +
 + tmuctrl_1: tmuctrl@16011C {
 + compatible = samsung,exynos5440-tmu;
 + reg = 0x16011C 0x230, 0x160368 0x10;
 + interrupts = 0 58 0;
 + clocks = clock 21;
 + clock-names = tmu_apbif;
 + };
 +
 + tmuctrl_2: tmuctrl@160120 {
 + compatible = samsung,exynos5440-tmu;
 + reg = 0x160120 0x230, 0x160368 0x10;
 + interrupts = 0 58 0;
 + clocks = clock 21;
 + clock-names = tmu_apbif;
 + };
  };
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V6 09/30] thermal: exynos: Add extra entries in the tmu platform data

[Eduardo Valentin]

On 21-06-2013 04:50, amit daniel kachhap wrote:
 Hi,
 
 On Thu, Jun 20, 2013 at 2:22 AM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 19-06-2013 16:19, Eduardo Valentin wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds entries min_efuse_value, max_efuse_value, 
 default_temp_offset,
 trigger_type, cal_type, trim_first_point, trim_second_point, 
 max_trigger_level
 trigger_enable in the TMU platform data structure. Also the driver is 
 modified
 to use the data passed by these new platform memebers instead of the 
 constant
 macros. All these changes helps in separating the SOC specific data part 
 from
 the TMU driver.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.h |7 +++
  drivers/thermal/samsung/exynos_tmu.c|   43 
 ++--
  drivers/thermal/samsung/exynos_tmu.h|   49 
 ++
  drivers/thermal/samsung/exynos_tmu_data.c   |   35 
  4 files changed, 86 insertions(+), 48 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index 068f56c..fd789a5 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -44,6 +44,13 @@

  #define EXYNOS_ZONE_COUNT   3

 +enum trigger_type {
 +THROTTLE_ACTIVE = 1,
 +THROTTLE_PASSIVE,
 +SW_TRIP,
 +HW_TRIP,
 +};
 +
  /**
   * struct freq_clip_table
   * @freq_clip_max: maximum frequency allowed for this cooling state.
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index fa33a48..401ec98 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -49,7 +49,6 @@
  #define EXYNOS_TMU_BUF_SLOPE_SEL_MASK   0xf
  #define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT  8
  #define EXYNOS_TMU_CORE_EN_SHIFT0
 -#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET  50

  /* Exynos4210 specific registers */
  #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP   0x44
 @@ -94,9 +93,6 @@
  #define EXYNOS_TMU_INTEN_FALL1_SHIFT20
  #define EXYNOS_TMU_INTEN_FALL2_SHIFT24

 -#define EFUSE_MIN_VALUE 40
 -#define EFUSE_MAX_VALUE 100
 -
  #ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME0x57F0
  #define EXYNOS_EMUL_TIME_MASK   0x
 @@ -136,15 +132,16 @@ static int temp_to_code(struct exynos_tmu_data 
 *data, u8 temp)

  switch (pdata-cal_type) {
  case TYPE_TWO_POINT_TRIMMING:
 -temp_code = (temp - 25) *
 -(data-temp_error2 - data-temp_error1) /
 -(85 - 25) + data-temp_error1;
 +temp_code = (temp - pdata-first_point_trim) *
 +(data-temp_error2 - data-temp_error1) /
 +(pdata-second_point_trim - pdata-first_point_trim) +
 +data-temp_error1;
  break;
  case TYPE_ONE_POINT_TRIMMING:
 -temp_code = temp + data-temp_error1 - 25;
 +temp_code = temp + data-temp_error1 - 
 pdata-first_point_trim;
  break;
  default:
 -temp_code = temp + EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
 +temp_code = temp + pdata-default_temp_offset;
  break;
  }
  out:
 @@ -169,14 +166,16 @@ static int code_to_temp(struct exynos_tmu_data 
 *data, u8 temp_code)

  switch (pdata-cal_type) {
  case TYPE_TWO_POINT_TRIMMING:
 -temp = (temp_code - data-temp_error1) * (85 - 25) /
 -(data-temp_error2 - data-temp_error1) + 25;
 +temp = (temp_code - data-temp_error1) *
 +(pdata-second_point_trim - pdata-first_point_trim) /
 +(data-temp_error2 - data-temp_error1) +
 +pdata-first_point_trim;
  break;
  case TYPE_ONE_POINT_TRIMMING:
 -temp = temp_code - data-temp_error1 + 25;
 +temp = temp_code - data-temp_error1 + 
 pdata-first_point_trim;
  break;
  default:
 -temp = temp_code - EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
 +temp = temp_code - pdata-default_temp_offset;
  break;
  }
  out:
 @@ -209,8 +208,8 @@ static int exynos_tmu_initialize(struct 
 platform_device *pdev)
  data-temp_error1 = trim_info  EXYNOS_TMU_TRIM_TEMP_MASK;
  data-temp_error2 = ((trim_info  8)  EXYNOS_TMU_TRIM_TEMP_MASK);

 -if ((EFUSE_MIN_VALUE  data-temp_error1) ||
 -(data-temp_error1  EFUSE_MAX_VALUE) ||
 +if ((pdata-min_efuse_value  data-temp_error1) ||
 +(data-temp_error1  pdata-max_efuse_value) ||
  (data-temp_error2 != 0))
  data-temp_error1 = pdata-efuse_value;

 @@ -300,10 +299,10 @@ static void exynos_tmu_control(struct 
 platform_device *pdev, bool

Re: [PATCH V6 18/30] thermal: exynos: Add support to handle many instances of TMU

[Eduardo Valentin]

On 21-06-2013 08:46, amit daniel kachhap wrote:
 Hi Eduardo,
 
 On Thu, Jun 20, 2013 at 4:57 AM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds support to handle multiple instances of the TMU controllers.
 This is done by removing the static structure to register with the core 
 thermal
 and creating it dynamically for each instance of the TMU controller. The
 interrupt is made shared type to handle shared interrupts. Also
 the identifier of the TMU controller is extracted from device tree alias.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.h |1 +
  drivers/thermal/samsung/exynos_tmu.c|  147 
 ---
  drivers/thermal/samsung/exynos_tmu.h|   13 ++
  drivers/thermal/samsung/exynos_tmu_data.c   |  145 
 --
  drivers/thermal/samsung/exynos_tmu_data.h   |4 +-
  5 files changed, 197 insertions(+), 113 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
 b/drivers/thermal/samsung/exynos_thermal_common.h
 index dd0077e..0c189d6 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.h
 +++ b/drivers/thermal/samsung/exynos_thermal_common.h
 @@ -84,6 +84,7 @@ struct thermal_sensor_conf {
   struct thermal_cooling_conf cooling_data;
   void *driver_data;
   void *pzone_data;
 + struct device *dev;
  };

  /*Functions used exynos based thermal sensor driver*/
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 4356118..1880c4e 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -26,15 +26,32 @@
  #include linux/interrupt.h
  #include linux/module.h
  #include linux/of.h
 +#include linux/of_address.h
 +#include linux/of_irq.h
  #include linux/platform_device.h

  #include exynos_thermal_common.h
  #include exynos_tmu.h
  #include exynos_tmu_data.h

 +/**
 + * struct exynos_tmu_data : A structure to hold the private data of the TMU
 + driver
 + * @id: identifier of the one instance of the TMU controller.
 + * @pdata: pointer to the tmu platform/configuration data
 + * @base: base address of the single instance of the TMU controller.
 + * @irq: irq number of the TMU controller.
 + * @soc: id of the SOC type.
 + * @irq_work: pointer to the irq work structure.
 + * @lock: lock to implement synchronization.
 + * @clk: pointer to the clock structure.
 + * @temp_error1: fused value of the first point trim.
 + * @temp_error2: fused value of the second point trim.
 + * @reg_conf: pointer to structure to register with core thermal.
 + */
  struct exynos_tmu_data {
 + int id;
   struct exynos_tmu_platform_data *pdata;
 - struct resource *mem;
   void __iomem *base;
   int irq;
   enum soc_type soc;
 @@ -42,6 +59,7 @@ struct exynos_tmu_data {
   struct mutex lock;
   struct clk *clk;
   u8 temp_error1, temp_error2;
 + struct thermal_sensor_conf *reg_conf;
  };

  /*
 @@ -345,12 +363,6 @@ static int exynos_tmu_set_emulation(void *drv_data,
   unsigned long temp)
   { return -EINVAL; }
  #endif/*CONFIG_THERMAL_EMULATION*/

 -static struct thermal_sensor_conf exynos_sensor_conf = {
 - .name   = exynos-therm,
 - .read_temperature   = (int (*)(void *))exynos_tmu_read,
 - .write_emul_temp= exynos_tmu_set_emulation,
 -};
 -
  static void exynos_tmu_work(struct work_struct *work)
  {
   struct exynos_tmu_data *data = container_of(work,
 @@ -359,7 +371,7 @@ static void exynos_tmu_work(struct work_struct *work)
   const struct exynos_tmu_registers *reg = pdata-registers;
   unsigned int val_irq;

 - exynos_report_trigger(exynos_sensor_conf);
 + exynos_report_trigger(data-reg_conf);
   mutex_lock(data-lock);
   clk_enable(data-clk);

 @@ -404,33 +416,73 @@ MODULE_DEVICE_TABLE(of, exynos_tmu_match);
  #endif

  static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
 - struct platform_device *pdev)
 + struct platform_device *pdev, int id)
  {
 + struct  exynos_tmu_init_data *data_table;
 + struct exynos_tmu_platform_data *tmu_data;
  #ifdef CONFIG_OF
   if (pdev-dev.of_node) {
   const struct of_device_id *match;
   match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
   if (!match)
   return NULL;
 - return (struct exynos_tmu_platform_data *) match-data;
 + data_table = (struct exynos_tmu_init_data *) match-data;
 + if (!data_table || id = data_table-tmu_count)
 + return NULL;
 + tmu_data = data_table-tmu_data;
 + return (struct exynos_tmu_platform_data *) (tmu_data + id

Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

[Eduardo Valentin]

On 20-06-2013 21:50, amit daniel kachhap wrote:
 On Thu, Jun 20, 2013 at 12:15 AM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 Amit,

 On 17-06-2013 02:46, 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
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/Kconfig |   19 +-
  drivers/thermal/samsung/Makefile|4 +-
  drivers/thermal/samsung/exynos_thermal.c|  419 
 +--
  drivers/thermal/samsung/exynos_thermal_common.c |  384 
 +
  drivers/thermal/samsung/exynos_thermal_common.h |   83 +
  5 files changed, 490 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 2cf31ad..f8100b1 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -1,8 +1,17 @@
  config EXYNOS_THERMAL
 - tristate Temperature sensor on Samsung EXYNOS
 + tristate Exynos thermal management unit driver
   depends on ARCH_HAS_BANDGAP
   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 TMU (Thermal Management
 +   Unit) driver for SAMSUNG EXYNOS series of soc. This driver 
 initialises
 +   the TMU, reports temperature and handles cooling action if defined.
 +   This driver uses the exynos 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.
 Should this one depend on CPU_THERMAL? Is it mandatory?
 Hi Eduardo,
 
 No it is not mandatory. If CPU_THERMAL is not present then cooling
 device is not created and only temp/trip_points etc sysfs are created.

OK.

 
 Thanks,
 Amit Daniel

 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 03e4bbc..5293849 100644
 --- a/drivers/thermal/samsung/exynos_thermal.c
 +++ b/drivers/thermal/samsung/exynos_thermal.c
 @@ -21,23 +21,15 @@
   *
   */

 -#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/mutex.h
 -#include linux/platform_data/exynos_thermal.h
 -#include linux/thermal.h
 -#include linux/cpufreq.h
 -#include linux/cpu_cooling.h
 +#include linux/interrupt.h
 +#include linux/module.h
  #include linux/of.h
 +#include linux/platform_device.h
 +#include linux/platform_data/exynos_thermal.h
 +
 +#include exynos_thermal_common.h

  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -88,16 +80,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 +88,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

Re: [PATCH V6 08/30] thermal: exynos: Add missing definations and code cleanup

[Eduardo Valentin]

On 20-06-2013 22:01, amit daniel kachhap wrote:
 Hi Eduardo,
 
 On Thu, Jun 20, 2013 at 1:25 AM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This patch adds some extra register bitfield definations and cleans
 up the code to prepare for moving register macros and definations inside
 the TMU data section.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c |   62 
 +-
  1 files changed, 46 insertions(+), 16 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 5df04a1..fa33a48 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -43,9 +43,12 @@

  #define EXYNOS_TMU_TRIM_TEMP_MASK0xff
  #define EXYNOS_TMU_GAIN_SHIFT8
 +#define EXYNOS_TMU_GAIN_MASK 0xf
  #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
 -#define EXYNOS_TMU_CORE_ON   3
 -#define EXYNOS_TMU_CORE_OFF  2
 +#define EXYNOS_TMU_REF_VOLTAGE_MASK  0x1f
 +#define EXYNOS_TMU_BUF_SLOPE_SEL_MASK0xf
 +#define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT   8
 +#define EXYNOS_TMU_CORE_EN_SHIFT 0
  #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET   50

  /* Exynos4210 specific registers */
 @@ -63,6 +66,7 @@
  #define EXYNOS4210_TMU_TRIG_LEVEL1_MASK  0x10
  #define EXYNOS4210_TMU_TRIG_LEVEL2_MASK  0x100
  #define EXYNOS4210_TMU_TRIG_LEVEL3_MASK  0x1000
 +#define EXYNOS4210_TMU_TRIG_LEVEL_MASK   0x
  #define EXYNOS4210_TMU_INTCLEAR_VAL  0x

  /* Exynos5250 and Exynos4412 specific registers */
 @@ -72,17 +76,30 @@
  #define EXYNOS_EMUL_CON  0x80

  #define EXYNOS_TRIMINFO_RELOAD   0x1
 +#define EXYNOS_TRIMINFO_SHIFT0x0
 +#define EXYNOS_TMU_RISE_INT_MASK 0x111
 +#define EXYNOS_TMU_RISE_INT_SHIFT0
 +#define EXYNOS_TMU_FALL_INT_MASK 0x111
 +#define EXYNOS_TMU_FALL_INT_SHIFT12
  #define EXYNOS_TMU_CLEAR_RISE_INT0x111
  #define EXYNOS_TMU_CLEAR_FALL_INT(0x111  12)
 -#define EXYNOS_MUX_ADDR_VALUE6
 -#define EXYNOS_MUX_ADDR_SHIFT20
  #define EXYNOS_TMU_TRIP_MODE_SHIFT   13
 +#define EXYNOS_TMU_TRIP_MODE_MASK0x7
 +
 +#define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
 +#define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
 +#define EXYNOS_TMU_INTEN_RISE2_SHIFT 8
 +#define EXYNOS_TMU_INTEN_RISE3_SHIFT 12
 +#define EXYNOS_TMU_INTEN_FALL0_SHIFT 16
 +#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20
 +#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24

  #define EFUSE_MIN_VALUE 40
  #define EFUSE_MAX_VALUE 100

  #ifdef CONFIG_THERMAL_EMULATION
  #define EXYNOS_EMUL_TIME 0x57F0
 +#define EXYNOS_EMUL_TIME_MASK0x
  #define EXYNOS_EMUL_TIME_SHIFT   16
  #define EXYNOS_EMUL_DATA_SHIFT   8
  #define EXYNOS_EMUL_DATA_MASK0xFF
 @@ -261,24 +278,37 @@ static void exynos_tmu_control(struct platform_device 
 *pdev, bool on)
   mutex_lock(data-lock);
   clk_enable(data-clk);

 - con = pdata-reference_voltage  EXYNOS_TMU_REF_VOLTAGE_SHIFT |
 - pdata-gain  EXYNOS_TMU_GAIN_SHIFT;
 + con = readl(data-base + EXYNOS_TMU_REG_CONTROL);

 - if (data-soc == SOC_ARCH_EXYNOS) {
 - con |= pdata-noise_cancel_mode  EXYNOS_TMU_TRIP_MODE_SHIFT;
 - con |= (EXYNOS_MUX_ADDR_VALUE  EXYNOS_MUX_ADDR_SHIFT);
 + if (pdata-reference_voltage) {
 + con = ~(EXYNOS_TMU_REF_VOLTAGE_MASK 
 + EXYNOS_TMU_REF_VOLTAGE_SHIFT);
 + con |= pdata-reference_voltage  
 EXYNOS_TMU_REF_VOLTAGE_SHIFT;
 + }
 +
 + if (pdata-gain) {
 + con = ~(EXYNOS_TMU_GAIN_MASK  EXYNOS_TMU_GAIN_SHIFT);
 + con |= (pdata-gain  EXYNOS_TMU_GAIN_SHIFT);
 + }
 +
 + if (pdata-noise_cancel_mode) {
 + con = ~(EXYNOS_TMU_TRIP_MODE_MASK 
 + EXYNOS_TMU_TRIP_MODE_SHIFT);
 + con |= (pdata-noise_cancel_mode  
 EXYNOS_TMU_TRIP_MODE_SHIFT);
   }

   if (on) {
 - con |= EXYNOS_TMU_CORE_ON;



 Before, in order to turn core on you had:
 con = con | 3;

 now you do:
 con = con | (1  0);

 To me, before you would set bit 1 and 0, now you set bit 0.


 - interrupt_en = pdata-trigger_level3_en  12 |
 - pdata-trigger_level2_en  8 |
 - pdata-trigger_level1_en  4 |
 - pdata-trigger_level0_en;
 + con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
 + interrupt_en =
 + pdata-trigger_level3_en  EXYNOS_TMU_INTEN_RISE3_SHIFT |
 + pdata-trigger_level2_en  EXYNOS_TMU_INTEN_RISE2_SHIFT |
 + pdata-trigger_level1_en  EXYNOS_TMU_INTEN_RISE1_SHIFT |
 + pdata-trigger_level0_en  EXYNOS_TMU_INTEN_RISE0_SHIFT;
   if (pdata

Re: [PATCH V6 16/30] thermal: exynos: Make the zone handling use trip information

[Eduardo Valentin]

On 21-06-2013 08:30, amit daniel kachhap wrote:
 Hi
 
 On Thu, Jun 20, 2013 at 4:33 AM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
 This code simplifies the zone handling to use the trip information passed
 by the TMU driver and not the hardcoded macros. This also helps in adding
 more zone support.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  drivers/thermal/samsung/exynos_thermal_common.c |   61 
 +--
  drivers/thermal/samsung/exynos_thermal_common.h |3 +-
  drivers/thermal/samsung/exynos_tmu.c|5 ++-
  3 files changed, 40 insertions(+), 29 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 86d39aa..2873ca3 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -78,17 +78,22 @@ static int exynos_set_mode(struct thermal_zone_device 
 *thermal,
  static int exynos_get_trip_type(struct thermal_zone_device *thermal, int 
 trip,
enum thermal_trip_type *type)
  {
 - switch (GET_ZONE(trip)) {
 - case MONITOR_ZONE:
 - case WARN_ZONE:
 - *type = THERMAL_TRIP_ACTIVE;
 - break;
 - case PANIC_ZONE:
 - *type = THERMAL_TRIP_CRITICAL;
 - break;
 - default:
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
 + int max_trip = th_zone-sensor_conf-trip_data.trip_count;
 + int trip_type;
 +
 + if (trip  0 || trip = max_trip)
   return -EINVAL;
 - }
 +
 + trip_type = th_zone-sensor_conf-trip_data.trip_type[trip];
 +
 + if (trip_type == SW_TRIP)
 + *type = THERMAL_TRIP_CRITICAL;
 + else if (trip_type == THROTTLE_ACTIVE)
 + *type = THERMAL_TRIP_ACTIVE;
 + else if (trip_type == THROTTLE_PASSIVE)
 + *type = THERMAL_TRIP_PASSIVE;
 +
   return 0;
  }

 @@ -97,8 +102,9 @@ static int exynos_get_trip_temp(struct 
 thermal_zone_device *thermal, int trip,
   unsigned long *temp)
  {
   struct exynos_thermal_zone *th_zone = thermal-devdata;
 + int max_trip = th_zone-sensor_conf-trip_data.trip_count;

 - if (trip  GET_TRIP(MONITOR_ZONE) || trip  GET_TRIP(PANIC_ZONE))
 + if (trip  0 || trip = max_trip)
   return -EINVAL;

   *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
 @@ -112,10 +118,10 @@ static int exynos_get_trip_temp(struct 
 thermal_zone_device *thermal, int trip,
  static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
   unsigned long *temp)
  {
 - int ret;
 - /* Panic zone */
 - ret = exynos_get_trip_temp(thermal, GET_TRIP(PANIC_ZONE), temp);
 - return ret;
 + struct exynos_thermal_zone *th_zone = thermal-devdata;
 + int max_trip = th_zone-sensor_conf-trip_data.trip_count;
 + /* Get the temp of highest trip*/
 + return exynos_get_trip_temp(thermal, max_trip - 1, temp);
  }

  /* Bind callback functions for thermal zone */
 @@ -340,19 +346,22 @@ int exynos_register_thermal(struct 
 thermal_sensor_conf *sensor_conf)
   return -ENOMEM;

   th_zone-sensor_conf = sensor_conf;
 - cpumask_set_cpu(0, mask_val);
 - th_zone-cool_dev[0] = cpufreq_cooling_register(mask_val);
 - if (IS_ERR(th_zone-cool_dev[0])) {
 - pr_err(Failed to register cpufreq cooling device\n);
 - ret = -EINVAL;
 - goto err_unregister;
 + if (sensor_conf-cooling_data.freq_clip_count  0) {
 + cpumask_set_cpu(0, mask_val);
 + th_zone-cool_dev[0] = cpufreq_cooling_register(mask_val);

 Did you mean th_zone-cool_dev[th_zone-cool_dev_size] ?
 Yes.

 I think the logic behind the allocation of these cpufreq cooling devices
 needs to be revisited. You always assigned to cool_dev[0], but you
 always iterate the array until cool_dev_size. Remember that
 cool_dev_size now is per th_zone, not global.
 I have kept an array of cooling devices to add other type of cooling
 devices in the same thermal zone in future. For current use case
 although it does not make sense and only one cpufreq cooling device is
 present

I would at least put a TODO mark. This code can easily evolve to a bug.
What it would be better is to have a proper flag/way to say how you want
to do the cooling on a specific TMU. Now you rely on the fact that you
either cool with cpufreq if freq table is present or you don't cool.
This is not scalable to what you are planing to do.


 + if (IS_ERR(th_zone-cool_dev[0])) {
 + pr_err(Failed to register cpufreq cooling device\n);
 + ret = -EINVAL;
 + goto err_unregister;
 + }
 + th_zone-cool_dev_size

Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

[Eduardo Valentin]

On 17-06-2013 02:46, 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
 Acked-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/samsung/Kconfig |   19 +-
  drivers/thermal/samsung/Makefile|4 +-
  drivers/thermal/samsung/exynos_thermal.c|  419 
 +--
  drivers/thermal/samsung/exynos_thermal_common.c |  384 +
  drivers/thermal/samsung/exynos_thermal_common.h |   83 +
  5 files changed, 490 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 2cf31ad..f8100b1 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -1,8 +1,17 @@
  config EXYNOS_THERMAL
 - tristate Temperature sensor on Samsung EXYNOS
 + tristate Exynos thermal management unit driver
   depends on ARCH_HAS_BANDGAP
   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 TMU (Thermal Management
 +   Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
 +   the TMU, reports temperature and handles cooling action if defined.
 +   This driver uses the exynos 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.
 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 03e4bbc..5293849 100644
 --- a/drivers/thermal/samsung/exynos_thermal.c
 +++ b/drivers/thermal/samsung/exynos_thermal.c
 @@ -21,23 +21,15 @@
   *
   */
  
 -#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/mutex.h
 -#include linux/platform_data/exynos_thermal.h
 -#include linux/thermal.h
 -#include linux/cpufreq.h
 -#include linux/cpu_cooling.h
 +#include linux/interrupt.h
 +#include linux/module.h
  #include linux/of.h
 +#include linux/platform_device.h
 +#include linux/platform_data/exynos_thermal.h
 +
 +#include exynos_thermal_common.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -88,16 +80,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 +88,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
 -
  struct exynos_tmu_data {
   struct exynos_tmu_platform_data *pdata;
   struct resource *mem;
 @@ -129,384 +100,6 @@ struct exynos_tmu_data {
   u8 temp_error1, temp_error2;
  };
  
 -struct   thermal_trip_point_conf {
 - int trip_val

[PATCH 1/1] thermal: MAINTAINERS: Add git tree path for SoC specific updates

[Eduardo Valentin]

To reduce thermal maintenance load on Rui, SoC specific patches would be
applied by me now. Rui Zhang will pull in these changes from time to time (at
rc's). Additionally I would be sending him pull request for every merge
window and rc's (for fixes).

Branch names would be: next and fixes.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d7782b..48ff6282 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8032,6 +8032,7 @@ M:  Zhang Rui rui.zh...@intel.com
 M:  Eduardo Valentin eduardo.valen...@ti.com
 L:  linux...@vger.kernel.org
 T:  git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
+T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
 Q:  https://patchwork.kernel.org/project/linux-pm/list/
 S:  Supported
 F:  drivers/thermal/
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] cpufreq: cpufreq-cpu0: add dt node parsing on cooling need

[Eduardo Valentin]

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the boolean
property 'needs-cooling'.

In case this boolean is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not capable of determining how the system should
be using the cooling device. This can be described using device
tree, to determine what needs to be done with the loaded
cpufreq cooling device, in case the system temperature is detected
to be high, with help of temperature sensors (check
Documentation/devicetree/bindings/thermal/thermal.txt).

Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |  3 ++
 .../devicetree/bindings/thermal/thermal.txt| 34 ++
 drivers/cpufreq/cpufreq-cpu0.c |  8 +
 3 files changed, 45 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..e8ff916 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,8 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- needs-cooling: The generic cpu cooling (freq clipping) is loaded by the
+generic cpufreq-cpu0 driver in case the device tree node has this boolean.
 
 Examples:
 
@@ -33,6 +35,7 @@ cpus {
198000  85
;
clock-latency = 61036; /* two CLK32 periods */
+   needs-cooling;
};
 
cpu@1 {
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
index 03751bb..ac0c7b9 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -97,3 +97,37 @@ thermal_zone {
 };
 };
 };
+
+***
+cpufreq-cooling
+***
+
+The generic cpu cooling (freq clipping) can be loaded by the
+generic cpufreq-cpu0 driver in case the device tree node informs
+this need.
+
+In order to load the cpufreq cooling device, it is possible to
+inform that the cpu needs cooling by adding the boolean flag
+'needs-cooling' at the cpu0 phandle.
+
+Example:
+   cpus {
+   cpu@0 {
+   operating-points = 
+   /* kHzuV */
+   80  1313000
+   1008000 1375000
+   ;
+   needs-cooling; /* make sure we have cpufreq-cooling */
+   };
+   ...
+   };
+
+The above will cause the cpufreq-cpu0 driver to understand that
+the cpu will need passive cooling and while probing that node it will
+also load the cpufreq cpu cooling device in that system.
+
+However, be advised that this flag will not describe what needs to
+be done or how the cpufreq cooling device will be used. In order to
+accomplish this, one needs to write a phandle for a thermal zone, as
+described in the section 'thermal_zone'.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..4a8747a 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
 #include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -268,6 +272,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
 
+   if (of_property_read_bool(np, needs-cooling))
+   cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +290,7 @@ out_put_parent:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+   cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver

[PATCH 5/9] thermal: introduce device tree parser

[Eduardo Valentin]

In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 .../devicetree/bindings/thermal/thermal.txt| 133 ++
 drivers/thermal/Kconfig|  13 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/thermal_dt.c   | 458 +
 include/dt-bindings/thermal/thermal.h  |  27 ++
 include/linux/thermal.h|   3 +
 6 files changed, 635 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/thermal_dt.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..ac0c7b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,133 @@
+
+Thermal Framework Device Tree descriptor
+
+
+This file describes how to define a thermal structure using device tree.
+A thermal structure includes thermal zones and their components, such
+as name, governor, trip points, polling intervals and cooling devices
+binding descriptors. A binding descriptor may contain information on
+how to react, with a cooling stepped action or a weight on a fair share.
+
+
+trip
+
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+A node describing a trip must contain:
+- temperature: the trip temperature level, in milliCelsius.
+- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
+value, in milliCelsius.
+- type: the trip type. Here is the type mapping:
+   THERMAL_TRIP_ACTIVE
+   THERMAL_TRIP_PASSIVE
+   THERMAL_TRIP_HOT
+   THERMAL_TRIP_CRITICAL
+
+**
+bind_param
+**
+
+The bind_param node is a node to describe how cooling devices get assigned
+to trip points of the zone. The cooling devices are expected to be loaded
+in the target system.
+
+A node describing a bind_param must contain:
+- cooling_device: A string with the cooling device name.
+- weight: The 'influence' of a particular cooling device on this zone.
+ This is on a percentage scale. The sum of all these weights
+ (for a particular zone) cannot exceed 100.
+- trip_mask: This is a bit mask that gives the binding relation between
+   this thermal zone and cdev, for a particular trip point.
+   If nth bit is set, then the cdev and thermal zone are bound
+   for trip point n.
+- limits: An array integers consisting of 2-tuples items, and each item means
+  lower and upper state limits, like min-state max-state.
+
+
+thermal_zone
+
+
+The thermal_zone node is the node containing all the required info
+for describing a thermal zone, including its cdev bindings. The thermal_zone
+node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone bind parameters.
+
+Required properties:
+- type: this is a string containing the zone type. Say 'cpu', 'core', 'mem', 
etc.
+- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
+
+- passive_delay: number of milliseconds to wait between polls when
+   performing passive cooling.
+- polling_delay: number of milliseconds to wait between polls when checking
+
+- governor: A string containing the default governor for this zone.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = THERMAL_TRIP_PASSIVE;
+};
+crit@125000{
+temperature = 125000; /* milliCelsius */
+hysteresis = 0; /* milliCelsius

[PATCH 8/9] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/lm75.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..0aa5e28 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include linux/hwmon-sysfs.h
 #include linux/err.h
 #include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
 #include lm75.h
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
struct device   *hwmon_dev;
+   struct thermal_zone_device  *tz;
struct mutexupdate_lock;
u8  orig_conf;
u8  resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device 
*dev);
 
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+   struct lm75_data *data = lm75_update_device(dev);
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   *temp = ((data-temp[0]  (16 - data-resolution)) * 1000) 
+   (data-resolution - 8);
+
+   return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 char *buf)
 {
@@ -271,11 +287,23 @@ lm75_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
goto exit_remove;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   data-tz = thermal_zone_of_device_register(client-dev,
+  client-dev,
+  lm75_read_temp);
+   if (IS_ERR(data-tz)) {
+   status = PTR_ERR(data-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, %s: sensor '%s'\n,
 dev_name(data-hwmon_dev), client-name);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(data-hwmon_dev);
 exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +313,7 @@ static int lm75_remove(struct i2c_client *client)
 {
struct lm75_data *data = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 9/9] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/tmp102.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..621093b 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include linux/mutex.h
 #include linux/device.h
 #include linux/jiffies.h
+#include linux/thermal.h
+#include linux/of.h
 
 #defineDRIVER_NAME tmp102
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
struct device *hwmon_dev;
+   struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client 
*client)
return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, unsigned long *temp)
+{
+   struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+   *temp = tmp102-temp[0];
+
+   return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,10 +216,22 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   tmp102-tz = thermal_zone_of_device_register(client-dev,
+client-dev,
+tmp102_read_temp);
+   if (IS_ERR(tmp102-tz)) {
+   status = PTR_ERR(tmp102-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, initialized\n);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(tmp102-hwmon_dev);
 fail_remove_sysfs:
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 fail_restore_config:
@@ -220,6 +244,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(tmp102-tz);
hwmon_device_unregister(tmp102-hwmon_dev);
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/8] arm: dts: flag omap4430 with needs-cooling for cpu node

[Eduardo Valentin]

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index c9a1c89..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -23,6 +23,7 @@
1008000 1375000
;
clock-latency = 30; /* From legacy driver */
+   needs-cooling; /* make sure we have cpufreq-cooling */
};
};
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/4] thermal: introduce device tree parser

[Eduardo Valentin]

On 09-07-2013 12:14, R, Durgadoss wrote:
 Hi Eduardo,
 
 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Tuesday, July 09, 2013 7:30 PM
 To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
 Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
 Subject: [RFC PATCH 2/4] thermal: introduce device tree parser

 In order to be able to build thermal policies
 based on generic sensors, like I2C device, that
 can be places in different points on different boards,
 there is a need to have a way to feed board dependent
 data into the thermal framework.

 This patch introduces a thermal data parser for device
 tree. The parsed data is used to build thermal zones
 and thermal binding parameters. The output data
 can then be used to deploy thermal policies.

 This patch adds also documentation regarding this
 API and how to define define tree nodes to use
 this infrastructure.

 Cc: Zhang Rui rui.zh...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
 
 I looked at the Documentation part of this. And it looks good.
 
 At some places you are using ERANGE. Technically, this represents
 'Math result not representable'. May be should be use EINVAL 
 itself ? I would leave it up to you ;)

I will be using EDOM in next version, tks

 
 Thanks,
 Durga
 
  .../devicetree/bindings/thermal/thermal.txt|  92 +
  drivers/thermal/Kconfig|  13 +
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/thermal_dt.c   | 412 
 +
  drivers/thermal/thermal_dt.h   |  44 +++
  include/linux/thermal.h|   3 +
  6 files changed, 565 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
  create mode 100644 drivers/thermal/thermal_dt.c
  create mode 100644 drivers/thermal/thermal_dt.h

 diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
 b/Documentation/devicetree/bindings/thermal/thermal.txt
 new file mode 100644
 index 000..2c25ab2
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
 @@ -0,0 +1,92 @@
 +
 +Thermal Framework Device Tree descriptor
 +
 +
 +This file describes how to define a thermal structure using device tree.
 +A thermal structure includes thermal zones and their components, such
 +as name, governor, trip points, polling intervals and cooling devices
 +binding descriptors. A binding descriptor may contain information on
 +how to react, with a cooling stepped action or a weight on a fair share.
 +
 +
 +trip
 +
 +
 +The trip node is a node to describe a point in the temperature domain
 +in which the system takes an action. This node describes just the point,
 +not the action.
 +
 +A node describing a trip must contain:
 +- temperature: the trip temperature level, in milliCelsius.
 +- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
 +value, in milliCelsius.
 +- type: the trip type. Here is the type mapping:
 +THERMAL_TRIP_ACTIVE = 0
 +THERMAL_TRIP_PASSIVE = 1
 +THERMAL_TRIP_HOT = 2
 +THERMAL_TRIP_CRITICAL = 3
 +
 +**
 +bind_param
 +**
 +
 +The bind_param node is a node to describe how cooling devices get assigned
 +to trip points of the zone. The cooling devices are expected to be loaded
 +in the target system.
 +
 +A node describing a bind_param must contain:
 +- cooling_device: A string with the cooling device name.
 +- weight: The 'influence' of a particular cooling device on this zone.
 + This is on a percentage scale. The sum of all these weights
 + (for a particular zone) cannot exceed 100.
 +- trip_mask: This is a bit mask that gives the binding relation between
 +   this thermal zone and cdev, for a particular trip point.
 +   If nth bit is set, then the cdev and thermal zone are bound
 +   for trip point n.
 +
 +
 +thermal_zone
 +
 +
 +The thermal_zone node is the node containing all the required info
 +for describing a thermal zone, including its cdev bindings. The thermal_zone
 +node must contain, apart from its own properties, one node containing
 +trip nodes and one node containing all the zone bind parameters.
 +
 +Required properties:
 +- type: this is a string containing the zone type. Say 'cpu', 'core', 
 'mem', etc.
 +- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
 +
 +- passive_delay: number of milliseconds to wait between polls when
 +performing passive cooling.
 +- polling_delay: number of milliseconds to wait between polls when checking
 +
 +- governor: A string containing the default governor for this zone.
 +
 +Below is an example:
 +thermal_zone {
 +type

[PATCH 1/9] cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'

[Eduardo Valentin]

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the boolean
property 'needs-cooling'.

In case this boolean is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 +++
 drivers/cpufreq/cpufreq-cpu0.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..e8ff916 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,8 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- needs-cooling: The generic cpu cooling (freq clipping) is loaded by the
+generic cpufreq-cpu0 driver in case the device tree node has this boolean.
 
 Examples:
 
@@ -33,6 +35,7 @@ cpus {
198000  85
;
clock-latency = 61036; /* two CLK32 periods */
+   needs-cooling;
};
 
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..4a8747a 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
 #include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -268,6 +272,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
 
+   if (of_property_read_bool(np, needs-cooling))
+   cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +290,7 @@ out_put_parent:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+   cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

Hi,

On 17-07-2013 11:02, Eduardo Valentin wrote:
 Hello all,
 


Looks like I sent duplicated series. Please consider the series
containing 9 patches. I will resend with proper set.


 As you noticed, I am working in a way to represent thermal data
 using device tree [1]. Essentially, this should be a way to say
 what to do with a sensor and how to associate (cooling) actions
 with it.
 
 The motivation to create such infrastructure is:
 (i) - to reuse the existing temperature sensor code base;
 (ii) - have a way to easily describe thermal data across different
 boards for the same sensor. Say you have an i2c temp sensor,
 which is placed close to your battery on board A but on
 board B, another instance of this same senor is placed
 close to your display, for instance.
 
 This series introduces then a DT parser. The data expected in
 DT must contain the needed properties to build a thermal zone
 out of the desired sensor. All properties are documented and
 they are derived from the existing requirements of current
 thermal API.
 
 In order to perform a binding with cooling devices,
 the new thermal zone built using DT nodes will use
 the existing thermal API that uses binding parameters. This is
 the current proposed way to register thermal zones with platform
 information, written by Durga.
 
 There are some virtual concepts that are pushed to device tree,
 I know. But I believe using device tree to do this makes sense
 because we are still describing the HW and how they are related
 to each other. Things like cooling devices are not represented
 in device tree though, as I believe that will cause a lot of
 confusion with real devices (as already does).
 
 So the series is short but I think it makes sense to describe
 how it is organized, as it touches several places. First four
 patches are a preparation for this parser. There is a change
 on cpufreq-cpu0, so that it knows now how to load its
 corresponding cooling device. There is a change on thermal_core
 to split its hwmon code, because I think we may need to improve
 this code base when we start to integrate better with hwmon
 temperature sensors. Then, another needed preparation is to
 improve the bind_params, so that we are able to bind with
 upper and lower limits. The remaining patches are the changes
 with the proposed DT parser. A part from the DT thermal zone
 builder itself (patch 05), I also changed the ti-soc-thermal
 driver to use this new API and the omap4430 bandgap DT node,
 as an example (this has been tested on panda omap4430); and also changed
 the hwmon drivers lm75 and tmp102 to have the option to build
 a thermal zone using DT. I haven't touched any dts file using
 lm75 or tmp102 because this should come on a need basis.
 
 I believe this code is pretty usable the way it is, but might
 need to be revisited, in case the enhancement proposed by Durga
 get in. This is because representing virtual thermal zones
 built out of several sensors may need a different representation
 in DT.
 
 [1] - RFC of this work:
 http://comments.gmane.org/gmane.linux.power-management.general/35874
 
 Changes from RFC:
 - Added a way to load cpufreq cooling device out of DT
 - Added a way to bind with upper and lower limits using bind_params
 - Added a way to specify upper and lower binding limits on DT
 - Added DT thermal builder support to lm75 and tmp102 hwmon drivers
 - Changed ERANGE to EDOM
 - Added thermal constants for zone type and bind limit, so that
   dts file could be more readable
 
 Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq 
 working)
 
 BR,
 
 Eduardo Valentin (9):
   cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'
   thermal: hwmon: move hwmon support to single file
   thermal: thermal_core: allow binding with limits on bind_params
   arm: dts: flag omap4430 with needs-cooling for cpu node
   thermal: introduce device tree parser
   thermal: ti-soc-thermal: use thermal DT infrastructure
   arm: dts: add omap4430 thermal data
   hwmon: lm75: expose to thermal fw via DT nodes
   hwmon: tmp102: expose to thermal fw via DT nodes
 
  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   3 +
  .../devicetree/bindings/thermal/thermal.txt| 133 ++
  Documentation/thermal/sysfs-api.txt|   7 +
  arch/arm/boot/dts/omap443x.dtsi|  32 +-
  drivers/cpufreq/cpufreq-cpu0.c |   8 +
  drivers/hwmon/lm75.c   |  29 ++
  drivers/hwmon/tmp102.c |  25 ++
  drivers/thermal/Kconfig|  22 +
  drivers/thermal/Makefile   |   4 +
  drivers/thermal/thermal_core.c | 274 +---
  drivers/thermal/thermal_dt.c   | 458 
 +
  drivers/thermal/thermal_hwmon.c| 269 
  drivers/thermal/thermal_hwmon.h|  49 +++
  drivers/thermal/ti-soc

[PATCH 8/8] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/tmp102.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..621093b 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include linux/mutex.h
 #include linux/device.h
 #include linux/jiffies.h
+#include linux/thermal.h
+#include linux/of.h
 
 #defineDRIVER_NAME tmp102
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
struct device *hwmon_dev;
+   struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client 
*client)
return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, unsigned long *temp)
+{
+   struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+   *temp = tmp102-temp[0];
+
+   return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,10 +216,22 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   tmp102-tz = thermal_zone_of_device_register(client-dev,
+client-dev,
+tmp102_read_temp);
+   if (IS_ERR(tmp102-tz)) {
+   status = PTR_ERR(tmp102-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, initialized\n);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(tmp102-hwmon_dev);
 fail_remove_sysfs:
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 fail_restore_config:
@@ -220,6 +244,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(tmp102-tz);
hwmon_device_unregister(tmp102-hwmon_dev);
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] thermal: ti-soc-thermal: use thermal DT infrastructure

[Eduardo Valentin]

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 46 +-
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4c5f55c37..de4e138 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include linux/cpufreq.h
 #include linux/cpumask.h
 #include linux/cpu_cooling.h
+#include linux/of.h
 
 #include ti-thermal.h
 #include ti-bandgap.h
@@ -75,11 +76,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int 
s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, unsigned long *temp)
 {
struct thermal_zone_device *pcb_tz = NULL;
-   struct ti_thermal_data *data = thermal-devdata;
+   struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +117,14 @@ static inline int ti_thermal_get_temp(struct 
thermal_zone_device *thermal,
return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+   struct ti_thermal_data *data = thermal-devdata;
+
+   return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
   struct thermal_cooling_device *cdev)
@@ -302,17 +310,27 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int 
id,
if (!data)
return -EINVAL;
 
-   /* Create thermal zone */
-   data-ti_thermal = thermal_zone_device_register(domain,
+   /* in case this is specified by DT */
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone)) {
+   data-ti_thermal = thermal_zone_of_device_register(bgp-dev,
+   data, __ti_thermal_get_temp);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, failed to build of thermal zone\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   } else {
+   /* Create thermal zone */
+   data-ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, ti_thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE);
-   if (IS_ERR(data-ti_thermal)) {
-   dev_err(bgp-dev, thermal zone device is NULL\n);
-   return PTR_ERR(data-ti_thermal);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, thermal zone device is NULL\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
+   ti_bandgap_set_sensor_data(bgp, id, data);
}
-   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
-   ti_bandgap_set_sensor_data(bgp, id, data);
 
return 0;
 }
@@ -343,6 +361,14 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap 
*bgp, int id)
 {
struct ti_thermal_data *data;
 
+   /*
+* We are assuming here that if one deploys the zone
+* using DT, then it must be aware that the cooling device
+* loading has to happen via cpufreq driver.
+*/
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone))
+   return 0;
+
data = ti_bandgap_get_sensor_data(bgp, id);
if (!data || IS_ERR(data))
data = ti_thermal_build_data(bgp, id);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel

[PATCH 1/8] thermal: thermal_core: allow binding with limits on bind_params

[Eduardo Valentin]

When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).

This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 Documentation/thermal/sysfs-api.txt |  7 +++
 drivers/thermal/thermal_core.c  | 19 +++
 include/linux/thermal.h | 10 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..2ad50e7 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -134,6 +134,13 @@ temperature) and throttle appropriate devices.
this thermal zone and cdev, for a particular trip point.
If nth bit is set, then the cdev and thermal zone are bound
for trip point n.
+.limits: This is an array of cooling state limits. Must have exactly
+ 2 * thermal_zone.number_of_trip_points. It is an array consisting
+ of tuples lower-state upper-state of state limits. Each trip
+ will be associated with one state limit tuple when binding.
+ A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+ on all trips. These limits are used when binding a cdev to a
+ trip point.
 .match: This call back returns success(0) if the 'tz and cdev' need to
be bound, as per platform data.
 1.4.2 struct thermal_zone_params
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 247528b..eadb901 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -202,14 +202,23 @@ static void print_bind_err_msg(struct thermal_zone_device 
*tz,
 }
 
 static void __bind(struct thermal_zone_device *tz, int mask,
-   struct thermal_cooling_device *cdev)
+   struct thermal_cooling_device *cdev,
+   unsigned long *limits)
 {
int i, ret;
 
for (i = 0; i  tz-trips; i++) {
if (mask  (1  i)) {
+   unsigned long upper, lower;
+
+   upper = THERMAL_NO_LIMIT;
+   lower = THERMAL_NO_LIMIT;
+   if (limits) {
+   lower = limits[i * 2];
+   upper = limits[i * 2 + 1];
+   }
ret = thermal_zone_bind_cooling_device(tz, i, cdev,
-   THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+  lower, upper);
if (ret)
print_bind_err_msg(tz, cdev, ret);
}
@@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (tzp-tbp[i].match(pos, cdev))
continue;
tzp-tbp[i].cdev = cdev;
-   __bind(pos, tzp-tbp[i].trip_mask, cdev);
+   __bind(pos, tzp-tbp[i].trip_mask, cdev,
+  tzp-tbp[i].binding_limits);
}
}
 
@@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
if (tzp-tbp[i].match(tz, pos))
continue;
tzp-tbp[i].cdev = pos;
-   __bind(tz, tzp-tbp[i].trip_mask, pos);
+   __bind(tz, tzp-tbp[i].trip_mask, pos,
+  tzp-tbp[i].binding_limits);
}
}
 exit:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..39575eb 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -207,6 +207,16 @@ struct thermal_bind_params {
 * See Documentation/thermal/sysfs-api.txt for more information.
 */
int trip_mask;
+
+   /*
+* This is an array of cooling state limits. Must have exactly
+* 2 * thermal_zone.number_of_trip_points. It is an array consisting
+* of tuples lower-state upper-state of state limits. Each trip
+* will be associated with one state limit tuple when binding.
+* A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+* on all trips.
+*/
+   unsigned long *binding_limits;
int (*match) (struct thermal_zone_device *tz,
struct thermal_cooling_device *cdev);
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux

[PATCH 7/9] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include dt-bindings/thermal/thermal.h
 #include omap4.dtsi
 
 / {
@@ -27,8 +28,34 @@
};
 
bandgap {
-   reg = 0x4a002260 0x4
-  0x4a00232C 0x4;
+   reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+   thermal_zone {
+   type = CPU;
+   mask = 0x03; /* trips writability */
+   passive_delay = 250; /* milliseconds */
+   polling_delay = 1000; /* milliseconds */
+   governor = step_wise;
+   trips {
+   alert@10{
+   temperature = 10; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_PASSIVE;
+   };
+   crit@125000{
+   temperature = 125000; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_CRITICAL;
+   };
+   };
+   bind_params {
+   action@0{
+   cooling_device = thermal-cpufreq;
+   weight = 100; /* percentage */
+   mask = 0x01;
+   /* no limits, using defaults */
+   };
+   };
+   };
};
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/9] thermal: ti-soc-thermal: use thermal DT infrastructure

[Eduardo Valentin]

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 46 +-
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4c5f55c37..de4e138 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include linux/cpufreq.h
 #include linux/cpumask.h
 #include linux/cpu_cooling.h
+#include linux/of.h
 
 #include ti-thermal.h
 #include ti-bandgap.h
@@ -75,11 +76,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int 
s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, unsigned long *temp)
 {
struct thermal_zone_device *pcb_tz = NULL;
-   struct ti_thermal_data *data = thermal-devdata;
+   struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +117,14 @@ static inline int ti_thermal_get_temp(struct 
thermal_zone_device *thermal,
return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+   struct ti_thermal_data *data = thermal-devdata;
+
+   return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
   struct thermal_cooling_device *cdev)
@@ -302,17 +310,27 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int 
id,
if (!data)
return -EINVAL;
 
-   /* Create thermal zone */
-   data-ti_thermal = thermal_zone_device_register(domain,
+   /* in case this is specified by DT */
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone)) {
+   data-ti_thermal = thermal_zone_of_device_register(bgp-dev,
+   data, __ti_thermal_get_temp);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, failed to build of thermal zone\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   } else {
+   /* Create thermal zone */
+   data-ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, ti_thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE);
-   if (IS_ERR(data-ti_thermal)) {
-   dev_err(bgp-dev, thermal zone device is NULL\n);
-   return PTR_ERR(data-ti_thermal);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, thermal zone device is NULL\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
+   ti_bandgap_set_sensor_data(bgp, id, data);
}
-   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
-   ti_bandgap_set_sensor_data(bgp, id, data);
 
return 0;
 }
@@ -343,6 +361,14 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap 
*bgp, int id)
 {
struct ti_thermal_data *data;
 
+   /*
+* We are assuming here that if one deploys the zone
+* using DT, then it must be aware that the cooling device
+* loading has to happen via cpufreq driver.
+*/
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone))
+   return 0;
+
data = ti_bandgap_get_sensor_data(bgp, id);
if (!data || IS_ERR(data))
data = ti_thermal_build_data(bgp, id);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel

[PATCH 2/9] thermal: hwmon: move hwmon support to single file

[Eduardo Valentin]

In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.

In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/Kconfig |   9 ++
 drivers/thermal/Makefile|   3 +
 drivers/thermal/thermal_core.c  | 255 +
 drivers/thermal/thermal_hwmon.c | 269 
 drivers/thermal/thermal_hwmon.h |  49 
 5 files changed, 331 insertions(+), 254 deletions(-)
 create mode 100644 drivers/thermal/thermal_hwmon.c
 create mode 100644 drivers/thermal/thermal_hwmon.h

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e988c81..7fb16bc 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,8 +17,17 @@ if THERMAL
 
 config THERMAL_HWMON
bool
+   prompt Expose thermal sensors as hwmon device
depends on HWMON=y || HWMON=THERMAL
default y
+   help
+ In case a sensor is registered with the thermal
+ framework, this option will also register it
+ as a hwmon. The sensor will then have the common
+ hwmon sysfs interface.
+
+ Say 'Y' here if you want all thermal sensors to
+ have hwmon sysfs interface too.
 
 choice
prompt Default Thermal governor
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..24cb894 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -5,6 +5,9 @@
 obj-$(CONFIG_THERMAL)  += thermal_sys.o
 thermal_sys-y  += thermal_core.o
 
+# interface to/from other layers providing sensors
+thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
+
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
 thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 1f02e8e..247528b 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -38,6 +38,7 @@
 #include net/genetlink.h
 
 #include thermal_core.h
+#include thermal_hwmon.h
 
 MODULE_AUTHOR(Zhang Rui);
 MODULE_DESCRIPTION(Generic thermal management sysfs support);
@@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device *dev,
 
 /* Device management */
 
-#if defined(CONFIG_THERMAL_HWMON)
-
-/* hwmon sys I/F */
-#include linux/hwmon.h
-
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
-   char type[THERMAL_NAME_LENGTH];
-   struct device *device;
-   int count;
-   struct list_head tz_list;
-   struct list_head node;
-};
-
-struct thermal_hwmon_attr {
-   struct device_attribute attr;
-   char name[16];
-};
-
-/* one temperature input for each thermal zone */
-struct thermal_hwmon_temp {
-   struct list_head hwmon_node;
-   struct thermal_zone_device *tz;
-   struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
-   struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
-};
-
-static LIST_HEAD(thermal_hwmon_list);
-
-static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
-   return sprintf(buf, %s\n, hwmon-type);
-}
-static DEVICE_ATTR(name, 0444, name_show, NULL);
-
-static ssize_t
-temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   long temperature;
-   int ret;
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_input);
-   struct thermal_zone_device *tz = temp-tz;
-
-   ret = thermal_zone_get_temp(tz, temperature);
-
-   if (ret)
-   return ret;
-
-   return sprintf(buf, %ld\n, temperature);
-}
-
-static ssize_t
-temp_crit_show(struct device *dev, struct device_attribute *attr,
-   char *buf)
-{
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_crit);
-   struct thermal_zone_device *tz = temp-tz;
-   long temperature;
-   int ret;
-
-   ret = tz-ops-get_trip_temp(tz, 0, temperature);
-   if (ret

[PATCH 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

Hello all,

As you noticed, I am working in a way to represent thermal data
using device tree [1]. Essentially, this should be a way to say
what to do with a sensor and how to associate (cooling) actions
with it.

The motivation to create such infrastructure is:
(i) - to reuse the existing temperature sensor code base;
(ii) - have a way to easily describe thermal data across different
boards for the same sensor. Say you have an i2c temp sensor,
which is placed close to your battery on board A but on
board B, another instance of this same senor is placed
close to your display, for instance.

This series introduces then a DT parser. The data expected in
DT must contain the needed properties to build a thermal zone
out of the desired sensor. All properties are documented and
they are derived from the existing requirements of current
thermal API.

In order to perform a binding with cooling devices,
the new thermal zone built using DT nodes will use
the existing thermal API that uses binding parameters. This is
the current proposed way to register thermal zones with platform
information, written by Durga.

There are some virtual concepts that are pushed to device tree,
I know. But I believe using device tree to do this makes sense
because we are still describing the HW and how they are related
to each other. Things like cooling devices are not represented
in device tree though, as I believe that will cause a lot of
confusion with real devices (as already does).

So the series is short but I think it makes sense to describe
how it is organized, as it touches several places. First four
patches are a preparation for this parser. There is a change
on cpufreq-cpu0, so that it knows now how to load its
corresponding cooling device. There is a change on thermal_core
to split its hwmon code, because I think we may need to improve
this code base when we start to integrate better with hwmon
temperature sensors. Then, another needed preparation is to
improve the bind_params, so that we are able to bind with
upper and lower limits. The remaining patches are the changes
with the proposed DT parser. A part from the DT thermal zone
builder itself (patch 05), I also changed the ti-soc-thermal
driver to use this new API and the omap4430 bandgap DT node,
as an example (this has been tested on panda omap4430); and also changed
the hwmon drivers lm75 and tmp102 to have the option to build
a thermal zone using DT. I haven't touched any dts file using
lm75 or tmp102 because this should come on a need basis.

I believe this code is pretty usable the way it is, but might
need to be revisited, in case the enhancement proposed by Durga
get in. This is because representing virtual thermal zones
built out of several sensors may need a different representation
in DT.

[1] - RFC of this work:
http://comments.gmane.org/gmane.linux.power-management.general/35874

Changes from RFC:
- Added a way to load cpufreq cooling device out of DT
- Added a way to bind with upper and lower limits using bind_params
- Added a way to specify upper and lower binding limits on DT
- Added DT thermal builder support to lm75 and tmp102 hwmon drivers
- Changed ERANGE to EDOM
- Added thermal constants for zone type and bind limit, so that
  dts file could be more readable

Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq 
working)

BR,

Eduardo Valentin (9):
  cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'
  thermal: hwmon: move hwmon support to single file
  thermal: thermal_core: allow binding with limits on bind_params
  arm: dts: flag omap4430 with needs-cooling for cpu node
  thermal: introduce device tree parser
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4430 thermal data
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   3 +
 .../devicetree/bindings/thermal/thermal.txt| 133 ++
 Documentation/thermal/sysfs-api.txt|   7 +
 arch/arm/boot/dts/omap443x.dtsi|  32 +-
 drivers/cpufreq/cpufreq-cpu0.c |   8 +
 drivers/hwmon/lm75.c   |  29 ++
 drivers/hwmon/tmp102.c |  25 ++
 drivers/thermal/Kconfig|  22 +
 drivers/thermal/Makefile   |   4 +
 drivers/thermal/thermal_core.c | 274 +---
 drivers/thermal/thermal_dt.c   | 458 +
 drivers/thermal/thermal_hwmon.c| 269 
 drivers/thermal/thermal_hwmon.h|  49 +++
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  46 ++-
 include/dt-bindings/thermal/thermal.h  |  27 ++
 include/linux/thermal.h|  13 +
 16 files changed, 1129 insertions(+), 270 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal

[PATCH 5/8] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..c9a1c89 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include dt-bindings/thermal/thermal.h
 #include omap4.dtsi
 
 / {
@@ -26,8 +27,34 @@
};
 
bandgap {
-   reg = 0x4a002260 0x4
-  0x4a00232C 0x4;
+   reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+   thermal_zone {
+   type = CPU;
+   mask = 0x03; /* trips writability */
+   passive_delay = 250; /* milliseconds */
+   polling_delay = 1000; /* milliseconds */
+   governor = step_wise;
+   trips {
+   alert@10{
+   temperature = 10; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_PASSIVE;
+   };
+   crit@125000{
+   temperature = 125000; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_CRITICAL;
+   };
+   };
+   bind_params {
+   action@0{
+   cooling_device = thermal-cpufreq;
+   weight = 100; /* percentage */
+   mask = 0x01;
+   /* no limits, using defaults */
+   };
+   };
+   };
};
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node

[Eduardo Valentin]

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..4a4dcc3 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,7 @@
1008000 1375000
;
clock-latency = 30; /* From legacy driver */
+   needs-cooling; /* make sure we have cpufreq-cooling */
};
};
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 5/9] thermal: introduce device tree parser

[Eduardo Valentin]

In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 .../devicetree/bindings/thermal/thermal.txt| 133 ++
 drivers/thermal/Kconfig|  13 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/thermal_dt.c   | 458 +
 include/dt-bindings/thermal/thermal.h  |  27 ++
 include/linux/thermal.h|   3 +
 6 files changed, 635 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/thermal_dt.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..ac0c7b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,133 @@
+
+Thermal Framework Device Tree descriptor
+
+
+This file describes how to define a thermal structure using device tree.
+A thermal structure includes thermal zones and their components, such
+as name, governor, trip points, polling intervals and cooling devices
+binding descriptors. A binding descriptor may contain information on
+how to react, with a cooling stepped action or a weight on a fair share.
+
+
+trip
+
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+A node describing a trip must contain:
+- temperature: the trip temperature level, in milliCelsius.
+- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
+value, in milliCelsius.
+- type: the trip type. Here is the type mapping:
+   THERMAL_TRIP_ACTIVE
+   THERMAL_TRIP_PASSIVE
+   THERMAL_TRIP_HOT
+   THERMAL_TRIP_CRITICAL
+
+**
+bind_param
+**
+
+The bind_param node is a node to describe how cooling devices get assigned
+to trip points of the zone. The cooling devices are expected to be loaded
+in the target system.
+
+A node describing a bind_param must contain:
+- cooling_device: A string with the cooling device name.
+- weight: The 'influence' of a particular cooling device on this zone.
+ This is on a percentage scale. The sum of all these weights
+ (for a particular zone) cannot exceed 100.
+- trip_mask: This is a bit mask that gives the binding relation between
+   this thermal zone and cdev, for a particular trip point.
+   If nth bit is set, then the cdev and thermal zone are bound
+   for trip point n.
+- limits: An array integers consisting of 2-tuples items, and each item means
+  lower and upper state limits, like min-state max-state.
+
+
+thermal_zone
+
+
+The thermal_zone node is the node containing all the required info
+for describing a thermal zone, including its cdev bindings. The thermal_zone
+node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone bind parameters.
+
+Required properties:
+- type: this is a string containing the zone type. Say 'cpu', 'core', 'mem', 
etc.
+- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
+
+- passive_delay: number of milliseconds to wait between polls when
+   performing passive cooling.
+- polling_delay: number of milliseconds to wait between polls when checking
+
+- governor: A string containing the default governor for this zone.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = THERMAL_TRIP_PASSIVE;
+};
+crit@125000{
+temperature = 125000; /* milliCelsius */
+hysteresis = 0; /* milliCelsius

[RESEND PATCH V1 6/9] thermal: ti-soc-thermal: use thermal DT infrastructure

[Eduardo Valentin]

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 46 +-
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4c5f55c37..de4e138 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include linux/cpufreq.h
 #include linux/cpumask.h
 #include linux/cpu_cooling.h
+#include linux/of.h
 
 #include ti-thermal.h
 #include ti-bandgap.h
@@ -75,11 +76,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int 
s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, unsigned long *temp)
 {
struct thermal_zone_device *pcb_tz = NULL;
-   struct ti_thermal_data *data = thermal-devdata;
+   struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +117,14 @@ static inline int ti_thermal_get_temp(struct 
thermal_zone_device *thermal,
return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+   struct ti_thermal_data *data = thermal-devdata;
+
+   return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
   struct thermal_cooling_device *cdev)
@@ -302,17 +310,27 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int 
id,
if (!data)
return -EINVAL;
 
-   /* Create thermal zone */
-   data-ti_thermal = thermal_zone_device_register(domain,
+   /* in case this is specified by DT */
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone)) {
+   data-ti_thermal = thermal_zone_of_device_register(bgp-dev,
+   data, __ti_thermal_get_temp);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, failed to build of thermal zone\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   } else {
+   /* Create thermal zone */
+   data-ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, ti_thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE);
-   if (IS_ERR(data-ti_thermal)) {
-   dev_err(bgp-dev, thermal zone device is NULL\n);
-   return PTR_ERR(data-ti_thermal);
+   if (IS_ERR(data-ti_thermal)) {
+   dev_err(bgp-dev, thermal zone device is NULL\n);
+   return PTR_ERR(data-ti_thermal);
+   }
+   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
+   ti_bandgap_set_sensor_data(bgp, id, data);
}
-   data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
-   ti_bandgap_set_sensor_data(bgp, id, data);
 
return 0;
 }
@@ -343,6 +361,14 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap 
*bgp, int id)
 {
struct ti_thermal_data *data;
 
+   /*
+* We are assuming here that if one deploys the zone
+* using DT, then it must be aware that the cooling device
+* loading has to happen via cpufreq driver.
+*/
+   if (of_find_node_by_name(bgp-dev-of_node, thermal_zone))
+   return 0;
+
data = ti_bandgap_get_sensor_data(bgp, id);
if (!data || IS_ERR(data))
data = ti_thermal_build_data(bgp, id);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel

[RESEND PATCH V1 8/9] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/lm75.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..0aa5e28 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include linux/hwmon-sysfs.h
 #include linux/err.h
 #include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
 #include lm75.h
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
struct device   *hwmon_dev;
+   struct thermal_zone_device  *tz;
struct mutexupdate_lock;
u8  orig_conf;
u8  resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device 
*dev);
 
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+   struct lm75_data *data = lm75_update_device(dev);
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   *temp = ((data-temp[0]  (16 - data-resolution)) * 1000) 
+   (data-resolution - 8);
+
+   return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 char *buf)
 {
@@ -271,11 +287,23 @@ lm75_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
goto exit_remove;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   data-tz = thermal_zone_of_device_register(client-dev,
+  client-dev,
+  lm75_read_temp);
+   if (IS_ERR(data-tz)) {
+   status = PTR_ERR(data-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, %s: sensor '%s'\n,
 dev_name(data-hwmon_dev), client-name);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(data-hwmon_dev);
 exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +313,7 @@ static int lm75_remove(struct i2c_client *client)
 {
struct lm75_data *data = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 1/9] cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'

[Eduardo Valentin]

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the boolean
property 'needs-cooling'.

In case this boolean is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 +++
 drivers/cpufreq/cpufreq-cpu0.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..e8ff916 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,8 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- needs-cooling: The generic cpu cooling (freq clipping) is loaded by the
+generic cpufreq-cpu0 driver in case the device tree node has this boolean.
 
 Examples:
 
@@ -33,6 +35,7 @@ cpus {
198000  85
;
clock-latency = 61036; /* two CLK32 periods */
+   needs-cooling;
};
 
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..4a8747a 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
 #include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -268,6 +272,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
 
+   if (of_property_read_bool(np, needs-cooling))
+   cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +290,7 @@ out_put_parent:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+   cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node

[Eduardo Valentin]

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..4a4dcc3 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,7 @@
1008000 1375000
;
clock-latency = 30; /* From legacy driver */
+   needs-cooling; /* make sure we have cpufreq-cooling */
};
};
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 7/9] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include dt-bindings/thermal/thermal.h
 #include omap4.dtsi
 
 / {
@@ -27,8 +28,34 @@
};
 
bandgap {
-   reg = 0x4a002260 0x4
-  0x4a00232C 0x4;
+   reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+   thermal_zone {
+   type = CPU;
+   mask = 0x03; /* trips writability */
+   passive_delay = 250; /* milliseconds */
+   polling_delay = 1000; /* milliseconds */
+   governor = step_wise;
+   trips {
+   alert@10{
+   temperature = 10; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_PASSIVE;
+   };
+   crit@125000{
+   temperature = 125000; /* milliCelsius 
*/
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_CRITICAL;
+   };
+   };
+   bind_params {
+   action@0{
+   cooling_device = thermal-cpufreq;
+   weight = 100; /* percentage */
+   mask = 0x01;
+   /* no limits, using defaults */
+   };
+   };
+   };
};
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 9/9] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/tmp102.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..621093b 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include linux/mutex.h
 #include linux/device.h
 #include linux/jiffies.h
+#include linux/thermal.h
+#include linux/of.h
 
 #defineDRIVER_NAME tmp102
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
struct device *hwmon_dev;
+   struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client 
*client)
return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, unsigned long *temp)
+{
+   struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+   *temp = tmp102-temp[0];
+
+   return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,10 +216,22 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   tmp102-tz = thermal_zone_of_device_register(client-dev,
+client-dev,
+tmp102_read_temp);
+   if (IS_ERR(tmp102-tz)) {
+   status = PTR_ERR(tmp102-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, initialized\n);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(tmp102-hwmon_dev);
 fail_remove_sysfs:
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 fail_restore_config:
@@ -220,6 +244,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(tmp102-tz);
hwmon_device_unregister(tmp102-hwmon_dev);
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH V1 3/9] thermal: thermal_core: allow binding with limits on bind_params

[Eduardo Valentin]

When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).

This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 Documentation/thermal/sysfs-api.txt |  7 +++
 drivers/thermal/thermal_core.c  | 19 +++
 include/linux/thermal.h | 10 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..2ad50e7 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -134,6 +134,13 @@ temperature) and throttle appropriate devices.
this thermal zone and cdev, for a particular trip point.
If nth bit is set, then the cdev and thermal zone are bound
for trip point n.
+.limits: This is an array of cooling state limits. Must have exactly
+ 2 * thermal_zone.number_of_trip_points. It is an array consisting
+ of tuples lower-state upper-state of state limits. Each trip
+ will be associated with one state limit tuple when binding.
+ A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+ on all trips. These limits are used when binding a cdev to a
+ trip point.
 .match: This call back returns success(0) if the 'tz and cdev' need to
be bound, as per platform data.
 1.4.2 struct thermal_zone_params
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 247528b..096c8be 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -202,14 +202,23 @@ static void print_bind_err_msg(struct thermal_zone_device 
*tz,
 }
 
 static void __bind(struct thermal_zone_device *tz, int mask,
-   struct thermal_cooling_device *cdev)
+   struct thermal_cooling_device *cdev,
+   unsigned long *limits)
 {
int i, ret;
 
for (i = 0; i  tz-trips; i++) {
if (mask  (1  i)) {
+   unsigned long upper, lower;
+
+   upper = THERMAL_NO_LIMIT;
+   lower = THERMAL_NO_LIMIT;
+   if (limits) {
+   lower = limits[i * 2];
+   upper = limits[i * 2 + 1];
+   }
ret = thermal_zone_bind_cooling_device(tz, i, cdev,
-   THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+  upper, lower);
if (ret)
print_bind_err_msg(tz, cdev, ret);
}
@@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (tzp-tbp[i].match(pos, cdev))
continue;
tzp-tbp[i].cdev = cdev;
-   __bind(pos, tzp-tbp[i].trip_mask, cdev);
+   __bind(pos, tzp-tbp[i].trip_mask, cdev,
+  tzp-tbp[i].binding_limits);
}
}
 
@@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
if (tzp-tbp[i].match(tz, pos))
continue;
tzp-tbp[i].cdev = pos;
-   __bind(tz, tzp-tbp[i].trip_mask, pos);
+   __bind(tz, tzp-tbp[i].trip_mask, pos,
+  tzp-tbp[i].binding_limits);
}
}
 exit:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..39575eb 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -207,6 +207,16 @@ struct thermal_bind_params {
 * See Documentation/thermal/sysfs-api.txt for more information.
 */
int trip_mask;
+
+   /*
+* This is an array of cooling state limits. Must have exactly
+* 2 * thermal_zone.number_of_trip_points. It is an array consisting
+* of tuples lower-state upper-state of state limits. Each trip
+* will be associated with one state limit tuple when binding.
+* A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+* on all trips.
+*/
+   unsigned long *binding_limits;
int (*match) (struct thermal_zone_device *tz,
struct thermal_cooling_device *cdev);
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux

[RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

Hello all,

As you noticed, I am working in a way to represent thermal data
using device tree [1]. Essentially, this should be a way to say
what to do with a sensor and how to associate (cooling) actions
with it.

The motivation to create such infrastructure is:
(i) - to reuse the existing temperature sensor code base;
(ii) - have a way to easily describe thermal data across different
boards for the same sensor. Say you have an i2c temp sensor,
which is placed close to your battery on board A but on
board B, another instance of this same senor is placed
close to your display, for instance.

This series introduces then a DT parser. The data expected in
DT must contain the needed properties to build a thermal zone
out of the desired sensor. All properties are documented and
they are derived from the existing requirements of current
thermal API.

In order to perform a binding with cooling devices,
the new thermal zone built using DT nodes will use
the existing thermal API that uses binding parameters. This is
the current proposed way to register thermal zones with platform
information, written by Durga.

There are some virtual concepts that are pushed to device tree,
I know. But I believe using device tree to do this makes sense
because we are still describing the HW and how they are related
to each other. Things like cooling devices are not represented
in device tree though, as I believe that will cause a lot of
confusion with real devices (as already does).

So the series is short but I think it makes sense to describe
how it is organized, as it touches several places. First four
patches are a preparation for this parser. There is a change
on cpufreq-cpu0, so that it knows now how to load its
corresponding cooling device. There is a change on thermal_core
to split its hwmon code, because I think we may need to improve
this code base when we start to integrate better with hwmon
temperature sensors. Then, another needed preparation is to
improve the bind_params, so that we are able to bind with
upper and lower limits. The remaining patches are the changes
with the proposed DT parser. A part from the DT thermal zone
builder itself (patch 05), I also changed the ti-soc-thermal
driver to use this new API and the omap4430 bandgap DT node,
as an example (this has been tested on panda omap4430); and also changed
the hwmon drivers lm75 and tmp102 to have the option to build
a thermal zone using DT. I haven't touched any dts file using
lm75 or tmp102 because this should come on a need basis.

I believe this code is pretty usable the way it is, but might
need to be revisited, in case the enhancement proposed by Durga
get in. This is because representing virtual thermal zones
built out of several sensors may need a different representation
in DT.

[1] - RFC of this work:
http://comments.gmane.org/gmane.linux.power-management.general/35874

Changes from RFC:
- Added a way to load cpufreq cooling device out of DT
- Added a way to bind with upper and lower limits using bind_params
- Added a way to specify upper and lower binding limits on DT
- Added DT thermal builder support to lm75 and tmp102 hwmon drivers
- Changed ERANGE to EDOM
- Added thermal constants for zone type and bind limit, so that
  dts file could be more readable

Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq 
working)

BR,

Eduardo Valentin (9):
  cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'
  thermal: hwmon: move hwmon support to single file
  thermal: thermal_core: allow binding with limits on bind_params
  arm: dts: flag omap4430 with needs-cooling for cpu node
  thermal: introduce device tree parser
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4430 thermal data
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   3 +
 .../devicetree/bindings/thermal/thermal.txt| 133 ++
 Documentation/thermal/sysfs-api.txt|   7 +
 arch/arm/boot/dts/omap443x.dtsi|  32 +-
 drivers/cpufreq/cpufreq-cpu0.c |   8 +
 drivers/hwmon/lm75.c   |  29 ++
 drivers/hwmon/tmp102.c |  25 ++
 drivers/thermal/Kconfig|  22 +
 drivers/thermal/Makefile   |   4 +
 drivers/thermal/thermal_core.c | 274 +---
 drivers/thermal/thermal_dt.c   | 458 +
 drivers/thermal/thermal_hwmon.c| 269 
 drivers/thermal/thermal_hwmon.h|  49 +++
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  46 ++-
 include/dt-bindings/thermal/thermal.h  |  27 ++
 include/linux/thermal.h|  13 +
 16 files changed, 1129 insertions(+), 270 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal

[PATCH 1/8] thermal: hwmon: move hwmon support to single file

[Eduardo Valentin]

In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.

In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/Kconfig |   9 ++
 drivers/thermal/Makefile|   3 +
 drivers/thermal/thermal_core.c  | 255 +-
 drivers/thermal/thermal_hwmon.c | 268 
 drivers/thermal/thermal_hwmon.h |  49 
 5 files changed, 330 insertions(+), 254 deletions(-)
 create mode 100644 drivers/thermal/thermal_hwmon.c
 create mode 100644 drivers/thermal/thermal_hwmon.h

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e988c81..7fb16bc 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,8 +17,17 @@ if THERMAL
 
 config THERMAL_HWMON
bool
+   prompt Expose thermal sensors as hwmon device
depends on HWMON=y || HWMON=THERMAL
default y
+   help
+ In case a sensor is registered with the thermal
+ framework, this option will also register it
+ as a hwmon. The sensor will then have the common
+ hwmon sysfs interface.
+
+ Say 'Y' here if you want all thermal sensors to
+ have hwmon sysfs interface too.
 
 choice
prompt Default Thermal governor
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..24cb894 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -5,6 +5,9 @@
 obj-$(CONFIG_THERMAL)  += thermal_sys.o
 thermal_sys-y  += thermal_core.o
 
+# interface to/from other layers providing sensors
+thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
+
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
 thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 1f02e8e..247528b 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -38,6 +38,7 @@
 #include net/genetlink.h
 
 #include thermal_core.h
+#include thermal_hwmon.h
 
 MODULE_AUTHOR(Zhang Rui);
 MODULE_DESCRIPTION(Generic thermal management sysfs support);
@@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device *dev,
 
 /* Device management */
 
-#if defined(CONFIG_THERMAL_HWMON)
-
-/* hwmon sys I/F */
-#include linux/hwmon.h
-
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
-   char type[THERMAL_NAME_LENGTH];
-   struct device *device;
-   int count;
-   struct list_head tz_list;
-   struct list_head node;
-};
-
-struct thermal_hwmon_attr {
-   struct device_attribute attr;
-   char name[16];
-};
-
-/* one temperature input for each thermal zone */
-struct thermal_hwmon_temp {
-   struct list_head hwmon_node;
-   struct thermal_zone_device *tz;
-   struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
-   struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
-};
-
-static LIST_HEAD(thermal_hwmon_list);
-
-static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
-   return sprintf(buf, %s\n, hwmon-type);
-}
-static DEVICE_ATTR(name, 0444, name_show, NULL);
-
-static ssize_t
-temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   long temperature;
-   int ret;
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_input);
-   struct thermal_zone_device *tz = temp-tz;
-
-   ret = thermal_zone_get_temp(tz, temperature);
-
-   if (ret)
-   return ret;
-
-   return sprintf(buf, %ld\n, temperature);
-}
-
-static ssize_t
-temp_crit_show(struct device *dev, struct device_attribute *attr,
-   char *buf)
-{
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_crit);
-   struct thermal_zone_device *tz = temp-tz;
-   long temperature;
-   int ret;
-
-   ret = tz-ops-get_trip_temp(tz, 0, temperature);
-   if (ret

[RESEND PATCH V1 2/9] thermal: hwmon: move hwmon support to single file

[Eduardo Valentin]

In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.

In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/Kconfig |   9 ++
 drivers/thermal/Makefile|   3 +
 drivers/thermal/thermal_core.c  | 255 +
 drivers/thermal/thermal_hwmon.c | 269 
 drivers/thermal/thermal_hwmon.h |  49 
 5 files changed, 331 insertions(+), 254 deletions(-)
 create mode 100644 drivers/thermal/thermal_hwmon.c
 create mode 100644 drivers/thermal/thermal_hwmon.h

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e988c81..7fb16bc 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,8 +17,17 @@ if THERMAL
 
 config THERMAL_HWMON
bool
+   prompt Expose thermal sensors as hwmon device
depends on HWMON=y || HWMON=THERMAL
default y
+   help
+ In case a sensor is registered with the thermal
+ framework, this option will also register it
+ as a hwmon. The sensor will then have the common
+ hwmon sysfs interface.
+
+ Say 'Y' here if you want all thermal sensors to
+ have hwmon sysfs interface too.
 
 choice
prompt Default Thermal governor
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..24cb894 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -5,6 +5,9 @@
 obj-$(CONFIG_THERMAL)  += thermal_sys.o
 thermal_sys-y  += thermal_core.o
 
+# interface to/from other layers providing sensors
+thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
+
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
 thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 1f02e8e..247528b 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -38,6 +38,7 @@
 #include net/genetlink.h
 
 #include thermal_core.h
+#include thermal_hwmon.h
 
 MODULE_AUTHOR(Zhang Rui);
 MODULE_DESCRIPTION(Generic thermal management sysfs support);
@@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device *dev,
 
 /* Device management */
 
-#if defined(CONFIG_THERMAL_HWMON)
-
-/* hwmon sys I/F */
-#include linux/hwmon.h
-
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
-   char type[THERMAL_NAME_LENGTH];
-   struct device *device;
-   int count;
-   struct list_head tz_list;
-   struct list_head node;
-};
-
-struct thermal_hwmon_attr {
-   struct device_attribute attr;
-   char name[16];
-};
-
-/* one temperature input for each thermal zone */
-struct thermal_hwmon_temp {
-   struct list_head hwmon_node;
-   struct thermal_zone_device *tz;
-   struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
-   struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
-};
-
-static LIST_HEAD(thermal_hwmon_list);
-
-static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
-   return sprintf(buf, %s\n, hwmon-type);
-}
-static DEVICE_ATTR(name, 0444, name_show, NULL);
-
-static ssize_t
-temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   long temperature;
-   int ret;
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_input);
-   struct thermal_zone_device *tz = temp-tz;
-
-   ret = thermal_zone_get_temp(tz, temperature);
-
-   if (ret)
-   return ret;
-
-   return sprintf(buf, %ld\n, temperature);
-}
-
-static ssize_t
-temp_crit_show(struct device *dev, struct device_attribute *attr,
-   char *buf)
-{
-   struct thermal_hwmon_attr *hwmon_attr
-   = container_of(attr, struct thermal_hwmon_attr, attr);
-   struct thermal_hwmon_temp *temp
-   = container_of(hwmon_attr, struct thermal_hwmon_temp,
-  temp_crit);
-   struct thermal_zone_device *tz = temp-tz;
-   long temperature;
-   int ret;
-
-   ret = tz-ops-get_trip_temp(tz, 0, temperature);
-   if (ret

[PATCH 3/9] thermal: thermal_core: allow binding with limits on bind_params

[Eduardo Valentin]

When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).

This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 Documentation/thermal/sysfs-api.txt |  7 +++
 drivers/thermal/thermal_core.c  | 19 +++
 include/linux/thermal.h | 10 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..2ad50e7 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -134,6 +134,13 @@ temperature) and throttle appropriate devices.
this thermal zone and cdev, for a particular trip point.
If nth bit is set, then the cdev and thermal zone are bound
for trip point n.
+.limits: This is an array of cooling state limits. Must have exactly
+ 2 * thermal_zone.number_of_trip_points. It is an array consisting
+ of tuples lower-state upper-state of state limits. Each trip
+ will be associated with one state limit tuple when binding.
+ A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+ on all trips. These limits are used when binding a cdev to a
+ trip point.
 .match: This call back returns success(0) if the 'tz and cdev' need to
be bound, as per platform data.
 1.4.2 struct thermal_zone_params
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 247528b..096c8be 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -202,14 +202,23 @@ static void print_bind_err_msg(struct thermal_zone_device 
*tz,
 }
 
 static void __bind(struct thermal_zone_device *tz, int mask,
-   struct thermal_cooling_device *cdev)
+   struct thermal_cooling_device *cdev,
+   unsigned long *limits)
 {
int i, ret;
 
for (i = 0; i  tz-trips; i++) {
if (mask  (1  i)) {
+   unsigned long upper, lower;
+
+   upper = THERMAL_NO_LIMIT;
+   lower = THERMAL_NO_LIMIT;
+   if (limits) {
+   lower = limits[i * 2];
+   upper = limits[i * 2 + 1];
+   }
ret = thermal_zone_bind_cooling_device(tz, i, cdev,
-   THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+  upper, lower);
if (ret)
print_bind_err_msg(tz, cdev, ret);
}
@@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (tzp-tbp[i].match(pos, cdev))
continue;
tzp-tbp[i].cdev = cdev;
-   __bind(pos, tzp-tbp[i].trip_mask, cdev);
+   __bind(pos, tzp-tbp[i].trip_mask, cdev,
+  tzp-tbp[i].binding_limits);
}
}
 
@@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
if (tzp-tbp[i].match(tz, pos))
continue;
tzp-tbp[i].cdev = pos;
-   __bind(tz, tzp-tbp[i].trip_mask, pos);
+   __bind(tz, tzp-tbp[i].trip_mask, pos,
+  tzp-tbp[i].binding_limits);
}
}
 exit:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..39575eb 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -207,6 +207,16 @@ struct thermal_bind_params {
 * See Documentation/thermal/sysfs-api.txt for more information.
 */
int trip_mask;
+
+   /*
+* This is an array of cooling state limits. Must have exactly
+* 2 * thermal_zone.number_of_trip_points. It is an array consisting
+* of tuples lower-state upper-state of state limits. Each trip
+* will be associated with one state limit tuple when binding.
+* A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+* on all trips.
+*/
+   unsigned long *binding_limits;
int (*match) (struct thermal_zone_device *tz,
struct thermal_cooling_device *cdev);
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux

[PATCH 2/8] thermal: introduce device tree parser

[Eduardo Valentin]

In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 .../devicetree/bindings/thermal/thermal.txt|  99 +
 drivers/thermal/Kconfig|  13 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/thermal_dt.c   | 438 +
 include/dt-bindings/thermal/thermal.h  |  27 ++
 include/linux/thermal.h|   3 +
 6 files changed, 581 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/thermal_dt.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..03751bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,99 @@
+
+Thermal Framework Device Tree descriptor
+
+
+This file describes how to define a thermal structure using device tree.
+A thermal structure includes thermal zones and their components, such
+as name, governor, trip points, polling intervals and cooling devices
+binding descriptors. A binding descriptor may contain information on
+how to react, with a cooling stepped action or a weight on a fair share.
+
+
+trip
+
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+A node describing a trip must contain:
+- temperature: the trip temperature level, in milliCelsius.
+- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
+value, in milliCelsius.
+- type: the trip type. Here is the type mapping:
+   THERMAL_TRIP_ACTIVE
+   THERMAL_TRIP_PASSIVE
+   THERMAL_TRIP_HOT
+   THERMAL_TRIP_CRITICAL
+
+**
+bind_param
+**
+
+The bind_param node is a node to describe how cooling devices get assigned
+to trip points of the zone. The cooling devices are expected to be loaded
+in the target system.
+
+A node describing a bind_param must contain:
+- cooling_device: A string with the cooling device name.
+- weight: The 'influence' of a particular cooling device on this zone.
+ This is on a percentage scale. The sum of all these weights
+ (for a particular zone) cannot exceed 100.
+- trip_mask: This is a bit mask that gives the binding relation between
+   this thermal zone and cdev, for a particular trip point.
+   If nth bit is set, then the cdev and thermal zone are bound
+   for trip point n.
+- limits: An array integers consisting of 2-tuples items, and each item means
+  lower and upper state limits, like min-state max-state.
+
+
+thermal_zone
+
+
+The thermal_zone node is the node containing all the required info
+for describing a thermal zone, including its cdev bindings. The thermal_zone
+node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone bind parameters.
+
+Required properties:
+- type: this is a string containing the zone type. Say 'cpu', 'core', 'mem', 
etc.
+- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
+
+- passive_delay: number of milliseconds to wait between polls when
+   performing passive cooling.
+- polling_delay: number of milliseconds to wait between polls when checking
+
+- governor: A string containing the default governor for this zone.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = THERMAL_TRIP_PASSIVE;
+};
+crit@125000{
+temperature = 125000; /* milliCelsius */
+hysteresis = 0; /* milliCelsius

[PATCH 7/8] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/hwmon/lm75.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..0aa5e28 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include linux/hwmon-sysfs.h
 #include linux/err.h
 #include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
 #include lm75.h
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
struct device   *hwmon_dev;
+   struct thermal_zone_device  *tz;
struct mutexupdate_lock;
u8  orig_conf;
u8  resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device 
*dev);
 
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+   struct lm75_data *data = lm75_update_device(dev);
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   *temp = ((data-temp[0]  (16 - data-resolution)) * 1000) 
+   (data-resolution - 8);
+
+   return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 char *buf)
 {
@@ -271,11 +287,23 @@ lm75_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
goto exit_remove;
}
 
+   if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
+   data-tz = thermal_zone_of_device_register(client-dev,
+  client-dev,
+  lm75_read_temp);
+   if (IS_ERR(data-tz)) {
+   status = PTR_ERR(data-tz);
+   goto exit_hwmon;
+   }
+   }
+
dev_info(client-dev, %s: sensor '%s'\n,
 dev_name(data-hwmon_dev), client-name);
 
return 0;
 
+exit_hwmon:
+   hwmon_device_unregister(data-hwmon_dev);
 exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +313,7 @@ static int lm75_remove(struct i2c_client *client)
 {
struct lm75_data *data = i2c_get_clientdata(client);
 
+   thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH V1 8/9] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

Hi Wei,


On 18-07-2013 01:33, Wei Ni wrote:
 On 07/17/2013 11:17 PM, Eduardo Valentin wrote:
 This patch adds to lm75 temperature sensor the possibility
 to expose itself as thermal zone device, registered on the
 thermal framework.

 The thermal zone is built only if a device tree node
 describing a thermal zone for this sensor is present
 inside the lm75 DT node. Otherwise, the driver behavior
 will be the same.

 Cc: Jean Delvare kh...@linux-fr.org
 Cc: Guenter Roeck li...@roeck-us.net
 Cc: lm-sens...@lm-sensors.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  drivers/hwmon/lm75.c | 29 +
  1 file changed, 29 insertions(+)

 diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
 index c03b490..0aa5e28 100644
 --- a/drivers/hwmon/lm75.c
 +++ b/drivers/hwmon/lm75.c
 @@ -27,6 +27,8 @@
  #include linux/hwmon-sysfs.h
  #include linux/err.h
  #include linux/mutex.h
 +#include linux/thermal.h
 +#include linux/of.h
  #include lm75.h
  
  
 @@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
  /* Each client has this additional data */
  struct lm75_data {
  struct device   *hwmon_dev;
 +struct thermal_zone_device  *tz;
  struct mutexupdate_lock;
  u8  orig_conf;
  u8  resolution; /* In bits, between 9 and 12 */
 @@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device 
 *dev);
  
  /* sysfs attributes for hwmon */
  
 +static int lm75_read_temp(void *dev, unsigned long *temp)
 +{
 +struct lm75_data *data = lm75_update_device(dev);
 +
 +if (IS_ERR(data))
 +return PTR_ERR(data);
 +
 +*temp = ((data-temp[0]  (16 - data-resolution)) * 1000) 
 +(data-resolution - 8);
 +
 +return 0;
 +}
 +
  static ssize_t show_temp(struct device *dev, struct device_attribute *da,
   char *buf)
  {
 @@ -271,11 +287,23 @@ lm75_probe(struct i2c_client *client, const struct 
 i2c_device_id *id)
  goto exit_remove;
  }
  
 +if (of_find_node_by_name(client-dev.of_node, thermal_zone)) {
 +data-tz = thermal_zone_of_device_register(client-dev,
 +   client-dev,
 +   lm75_read_temp);
 
 Hi, Eduardo
 I have two questions:
 1. As we know, after register to the thermal framework, it will have
 duplicate hwmon devices. I think lm-sensor maintainer would not like this.

Yes I noticed. You have always the option to disable the
CONFIG_THERMAL_HWMON in your build.

 How about to add a flag to indicate it, which I talk about with
 Durgadoss in your [RFC 1/4]patch.

This would be very much appreciated, but I don't think this is a blocker
for this series. We can of course include this patch on it. Having a
flag to control this thermal fw to hwmon interface is actually a good idea.

 
 2. I'm also trying to use your codes on lm90. The LM90 serial has more
 then one sensors in one chip, local sensor, remote sensor and may have
 remote2 sensor, so it mean there may have more than one thermal_zone
 under the lm90 device node, will you consider it?
 

I haven't looked lm90 source code. How do you map it? Do you probe each
sensor or do you probe 1 device and expose 3 sensors?

In first case, you can still reuse what is in this series.

Later case, we need to change it slightly.

That is the case which is pretty similar on OMAP5 for instance, where
the device has three sensors. This patch series does not cover for this
case. But it can be simply modified to get around it.

We would need to allow more than one 'thermal_zone' nodes inside a
single device. But then we would need to have a way to determine which
sensor goes to which zone too.


 Thanks.
 Wei.
 
 +if (IS_ERR(data-tz)) {
 +status = PTR_ERR(data-tz);
 +goto exit_hwmon;
 +}
 +}
 +
  dev_info(client-dev, %s: sensor '%s'\n,
   dev_name(data-hwmon_dev), client-name);
  
  return 0;
  
 +exit_hwmon:
 +hwmon_device_unregister(data-hwmon_dev);
  exit_remove:
  sysfs_remove_group(client-dev.kobj, lm75_group);
  return status;
 @@ -285,6 +313,7 @@ static int lm75_remove(struct i2c_client *client)
  {
  struct lm75_data *data = i2c_get_clientdata(client);
  
 +thermal_zone_device_unregister(data-tz);
  hwmon_device_unregister(data-hwmon_dev);
  sysfs_remove_group(client-dev.kobj, lm75_group);
  lm75_write_value(client, LM75_REG_CONF, data-orig_conf);

 
 
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

Hello Guenter,

On 17-07-2013 18:09, Guenter Roeck wrote:
 On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin wrote:
 Hello all,

 As you noticed, I am working in a way to represent thermal data
 using device tree [1]. Essentially, this should be a way to say
 what to do with a sensor and how to associate (cooling) actions
 with it.

 Seems to me that goes way beyond the supposed scope of devicetree data.
 Devicetree data is supposed to describe hardware, not its configuration or 
 use.
 This is clearly a use case.

Thanks for rising your voice here. It is important to know what hwmon
ppl think about this.

 
 Guenter

As your answers to the series are giving same argument, I chose to
answer on patch 0. I would be happier if you could elaborate a bit more
on your concern, specially if you take hwmon cap here, and give your
view with that perspective.

I also considered that this work could be abusing of DT purposes. But
let me explain why I still think it makes sense to have it.

First thing is that this series intend to describe the thermal data
required for a specific board. That means, considering your board
layout, mechanics, power dissipation and composition of your ICs, etc,
that will impose thermal requirements on your system. That is not
configuration, but part of your board design and non-functional
requirement. To me, configuration would be something like saying you
want to use a specific keyboard layout, or defining your wifi card
channel, or display size, etc.

Here what is described and setup may get confused with configuration,
but it is not because what goes in DT in this case must be actually
derived from your HW needs. Putting a sensor  close to your battery has
a strong meaning behind. Same if you put a sensor close to your
processor. For instance, we have cases we need to consider external heat
in order to properly determine our CPU hotspot level, using a board
sensor. That is what I mean by HW requirement/need.

Again, just to refresh our minds, this is about protecting your board
and ICs from operating out of their spec and extending their lifetime.
This is not about configuring something just because user has chosen to.
That is definitely not a configuration.

Being a use case, well, these new DT nodes can still be seen as a use
case, yes. But depends on your understanding of use case. Because a
sensor device may be used on different needs, composing different use
cases. But still here we are talking about HW needs and composition. And
yes, if you take that perspective, there are use cases already described
in DT.

For instance, just because you use an LDO to power a MMC, does it mean
you always will use it to power MMC on all boards. Would that be a use
case? And in that example, because your MMC requires 2.8V, if you have a
DT property to say that, does it mean it is  configuration? Well, yes,
but that is based on HW needs, otherwise it wont operate properly. Same
thing here, leave your hw operating out of temperature specs and you
will see what is the outcome.

Similar example would be cpufreq, or OPPs for opp layer. Defining an OPP
in DT could be considered a configuration?  Well in theory yes, one can
pick what ever configuration for your (D)PLL then match with a
minimalist voltage level. And in theory, a voltage level can sustain
more than one frequency level. An OPP is still a virtual concept, and we
still describe it in DT. Why? To me is because it is a HW need, because
HW folks have actually validated that configuration of PLL (frequency)
and voltage level. Sometimes they have even optimized it (for low power
consumption for instance), as one may achieve same OPP with different
configuration. Then why thermal data, which is again, a 'HW
configuration' that has been optimized by HW folks, known to be a HW
requirement, cannot be described in DT?

Similar argument goes to the fact that one may think this is subsystem
specific. Again, describing your OPPs is not OPP layer specific?
Besides, one can still read the device tree nodes I have written for
describing thermal data and implement the HW requirement elsewhere, if
wanted (say in user land). I don't see as subsystem specific.

Keep in mind that these very same concepts are actually derived from
ACPI specification. They don't come from nowhere. And just because your
system does not have ACPI support, does not mean it won't have a need to
describe thermal?

So, because with this work (i) we are describing something that is
required for properly usage of your HW (and not choice of the user),
because (ii) same data is used on different specification (that is used
on different OSes too), because (iii) you don't need thermal fw to read
this data and you could implement the HW requirement elsewhere, because
(iv) there are other similar requirements already implemented via DT; I
still think this work is within DT scope. And that is based on evidence
of existing work not because DT is nice and I would want to use it.

Hope

Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

On 18-07-2013 17:21, Guenter Roeck wrote:
 On Thu, Jul 18, 2013 at 11:18:05AM -0600, Stephen Warren wrote:
 On 07/18/2013 07:53 AM, Eduardo Valentin wrote:
 Hello Guenter,

 On 17-07-2013 18:09, Guenter Roeck wrote:
 On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
 wrote:
 Hello all,

 As you noticed, I am working in a way to represent thermal
 data using device tree [1]. Essentially, this should be a way
 to say what to do with a sensor and how to associate (cooling)
 actions with it.

 Seems to me that goes way beyond the supposed scope of devicetree
 data. Devicetree data is supposed to describe hardware, not its
 configuration or use. This is clearly a use case.

 Thanks for rising your voice here. It is important to know what
 hwmon ppl think about this.

 I meant to find time to read Guenter's original email where he
 initially objected to putting data into DT, and determine exactly what
 was being objected to. I still haven't:-( However, the arguments that
 Eduardo stated in his email do make sense to me; I agree that
 temperature limits really are a description of HW. Details of which
 cooling methods to invoke when certain temperature limits are reached
 is also part of the HW/system design, and hence I would tend to agree
 that they're appropriate to include in DT. Anyway, that's just my 2
 cents on the matter:-)
 
 Many systems have multiple profiles for various use cases (high performance,
 low power etc), and limits are different based on the use case. If that means
 you are going to have multiple devicetree variants based on the profile,

No, definitely this patch series is *not* about mapping multiples
profiles for various use cases on device tree! This series is about
mapping *hw thermal limits* on device tree.

 I would argue that you crossed the line. With thermal profiles it gets even 
 more
 complicated, as those parameters may be played around with and changed
 multiple times to find the best settings to achieve optimal cooling.
 Does this describe hardware ? I don't think so, but, as I mentioned before,
 maybe I am wrong.


Again, this is about describing points and actions to avoid your hw
degradation. May be also useful to avoid end user harm.

This series is not about describing performance profiles.

 
 Guenter
 
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

[Eduardo Valentin]

On 18-07-2013 17:11, Guenter Roeck wrote:
 On Thu, Jul 18, 2013 at 09:53:05AM -0400, Eduardo Valentin wrote:
 Hello Guenter,

 On 17-07-2013 18:09, Guenter Roeck wrote:
 On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin wrote:
 Hello all,

 As you noticed, I am working in a way to represent thermal data
 using device tree [1]. Essentially, this should be a way to say
 what to do with a sensor and how to associate (cooling) actions
 with it.

 Seems to me that goes way beyond the supposed scope of devicetree data.
 Devicetree data is supposed to describe hardware, not its configuration or 
 use.
 This is clearly a use case.

 Thanks for rising your voice here. It is important to know what hwmon
 ppl think about this.

 Sorry, I don't know what ppl stands for.
 

 Guenter

 As your answers to the series are giving same argument, I chose to
 answer on patch 0. I would be happier if you could elaborate a bit more
 on your concern, specially if you take hwmon cap here, and give your
 view with that perspective.

 I also considered that this work could be abusing of DT purposes. But
 let me explain why I still think it makes sense to have it.

 Ultimately, you are making my point here. If you considered it, did you ask
 devicetree experts for an opinion ? Did you discuss the subject on the
 devicetree-discuss mailing list ? If so, what was the result ?

Although I have asked, I didn't get any feedback.
https://lkml.org/lkml/2013/4/11/760

But now I am requesting feedback in a formal (patch) way.

Consider this patch series as official request for (devicetree experts
and everyone involved) opinions.

 
 First thing is that this series intend to describe the thermal data
 required for a specific board. That means, considering your board
 layout, mechanics, power dissipation and composition of your ICs, etc,
 that will impose thermal requirements on your system. That is not
 configuration, but part of your board design and non-functional
 requirement. To me, configuration would be something like saying you
 want to use a specific keyboard layout, or defining your wifi card
 channel, or display size, etc.

 Here what is described and setup may get confused with configuration,
 but it is not because what goes in DT in this case must be actually
 derived from your HW needs. Putting a sensor  close to your battery has
 a strong meaning behind. Same if you put a sensor close to your
 processor. For instance, we have cases we need to consider external heat
 in order to properly determine our CPU hotspot level, using a board
 sensor. That is what I mean by HW requirement/need.

 Again, just to refresh our minds, this is about protecting your board
 and ICs from operating out of their spec and extending their lifetime.
 This is not about configuring something just because user has chosen to.
 That is definitely not a configuration.

 Being a use case, well, these new DT nodes can still be seen as a use
 case, yes. But depends on your understanding of use case. Because a
 sensor device may be used on different needs, composing different use
 cases. But still here we are talking about HW needs and composition. And
 yes, if you take that perspective, there are use cases already described
 in DT.

 For instance, just because you use an LDO to power a MMC, does it mean
 you always will use it to power MMC on all boards. Would that be a use
 case? And in that example, because your MMC requires 2.8V, if you have a
 DT property to say that, does it mean it is  configuration? Well, yes,
 but that is based on HW needs, otherwise it wont operate properly. Same
 thing here, leave your hw operating out of temperature specs and you
 will see what is the outcome.

 Similar example would be cpufreq, or OPPs for opp layer. Defining an OPP
 in DT could be considered a configuration?  Well in theory yes, one can
 pick what ever configuration for your (D)PLL then match with a
 minimalist voltage level. And in theory, a voltage level can sustain
 more than one frequency level. An OPP is still a virtual concept, and we
 still describe it in DT. Why? To me is because it is a HW need, because
 HW folks have actually validated that configuration of PLL (frequency)
 and voltage level. Sometimes they have even optimized it (for low power
 consumption for instance), as one may achieve same OPP with different
 configuration. Then why thermal data, which is again, a 'HW
 configuration' that has been optimized by HW folks, known to be a HW
 requirement, cannot be described in DT?

 Similar argument goes to the fact that one may think this is subsystem
 specific. Again, describing your OPPs is not OPP layer specific?
 Besides, one can still read the device tree nodes I have written for
 describing thermal data and implement the HW requirement elsewhere, if
 wanted (say in user land). I don't see as subsystem specific.

 Keep in mind that these very same concepts are actually derived from
 ACPI specification. They don't come from nowhere

Re: [PATCH] typo in drivers/thermal/Kconfig: lpatform instead of platform

[Eduardo Valentin]

On 08-09-2013 17:58, Regid Ichira wrote:
 Applied to the HEAD of linux.git,
VERSION = 3 PATCHLEVEL = 11 SUBLEVEL = 0
 Signed-off-by: Regid Ichira regi...@nt1.in

Acked-by: Eduardo Valentin eduardo.valen...@ti.com

 ---
  drivers/thermal/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index e988c81..3f99f79 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -47,7 +47,7 @@ config THERMAL_DEFAULT_GOV_USER_SPACE
   select THERMAL_GOV_USER_SPACE
   help
 Select this if you want to let the user space manage the
 -   lpatform thermals.
 +   platform thermals.
  
  endchoice
  
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

[PATCHv2 3/7] arm: dts: dra7: add bandgap entry

[Eduardo Valentin]

This patch adds bandgap IP entry on DRA7 dtsi device tree file.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 12 
 1 file changed, 12 insertions(+)
---
Hi all,

Difference from V1: now the BG node belongs to OCP.

Tero, this is the patch you were asking for.

Thanks,

Eduardo

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 3a746c2..d3d467b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -102,6 +102,18 @@
pinctrl-single,function-mask = 0x3fff;
};
 
+   bandgap: bandgap {
+   reg = 0x4a0021e0 0xc
+   0x4a00232c 0xc
+   0x4a002380 0x2c
+   0x4a0023C0 0x3c
+   0x4a002564 0x8
+   0x4a002574 0x50;
+   compatible = ti,dra752-bandgap;
+   interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+   #thermal-sensor-cells = 1;
+   };
+
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/7] DRA7: DT thermal support

[Eduardo Valentin]

Hello all,

This is a complementary patch series with themal DT support for DRA7.

Although this work depends on the thermal dt parser work [1], I decided
to share it before hand. It also depends on DRA7 DT base port support,
which I fetched from Rajendra's tree [2].

This patch series has been runtime tested on DRA7-evm.

All best,

[1] - https://lkml.org/lkml/2013/9/26/787
[2] - git://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v3

Eduardo Valentin (7):
  arm: dts: add dra7 DSPEVE thermal data
  arm: dts: add dra7 IVA thermal data
  arm: dts: dra7: add bandgap entry
  arm: dts: add cooling properties on dra7 cpu node
  arm: dts: dra7: add thermal data
  arm: dts: add tmp102 i2c sensor node on dra7-evm
  arm: dts: add thermal zones info on tmp102 for DRA7-EVM

 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 
 arch/arm/boot/dts/dra7-evm.dts | 23 +++
 arch/arm/boot/dts/dra7-iva-thermal.dtsi| 28 
 arch/arm/boot/dts/dra7.dtsi| 27 ++-
 4 files changed, 105 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi

-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] arm: dts: add dra7 IVA thermal data

[Eduardo Valentin]

This patch changes a dtsi file to contain the thermal data
for IVA domain on DRA7 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7-iva-thermal.dtsi | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi

diff --git a/arch/arm/boot/dts/dra7-iva-thermal.dtsi 
b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
new file mode 100644
index 000..fea0cea
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for DRA7 SoC IVA thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+iva_thermal: iva_thermal {
+   polling-delay-passive = 250; /* milliseconds */
+   polling-delay = 1000; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = bandgap 4;
+
+   trips {
+   iva_crit: iva_crit {
+   temperature = 125000; /* milliCelsius */
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_CRITICAL;
+   };
+   };
+};
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] arm: dts: add dra7 DSPEVE thermal data

[Eduardo Valentin]

This patch changes a dtsi file to contain the thermal data
for DSPEVE domain on DRA7 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi

diff --git a/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi 
b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
new file mode 100644
index 000..f8b9051
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for DRA7 SoC DSPEVE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+dspeve_thermal: dspeve_thermal {
+   polling-delay-passive = 250; /* milliseconds */
+   polling-delay = 1000; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = bandgap 3;
+
+   trips {
+   dspeve_crit: dspeve_crit {
+   temperature = 125000; /* milliCelsius */
+   hysteresis = 2000; /* milliCelsius */
+   type = THERMAL_TRIP_CRITICAL;
+   };
+   };
+};
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] arm: dts: add cooling properties on dra7 cpu node

[Eduardo Valentin]

DRA7 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 4e9b159..1104d8a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -25,8 +25,12 @@
};
 
cpus {
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = arm,cortex-a15;
+
+   /* cooling properties */
+   #cooling-cells = 2; /* min and max */
+
timer {
compatible = arm,armv7-timer;
/*
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] arm: dts: dra7: add bandgap entry

[Eduardo Valentin]

This patch adds bandgap IP entry on DRA7 dtsi device tree file.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 3a746c2..4e9b159 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -53,6 +53,18 @@
};
};
 
+   bandgap: bandgap {
+   reg = 0x4a0021e0 0xc
+   0x4a00232c 0xc
+   0x4a002380 0x2c
+   0x4a0023C0 0x3c
+   0x4a002564 0x8
+   0x4a002574 0x50;
+   compatible = ti,dra752-bandgap;
+   interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+   #thermal-sensor-cells = 1;
+   };
+
gic: interrupt-controller@48211000 {
compatible = arm,cortex-a15-gic;
interrupt-controller;
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] arm: dts: dra7: add thermal data

[Eduardo Valentin]

This patch adds thermal data for DRA7 SoCs. Cpufreq cooling
will be enabled for MPU domain whenever it crosses 100C.
GPU, CORE, DSPEVE, IVA will be exposed and system shall
shutdown when they cross 125C.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1104d8a..8ba5e1c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -57,6 +57,15 @@
};
};
 
+   thermal_zones: thermal-zones {
+   /* SoC thermal zones */
+   #include omap4-cpu-thermal.dtsi
+   #include omap5-gpu-thermal.dtsi
+   #include omap5-core-thermal.dtsi
+   #include dra7-dspeve-thermal.dtsi
+   #include dra7-iva-thermal.dtsi
+   };
+
bandgap: bandgap {
reg = 0x4a0021e0 0xc
0x4a00232c 0xc
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] arm: dts: add tmp102 i2c sensor node on dra7-evm

[Eduardo Valentin]

On dra7-evm there is an tmp102 temperature sensor on i2c bus 1.
This patch adds its device tree node.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 21fe16b..3b6c16a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -7,6 +7,8 @@
  */
 /dts-v1/;
 
+#include dt-bindings/thermal/thermal.h
+
 #include dra7.dtsi
 
 / {
@@ -93,6 +95,12 @@
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+   tmp102: tmp102@48{
+   compatible = ti,tmp102;
+   reg = 0x48;
+
+   #thermal-sensor-cells = 0;
+   };
 };
 
 i2c2 {
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/7] arm: dts: add thermal zones info on tmp102 for DRA7-EVM

[Eduardo Valentin]

Add simple thermal zone on tmp102.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 3b6c16a..70e1a12 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -90,6 +90,21 @@
};
 };
 
+thermal_zones {
+   pcb_thermal: pcb_thermal {
+   polling-delay-passive = 250; /* milliseconds */
+   polling-delay = 1000; /* milliseconds */
+   thermal-sensors = tmp102;
+   trips {
+   crit@8 {
+   temperature = 8;
+   hysteresis = 1000;
+   type = critical;
+   };
+   };
+   };
+};
+
 i2c1 {
status = okay;
pinctrl-names = default;
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] arm: dts: add dra7 IVA thermal data

[Eduardo Valentin]

On 01-10-2013 18:33, Nishanth Menon wrote:
 On 14:32-20131001, Eduardo Valentin wrote:
 minor comments follow
 This patch changes a dtsi file to contain the thermal data
 s/changes/introduces?
 for IVA domain on DRA7 and later SoCs. This data will
 enable a thermal shutdown at 125C.

 This thermal data can be reused across TI SoC devices.
 is'nt it just DRA7 that reuses this - based on dtsi name?

For now, yes, but the file is intended to be reusable. just like the
file with cpu thermal zone is reusable on omap4/5/dra devices.


 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  arch/arm/boot/dts/dra7-iva-thermal.dtsi | 28 
  1 file changed, 28 insertions(+)
  create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi

 diff --git a/arch/arm/boot/dts/dra7-iva-thermal.dtsi 
 b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
 new file mode 100644
 index 000..fea0cea
 --- /dev/null
 +++ b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
 @@ -0,0 +1,28 @@
 +/*
 + * Device Tree Source for DRA7 SoC IVA thermal
 + *
 + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
 + * Contact: Eduardo Valentin eduardo.valen...@ti.com
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +#include dt-bindings/thermal/thermal.h
 +
 +iva_thermal: iva_thermal {
 +polling-delay-passive = 250; /* milliseconds */
 +polling-delay = 1000; /* milliseconds */
 +
 +/* sensor   ID */
 ^^ double tab here?
 +thermal-sensors = bandgap 4;
 space after bandgap is good enough?

Those tabulation were intentional, to hint that 4 means sensor id.

 +
 +trips {
 +iva_crit: iva_crit {
 +temperature = 125000; /* milliCelsius */
 +hysteresis = 2000; /* milliCelsius */
 +type = THERMAL_TRIP_CRITICAL;
 +};
 +};
 +};
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/7] arm: dts: dra7: add bandgap entry

[Eduardo Valentin]

On 01-10-2013 18:46, Nishanth Menon wrote:
 On 14:32-20131001, Eduardo Valentin wrote:
 This patch adds bandgap IP entry on DRA7 dtsi device tree file.

 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  arch/arm/boot/dts/dra7.dtsi | 12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
 index 3a746c2..4e9b159 100644
 --- a/arch/arm/boot/dts/dra7.dtsi
 +++ b/arch/arm/boot/dts/dra7.dtsi
 @@ -53,6 +53,18 @@
  };
  };
  
 +bandgap: bandgap {
   would you like to follow bandgap: bandgap@4a0021e0 convention?
 Also, could you move it under ocp?
 I already commented about this previously here: 
 https://lkml.org/lkml/2013/9/27/300

yes, this can be done.

 
 +reg = 0x4a0021e0 0xc
 +0x4a00232c 0xc
 +0x4a002380 0x2c
 +0x4a0023C0 0x3c
 +0x4a002564 0x8
 +0x4a002574 0x50;
 +compatible = ti,dra752-bandgap;
 +interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
 +#thermal-sensor-cells = 1;
 +};
 +
  gic: interrupt-controller@48211000 {
  compatible = arm,cortex-a15-gic;
  interrupt-controller;


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/7] arm: dts: add dra7 DSPEVE thermal data

[Eduardo Valentin]

On 01-10-2013 18:37, Nishanth Menon wrote:
 On 14:32-20131001, Eduardo Valentin wrote:
 This patch changes a dtsi file to contain the thermal data
^^ introduces?
 for DSPEVE domain on DRA7 and later SoCs. This data will
 enable a thermal shutdown at 125C.

 This thermal data can be reused across TI SoC devices.

 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 
  1 file changed, 28 insertions(+)
  create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi

 diff --git a/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi 
 b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
 new file mode 100644
 index 000..f8b9051
 --- /dev/null
 +++ b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
 @@ -0,0 +1,28 @@
 +/*
 + * Device Tree Source for DRA7 SoC DSPEVE thermal
 + *
 + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
 + * Contact: Eduardo Valentin eduardo.valen...@ti.com
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +#include dt-bindings/thermal/thermal.h
 +
 +dspeve_thermal: dspeve_thermal {
 +polling-delay-passive = 250; /* milliseconds */
 +polling-delay = 1000; /* milliseconds */
 +
 +/* sensor   ID */
 ^^
 +thermal-sensors = bandgap 3;
 ^^ tab control a bit? ;)

check answer on IVA patch.

 +
 +trips {
 +dspeve_crit: dspeve_crit {
 +temperature = 125000; /* milliCelsius */
 +hysteresis = 2000; /* milliCelsius */
 +type = THERMAL_TRIP_CRITICAL;
 +};
 +};
 +};
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 6/7] arm: dts: add tmp102 i2c sensor node on dra7-evm

[Eduardo Valentin]

On 01-10-2013 18:51, Nishanth Menon wrote:
 On 14:32-20131001, Eduardo Valentin wrote:
 On dra7-evm there is an tmp102 temperature sensor on i2c bus 1.
 This patch adds its device tree node.

 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 8 
  1 file changed, 8 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index 21fe16b..3b6c16a 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -7,6 +7,8 @@
   */
  /dts-v1/;
  
 +#include dt-bindings/thermal/thermal.h
 +
 
 ^^ needed?

In  fact this is left over from previous local versions and can be
removed from this patch.

However, depending on how patch 7 evolves, it could be needed, yes.

 
  #include dra7.dtsi
  
  / {
 @@ -93,6 +95,12 @@
  pinctrl-names = default;
  pinctrl-0 = i2c1_pins;
  clock-frequency = 40;
 could you add an EOL here?
 +tmp102: tmp102@48{
   a space before the {?

ok for both cosmetic comments.

 +compatible = ti,tmp102;
 +reg = 0x48;
 +
 +#thermal-sensor-cells = 0;
 +};
  };
  
  i2c2 {
 -- 
 1.8.2.1.342.gfa7285d

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


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/7] DRA7: DT thermal support

[Eduardo Valentin]

On 01-10-2013 18:58, Nishanth Menon wrote:
 On 14:32-20131001, Eduardo Valentin wrote:
 Hello all,

 This is a complementary patch series with themal DT support for DRA7.

 Although this work depends on the thermal dt parser work [1], I decided
 to share it before hand. It also depends on DRA7 DT base port support,
 which I fetched from Rajendra's tree [2].

 This patch series has been runtime tested on DRA7-evm.

 All best,

 [1] - https://lkml.org/lkml/2013/9/26/787
 [2] - git://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v3

 Eduardo Valentin (7):
   arm: dts: add dra7 DSPEVE thermal data
   arm: dts: add dra7 IVA thermal data
   arm: dts: dra7: add bandgap entry
   arm: dts: add cooling properties on dra7 cpu node
   arm: dts: dra7: add thermal data
   arm: dts: add tmp102 i2c sensor node on dra7-evm
   arm: dts: add thermal zones info on tmp102 for DRA7-EVM

  arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 28 
  arch/arm/boot/dts/dra7-evm.dts | 23 +++
  arch/arm/boot/dts/dra7-iva-thermal.dtsi| 28 
  arch/arm/boot/dts/dra7.dtsi| 27 ++-
  4 files changed, 105 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
  create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi
 
 +Benoit, Tony, Linux-omap.
 Ref: http://marc.info/?l=linux-pmm=138065243027014w=2
 
 Tony, Benoit,
 The following diff[1] is probably needed to ensure that right audience
 is addressed.

Well, yeah. thinking of this series now I probably should have mentioned
clear that it is not ready for merge. Not only because it depends on a
working in progress I have referred at [1], but because we lack
completely dra7 files (at linus tree we have no files under
arch/arm/boot/dts/*dra7*).  Therefore, I mentioned in this cover letter
that I actually based this work on top of [2] and [1]. Apologies if it
was not clear enough for you.

Just to make clear, the intention of this patch set was to share and use
yet another example of the usage of the work at [1]. Thus the audience
was directed to the cc and to lists I used.

 
 Eduardo,
 could you send an updated series with Tony,
 Benoit and linux-omap in the loop?

Well sure, once it has the right dependency in place.

 
 [1]
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 284969f..3442671 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -5969,6 +5969,7 @@ M:  Tony Lindgren t...@atomide.com
  L:   linux-o...@vger.kernel.org
  L:   devicet...@vger.kernel.org
  S:   Maintained
 +F:   arch/arm/boot/dts/*dra7*

I believe, once we have them merged, then I suppose this diff is applicable.

  F:   arch/arm/boot/dts/*omap*
  F:   arch/arm/boot/dts/*am3*
  
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/6] thermal: exynos: fix: Return from exynos_report_trigger() when therm_dev is NULL

[Eduardo Valentin]

On 24-09-2013 04:08, Lukasz Majewski wrote:
 The commit 4de0bdaa9677d11406c9becb70c60887c957e1f0
 (thermal: exynos: Add support for instance based register/unregister)
 broke check for presence of therm_dev at global thermal zone in
 exynos_report_trigger().
 
 The resulting wrong test prevents thermal_zone_device_update() call, which
 calls handlers for situation when trip points are passed.
 Such behavior prevents thermal driver from proper reaction (when TMU interrupt
 is raised) in a situation when overheating is detected at TMU hardware.
 This patch fixes it.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 ---
  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 f10a6ad..55a912a 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -310,7 +310,7 @@ void exynos_report_trigger(struct thermal_sensor_conf 
 *conf)
   }
  
   th_zone = conf-pzone_data;
 - if (th_zone-therm_dev)
 + if (!th_zone-therm_dev)

Fine with this fix, as it really looks obvious. But after reading the
code a bit, I am considering if we can remove the above check at all.

Reading the driver code piece at drivers/thermal/samsung/exynos_tmu.c,
by checking how exynos_register_thermal gets called, and how error is
handled, I assume we do not need to check for th_zone-therm_dev.

To me looks like the driver only allows th_zone's exist only with valid
therm_dev, isn't it? Except for the probe sequence, maybe, at run time
there is a time window that we have valid th_zone with invalid
therm_dev. However, reading the probe, still, the irq gets initialized
only in very end, so the work queue don't get queue till then at least.

So, my question before acking is, shall we remove this check altogether?


   return;
  
   if (th_zone-bind == false) {
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/6] thermal: exynos: Provide separate TMU data for Exynos4412

[Eduardo Valentin]

,
+   },

is a much more common style.


   },
   .tmu_count = 1,
  };
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
 b/drivers/thermal/samsung/exynos_tmu_data.h
 index dc7feb5..b130b1e 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.h
 +++ b/drivers/thermal/samsung/exynos_tmu_data.h
 @@ -138,7 +138,14 @@ extern struct exynos_tmu_init_data const 
 exynos4210_default_tmu_data;
  #define EXYNOS4210_TMU_DRV_DATA (NULL)
  #endif
  
 -#if (defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412))
 +#if defined(CONFIG_SOC_EXYNOS4412)
 +extern struct exynos_tmu_init_data const exynos4412_default_tmu_data;
 +#define EXYNOS4412_TMU_DRV_DATA (exynos4412_default_tmu_data)
 +#else
 +#define EXYNOS4412_TMU_DRV_DATA (NULL)
 +#endif
 +
 +#if defined(CONFIG_SOC_EXYNOS5250)
  extern struct exynos_tmu_init_data const exynos5250_default_tmu_data;
  #define EXYNOS5250_TMU_DRV_DATA (exynos5250_default_tmu_data)
  #else
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/6] thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412

[Eduardo Valentin]

On 24-09-2013 04:08, Lukasz Majewski wrote:
 The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 (thermal: exynos: Add
 missing definations and code cleanup) has removed setting of test MUX address
 value at TMU configuration setting.
 
 This field is not present on Exynos4210 and Exynos5 SoCs. However on 
 Exynos4412
 SoC it is required to set this field after reset because without it TMU shows
 maximal available temperature, which causes immediate platform shutdown.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c  |3 +++
  drivers/thermal/samsung/exynos_tmu_data.h |4 
  2 files changed, 7 insertions(+)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index a858cc4..21b89e4 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -317,6 +317,9 @@ static void exynos_tmu_control(struct platform_device 
 *pdev, bool on)
  
   con = readl(data-base + reg-tmu_ctrl);
  
 + if (pdata-type == SOC_ARCH_EXYNOS4412)
 + con |= (EXYNOS4412_MUX_ADDR_VALUE  EXYNOS4412_MUX_ADDR_SHIFT);

Amit has introduced a way to describe features instead of checking
features per type. It would be interesting to have a reasoning why not
to use it. Think what if new Exynos TMU versions come, are you guys
going to steadily increase the above check for type?

 +
   if (pdata-reference_voltage) {
   con = ~(reg-buf_vref_sel_mask  reg-buf_vref_sel_shift);
   con |= pdata-reference_voltage  reg-buf_vref_sel_shift;
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
 b/drivers/thermal/samsung/exynos_tmu_data.h
 index b130b1e..a1ea19d 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.h
 +++ b/drivers/thermal/samsung/exynos_tmu_data.h
 @@ -95,6 +95,10 @@
  
  #define EXYNOS_MAX_TRIGGER_PER_REG   4
  
 +/* Exynos4412 specific */
 +#define EXYNOS4412_MUX_ADDR_VALUE  6
 +#define EXYNOS4412_MUX_ADDR_SHIFT  20
 +
  /*exynos5440 specific registers*/
  #define EXYNOS5440_TMU_S0_7_TRIM 0x000
  #define EXYNOS5440_TMU_S0_7_CTRL 0x020
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

[Eduardo Valentin]

On 24-09-2013 04:08, Lukasz Majewski wrote:
 The TMU data definition is now separated to Exynos4412 and Exynos5250.
 
 Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
 SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.
 

How about merging this one with patch 02?

 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c  |4 ++--
  drivers/thermal/samsung/exynos_tmu.h  |2 +-
  drivers/thermal/samsung/exynos_tmu_data.c |2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 21b89e4..037cd46 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   if (ret)
   return ret;
  
 - if (pdata-type == SOC_ARCH_EXYNOS ||
 - pdata-type == SOC_ARCH_EXYNOS4210 ||
 + if (pdata-type == SOC_ARCH_EXYNOS4210 ||
   pdata-type == SOC_ARCH_EXYNOS4412 ||
 + pdata-type == SOC_ARCH_EXYNOS5250 ||
   pdata-type == SOC_ARCH_EXYNOS5440)
   data-soc = pdata-type;
   else {
 diff --git a/drivers/thermal/samsung/exynos_tmu.h 
 b/drivers/thermal/samsung/exynos_tmu.h
 index db37df0..b42ece4 100644
 --- a/drivers/thermal/samsung/exynos_tmu.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -42,7 +42,7 @@ enum calibration_mode {
  enum soc_type {
   SOC_ARCH_EXYNOS4210 = 1,
   SOC_ARCH_EXYNOS4412,
 - SOC_ARCH_EXYNOS,
 + SOC_ARCH_EXYNOS5250,
   SOC_ARCH_EXYNOS5440,
  };
  
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index bd08093..188223f 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -183,7 +183,7 @@ struct exynos_tmu_init_data const 
 exynos4412_default_tmu_data = {
  struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
   .tmu_data = {
   { EXYNOS4412_TMU_DATA,
 - .type = SOC_ARCH_EXYNOS,
 + .type = SOC_ARCH_EXYNOS5250,
   },
   },
   .tmu_count = 1,
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

[Eduardo Valentin]

On 04-10-2013 06:47, Bartlomiej Zolnierkiewicz wrote:
 On Friday, October 04, 2013 12:23:30 PM Lukasz Majewski wrote:
 Hi Eduardo,

 On 24-09-2013 04:08, Lukasz Majewski wrote:
 The TMU data definition is now separated to Exynos4412 and
 Exynos5250.

 Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
 SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.


 How about merging this one with patch 02?

 I wanted to show how the work was logically split - patch 02
 extracts Exynos4412 from Exynos5250. Then this patch changes the name.

 I will merge those two patches. No problem.
 
 Oh, well. Looking at the patch #2 again the merge can be done without
 sacrificing backportability.

Please, merge them and describe that you are reworking the type and the
enum definition. Also add your reasonings, specially if you found bugs.
The way the descriptions are being presented, the bugs you found do not
get properly explained.

 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 

 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c  |4 ++--
  drivers/thermal/samsung/exynos_tmu.h  |2 +-
  drivers/thermal/samsung/exynos_tmu_data.c |2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_tmu.c
 b/drivers/thermal/samsung/exynos_tmu.c index 21b89e4..037cd46 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct
 platform_device *pdev) if (ret)
return ret;
  
 -  if (pdata-type == SOC_ARCH_EXYNOS ||
 -  pdata-type == SOC_ARCH_EXYNOS4210 ||
 +  if (pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
 +  pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5440)
data-soc = pdata-type;
else {
 diff --git a/drivers/thermal/samsung/exynos_tmu.h
 b/drivers/thermal/samsung/exynos_tmu.h index db37df0..b42ece4 100644
 --- a/drivers/thermal/samsung/exynos_tmu.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -42,7 +42,7 @@ enum calibration_mode {
  enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
SOC_ARCH_EXYNOS4412,
 -  SOC_ARCH_EXYNOS,
 +  SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5440,
  };
  
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
 b/drivers/thermal/samsung/exynos_tmu_data.c index bd08093..188223f
 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -183,7 +183,7 @@ struct exynos_tmu_init_data const
 exynos4412_default_tmu_data = { struct exynos_tmu_init_data const
 exynos5250_default_tmu_data = { .tmu_data = {
{ EXYNOS4412_TMU_DATA,
 -  .type = SOC_ARCH_EXYNOS,
 +  .type = SOC_ARCH_EXYNOS5250,
},
},
.tmu_count = 1,
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] thermal: TI: remove TI_THERMAL dependency on CPU_THERMAL

[Eduardo Valentin]

On 04-10-2013 08:39, Bartlomiej Zolnierkiewicz wrote:
 Cover cpufreq_get_current_driver() call in ti-thermal-common.c with
 CPU_FREQ ifdefs and remove no longer needed CPU_THERMAL dependency
 from TI_THERMAL config option (stubs for other cpufreq functions for
 CPU_THERMAL=n case are already available).
 
 Please note that this enables TI_THERMAL config option in the final
 config derived from omap2plus_defconfig (which enables CPU_THERMAL
 config option but without CPU_FREQ one so TI_THERMAL config option
 was not enabled previously in the final config).
 
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/thermal/ti-soc-thermal/Kconfig | 1 -
  drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 ++
  2 files changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
 b/drivers/thermal/ti-soc-thermal/Kconfig
 index bd4c7be..bf5d6e4 100644
 --- a/drivers/thermal/ti-soc-thermal/Kconfig
 +++ b/drivers/thermal/ti-soc-thermal/Kconfig
 @@ -13,7 +13,6 @@ config TI_SOC_THERMAL
  config TI_THERMAL
   bool Texas Instruments SoCs thermal framework support
   depends on TI_SOC_THERMAL
 - depends on CPU_THERMAL

Until the code that uses cpu thermal is still present in the driver, I
would prefer to have this dependency, for runtime proper behavior. The
driver design is still to take the responsibility to load the cpufreq
cooling device. Up to now they are still dependent.

   help
 If you say yes here you want to get support for generic thermal
 framework for the Texas Instruments on die bandgap temperature sensor.
 diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
 b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
 index 4f8b9af..94d91af 100644
 --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
 +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
 @@ -357,10 +357,12 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap 
 *bgp, int id)
   if (!data)
   return -EINVAL;
  
 +#ifdef CONFIG_CPU_FREQ
   if (!cpufreq_get_current_driver()) {
   dev_dbg(bgp-dev, no cpufreq driver yet\n);
   return -EPROBE_DEFER;
   }
 +#endif

I would prefer not to have this ifdef here.

  
   /* Register cooling device */
   data-cool_dev = cpufreq_cooling_register(cpu_present_mask);
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] thermal: offer TI thermal support only when ARCH_OMAP2PLUS is defined

[Eduardo Valentin]

On 04-10-2013 08:35, Bartlomiej Zolnierkiewicz wrote:
 Menu for Texas Instruments thermal support is visible on all
 platforms and TI_SOC_THERMAL + TI_THERMAL config options can
 be selected also on EXYNOS platform (on which ARCH_HAS_BANDGAP
 config option is selected by SoCs config options to fulfill
 EXYNOS_THERMAL config option dependency). Thus the code which
 is never used can be build. Fix it by making TI menu dependent
 on ARCH_OMAP2PLUS config option.
 
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/thermal/Kconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index 57e06a9..a709c63 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -193,6 +193,7 @@ config X86_PKG_TEMP_THERMAL
 notification methods.
  
  menu Texas Instruments thermal drivers
 +depends on ARCH_OMAP2PLUS

No, this driver is not for ARCH_OMAP*, but for TI bandgap, with the
option to offer thermal control. So, the HW supported is TI bandgap IP,
not ARCH_OMAP*. It happens to be so that OMAP2PLUS all have a
(different) version of this device.

However, DRA7 devices, for instance, also feature the bandgap IP
(different version of those present in OMAP devices), and it is not
ARCH_OMAP2PLUS.

And because of that, the design of this driver is different. It is not
expected to depend on an arch, but the arch code is expected to select
ARCH_HAS_BANDGAP.

  source drivers/thermal/ti-soc-thermal/Kconfig
  endmenu
  
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] thermal: TI: always register sensor driver with core thermal framework

[Eduardo Valentin]

On 04-10-2013 08:40, Bartlomiej Zolnierkiewicz wrote:
 There is little sense in having separate config option for
 registering the sensor driver with the core thermal framework.
 Fix it by integrating TI_THERMAL config option with TI_SOC_THERMAL
 one.

I am a bit confused of what is exactly wrong or needs fixing. The code
organization is so that the file ti-bandgap.c adds the support for TI
Bandgap IP. It is not aware of thermal framework. And the
ti-thermal-common.c file is expected to talk to thermal framework. Can
you please elaborate a bit more why this split is hurting you?

 
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/thermal/ti-soc-thermal/Kconfig  | 15 +++---
  drivers/thermal/ti-soc-thermal/Makefile |  2 +-
  drivers/thermal/ti-soc-thermal/ti-thermal.h | 31 
 -
  3 files changed, 4 insertions(+), 44 deletions(-)
 
 diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
 b/drivers/thermal/ti-soc-thermal/Kconfig
 index bf5d6e4..c64e78b 100644
 --- a/drivers/thermal/ti-soc-thermal/Kconfig
 +++ b/drivers/thermal/ti-soc-thermal/Kconfig
 @@ -7,18 +7,9 @@ config TI_SOC_THERMAL
 OMAP4460+ on die bandgap temperature sensor support. The register
 set is part of system control module.
  
 -   This includes alert interrupts generation and also the TSHUT
 -   support.
 -
 -config TI_THERMAL
 - bool Texas Instruments SoCs thermal framework support
 - depends on TI_SOC_THERMAL
 - help
 -   If you say yes here you want to get support for generic thermal
 -   framework for the Texas Instruments on die bandgap temperature sensor.
 -
 -   This includes trip points definitions, extrapolation rules and
 -   CPU cooling device bindings.
 +   This includes alert interrupts generation, the TSHUT support,
 +   trip points definitions, extrapolation rules and CPU cooling
 +   device bindings.
  
  config OMAP4_THERMAL
   bool Texas Instruments OMAP4 thermal support
 diff --git a/drivers/thermal/ti-soc-thermal/Makefile 
 b/drivers/thermal/ti-soc-thermal/Makefile
 index 1226b24..c75cc91 100644
 --- a/drivers/thermal/ti-soc-thermal/Makefile
 +++ b/drivers/thermal/ti-soc-thermal/Makefile
 @@ -1,6 +1,6 @@
  obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal.o
  ti-soc-thermal-y := ti-bandgap.o
 -ti-soc-thermal-$(CONFIG_TI_THERMAL)  += ti-thermal-common.o
 +ti-soc-thermal-y += ti-thermal-common.o
  ti-soc-thermal-$(CONFIG_DRA752_THERMAL)  += dra752-thermal-data.o
  ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)   += omap4-thermal-data.o
  ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)   += omap5-thermal-data.o
 diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal.h 
 b/drivers/thermal/ti-soc-thermal/ti-thermal.h
 index f8b7ffe..5fb427c 100644
 --- a/drivers/thermal/ti-soc-thermal/ti-thermal.h
 +++ b/drivers/thermal/ti-soc-thermal/ti-thermal.h
 @@ -83,41 +83,10 @@
  #define ti_thermal_is_valid_trip(trip)   \
   ((trip) = 0  (trip)  OMAP_TRIP_NUMBER)
  
 -#ifdef CONFIG_TI_THERMAL
  int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id, char *domain);
  int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id);
  int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id);
  int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id);
  int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id);
 -#else
 -static inline
 -int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id, char *domain)
 -{
 - return 0;
 -}
  
 -static inline
 -int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
 -{
 - return 0;
 -}
 -
 -static inline
 -int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id)
 -{
 - return 0;
 -}
 -
 -static inline
 -int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
 -{
 - return 0;
 -}
 -
 -static inline
 -int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id)
 -{
 - return 0;
 -}
 -#endif
  #endif
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] thermal: offer TI thermal support only when ARCH_OMAP2PLUS is defined

[Eduardo Valentin]

On 04-10-2013 14:22, Eduardo Valentin wrote:
 On 04-10-2013 08:35, Bartlomiej Zolnierkiewicz wrote:
 Menu for Texas Instruments thermal support is visible on all
 platforms and TI_SOC_THERMAL + TI_THERMAL config options can
 be selected also on EXYNOS platform (on which ARCH_HAS_BANDGAP
 config option is selected by SoCs config options to fulfill
 EXYNOS_THERMAL config option dependency). Thus the code which
 is never used can be build. Fix it by making TI menu dependent
 on ARCH_OMAP2PLUS config option.



Besides, you can always disable the driver if you are not interested in
compiling it.

 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/thermal/Kconfig | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index 57e06a9..a709c63 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -193,6 +193,7 @@ config X86_PKG_TEMP_THERMAL
notification methods.
  
  menu Texas Instruments thermal drivers
 +depends on ARCH_OMAP2PLUS
 
 No, this driver is not for ARCH_OMAP*, but for TI bandgap, with the
 option to offer thermal control. So, the HW supported is TI bandgap IP,
 not ARCH_OMAP*. It happens to be so that OMAP2PLUS all have a
 (different) version of this device.
 
 However, DRA7 devices, for instance, also feature the bandgap IP
 (different version of those present in OMAP devices), and it is not
 ARCH_OMAP2PLUS.
 
 And because of that, the design of this driver is different. It is not
 expected to depend on an arch, but the arch code is expected to select
 ARCH_HAS_BANDGAP.
 
  source drivers/thermal/ti-soc-thermal/Kconfig
  endmenu
  

 
 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

[PATCH] drivers: thermal: allow ti-soc-thermal run without pcb zone

[Eduardo Valentin]

This patch changes the behavior of TI SoC thermal driver
when there is a PCB thermal zone.

Instead of reporting an error code when reading from
PCB temperature sensor fails, this patch will make
the driver attempt to compose the hotspot extrapolation
based on bandgap readings only.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index f588b32..e5b1cde 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -111,6 +111,7 @@ static inline int __ti_thermal_get_temp(void *devdata, long 
*temp)
} else {
dev_err(bgp-dev,
Failed to read PCB state. Using defaults\n);
+   ret = 0;
}
}
*temp = ti_thermal_hotspot_temperature(tmp, slope, constant);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/16] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties

[Eduardo Valentin]

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.

In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |  7 +++
 drivers/cpufreq/Kconfig  |  2 +-
 drivers/cpufreq/cpufreq-cpu0.c   | 16 
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..f055515 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+ Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
 
 Examples:
 
@@ -33,6 +37,9 @@ cpus {
198000  85
;
clock-latency = 61036; /* two CLK32 periods */
+   #cooling-cells = 2;
+   cooling-min-level = 0;
+   cooling-max-level = 2;
};
 
cpu@1 {
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 534fcb8..92e6921 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 config GENERIC_CPUFREQ_CPU0
tristate Generic CPU0 cpufreq driver
-   depends on HAVE_CLK  REGULATOR  PM_OPP  OF
+   depends on HAVE_CLK  REGULATOR  PM_OPP  OF  CPU_THERMAL
select CPU_FREQ_TABLE
help
  This adds a generic cpufreq driver for CPU0 frequency management.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index cbfffa9..c573e95 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,7 +12,9 @@
 #define pr_fmt(fmt)KBUILD_MODNAME :  fmt
 
 #include linux/clk.h
+#include linux/cpu_cooling.h
 #include linux/cpufreq.h
+#include linux/cpumask.h
 #include linux/err.h
 #include linux/module.h
 #include linux/of.h
@@ -20,6 +22,7 @@
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
 #include linux/slab.h
+#include linux/thermal.h
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -255,6 +259,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
 
+   /*
+* For now, just loading the cooling device;
+* thermal DT code takes care of matching them.
+*/
+   if (of_find_property(np, #cooling-cells, NULL)) {
+   cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+   if (IS_ERR(cdev))
+   pr_err(running cpufreq without cooling device: %ld\n,
+  PTR_ERR(cdev));
+   }
+
of_node_put(np);
return 0;
 
@@ -267,6 +282,7 @@ out_put_node:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+   cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/16] device thermal limits represented in device tree nodes (v3)

[Eduardo Valentin]

Hello all,

Here is the continuation of work of representing hardware thermal properties
in device tree infrastructure. The present patch series is the third version
of this work. Previous versions were sent as RFCs and can be found here:
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

The major change between RFCv2 and this version is the fact that I am now
designing the binding accordingly to the common practice of creating links
from consumers to producers, as seen in regulators for instance. The change
make a thermal zone node point to used cooling devices and used sensor devices.
As direct need, cooling devices then need to be properly represented.
I am proposing to have cooling properties inside existing nodes, e.g. fan nodes,
cpu nodes. The change also required me to modify the existing thermal core
code to allow decoupling thermal zones from sensor code. Currently, the
binding proposal covers for the situation in which one thermal zone has
several sensor devices. Although this situation is not covered by the
current thermal framework code, and thus not supported by this series.
I believe this is not a stopper for this series, it can be done
in later patch sets.

The second patch includes a detailed documentation with examples
and the proposed code. In this patch series, a part from the dt parser,
there are changes in the cpufreq code to load the cpu cooling device,
also changes in the following sensor drivers: tmp102, lm75 and ti-soc-thermal.
Several changes in TI's SoC DT bindings are also included, as source
of tested examples.

The present patch series was tested on OMAP4430, OMAP4460, OMAP5430 and DRA7,
although the DRA7 changes were not sent as the core device tree support is
currently in the process to find its way to upstream.

All best,

Eduardo Valentin (16):
  drivers: thermal: allow registering without .get_temp
  drivers: thermal: introduce device tree parser
  drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register
  cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
properties
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4 CPU thermal data
  arm: dts: add omap4430 thermal data
  arm: dts: add omap4460 thermal data
  arm: dts: add cooling properties on omap4430 cpu node
  arm: dts: add cooling properties on omap4460 cpu node
  arm: dts: add omap5 GPU thermal data
  arm: dts: add omap5 CORE thermal data
  arm: dts: add omap5 thermal data
  arm: dts: add cooling properties on omap5 cpu node

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
 .../devicetree/bindings/thermal/thermal.txt| 498 ++
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi   |  41 ++
 arch/arm/boot/dts/omap443x.dtsi|  15 +-
 arch/arm/boot/dts/omap4460.dtsi|  15 +-
 arch/arm/boot/dts/omap5-core-thermal.dtsi  |  28 +
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi   |  28 +
 arch/arm/boot/dts/omap5.dtsi   |  15 +-
 drivers/cpufreq/Kconfig|   2 +-
 drivers/cpufreq/cpufreq-cpu0.c |  16 +
 drivers/hwmon/lm75.c   |  46 +-
 drivers/hwmon/tmp102.c |  28 +
 drivers/thermal/Kconfig|  14 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/cpu_cooling.c  |  31 +
 drivers/thermal/of-thermal.c   | 763 +
 drivers/thermal/thermal_core.c |  19 +-
 drivers/thermal/thermal_core.h |   9 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 ++-
 include/dt-bindings/thermal/thermal.h  |  27 +
 include/linux/cpu_cooling.h|  25 +
 include/linux/thermal.h|  28 +-
 22 files changed, 1701 insertions(+), 32 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/16] drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register

[Eduardo Valentin]

This patch introduces an API to register cpufreq cooling device
based on device tree node.

The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.

Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/thermal/Kconfig   |  1 +
 drivers/thermal/cpu_cooling.c | 31 +++
 include/linux/cpu_cooling.h   | 25 +
 3 files changed, 57 insertions(+)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dd81eb8..9e7cc3f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -91,6 +91,7 @@ config THERMAL_GOV_USER_SPACE
 config CPU_THERMAL
bool generic cpu cooling support
depends on CPU_FREQ
+   depends on THERMAL_OF
select CPU_FREQ_TABLE
help
  This implements the generic cpu cooling mechanism through frequency
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index d179028..cd2f532 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -491,6 +491,37 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
 
 /**
+ * of_cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @np: a valid struct device_node to the cooling device device tree node
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * thermal-cpufreq-%x. This api can support multiple instances of cpufreq
+ * cooling devices.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+   const struct cpumask *clip_cpus)
+{
+   struct thermal_cooling_device *cdev;
+
+   if (!np)
+   return ERR_PTR(-EINVAL);
+
+   cdev = cpufreq_cooling_register(clip_cpus);
+   if (IS_ERR(cdev))
+   return cdev;
+
+   cdev-np = np;
+
+   return cdev;
+}
+EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  *
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index a5d52ee..c303d38 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -24,6 +24,7 @@
 #ifndef __CPU_COOLING_H__
 #define __CPU_COOLING_H__
 
+#include linux/of.h
 #include linux/thermal.h
 #include linux/cpumask.h
 
@@ -36,6 +37,24 @@ struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus);
 
 /**
+ * of_cpufreq_cooling_register - create cpufreq cooling device based on DT.
+ * @np: a valid struct device_node to the cooling device device tree node.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen
+ */
+#ifdef CONFIG_THERMAL_OF
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+   const struct cpumask *clip_cpus);
+#else
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+   const struct cpumask *clip_cpus)
+{
+   return NULL;
+}
+#endif
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  */
@@ -48,6 +67,12 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 {
return NULL;
 }
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+   const struct cpumask *clip_cpus)
+{
+   return NULL;
+}
 static inline
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 {
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/