Re: [PATCH] thermal: exynos: use of_property_read_u8()

[Eduardo Valentin]

On Mon, Nov 23, 2015 at 07:40:41PM +0530, Saurabh Sengar wrote:
> use of_property_read_u8() for u8 variables,
> also changed the return type to void as this function return type
> is nowhere used.
> 

I would be good if you could split both changes into two patches.

Also, I still do not understand properly the proposal to use u8.

Why are they u8?

If they are so, please document them in their DT bindings. Today, the
bindings tell us they are s32 (as there is nothing really specifying the
type).


BR


> Signed-off-by: Saurabh Sengar 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 30 +-
>  1 file changed, 13 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index fa61eff..b692c95 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1128,20 +1128,16 @@ static int exynos_of_get_soc_type(struct device_node 
> *np)
>   return -EINVAL;
>  }
>  
> -static int exynos_of_sensor_conf(struct device_node *np,
> +static void exynos_of_sensor_conf(struct device_node *np,
>struct exynos_tmu_platform_data *pdata)
>  {
> - u32 value;
> - int ret;
> -
>   of_node_get(np);
>  
> - ret = of_property_read_u32(np, "samsung,tmu_gain", );
> - pdata->gain = (u8)value;
> - of_property_read_u32(np, "samsung,tmu_reference_voltage", );
> - pdata->reference_voltage = (u8)value;
> - of_property_read_u32(np, "samsung,tmu_noise_cancel_mode", );
> - pdata->noise_cancel_mode = (u8)value;
> + of_property_read_u8(np, "samsung,tmu_gain", >gain);
> + of_property_read_u8(np, "samsung,tmu_reference_voltage",
> + >reference_voltage);
> + of_property_read_u8(np, "samsung,tmu_noise_cancel_mode",
> + >noise_cancel_mode);
>  
>   of_property_read_u32(np, "samsung,tmu_efuse_value",
>>efuse_value);
> @@ -1150,18 +1146,18 @@ static int exynos_of_sensor_conf(struct device_node 
> *np,
>   of_property_read_u32(np, "samsung,tmu_max_efuse_value",
>>max_efuse_value);
>  
> - of_property_read_u32(np, "samsung,tmu_first_point_trim", );
> - pdata->first_point_trim = (u8)value;
> - of_property_read_u32(np, "samsung,tmu_second_point_trim", );
> - pdata->second_point_trim = (u8)value;
> - of_property_read_u32(np, "samsung,tmu_default_temp_offset", );
> - pdata->default_temp_offset = (u8)value;
> + of_property_read_u8(np, "samsung,tmu_first_point_trim",
> + >first_point_trim);
> + of_property_read_u8(np, "samsung,tmu_second_point_trim",
> + >second_point_trim);
> + of_property_read_u8(np, "samsung,tmu_default_temp_offset",
> + >default_temp_offset);
>  
>   of_property_read_u32(np, "samsung,tmu_cal_type", >cal_type);
>   of_property_read_u32(np, "samsung,tmu_cal_mode", >cal_mode);
>  
>   of_node_put(np);
> - return 0;
> + return;

The landing return; is not needed.

>  }
>  
>  static int exynos_map_dt_data(struct platform_device *pdev)
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 07/10] thermal: exynos: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to exynos driver to facilitate
maintenance.

Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin <edubez...@gmail.com>
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index c2c8cba..202905e8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -345,7 +345,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
 menu "Samsung thermal drivers"
-depends on ARCH_EXYNOS
+depends on ARCH_EXYNOS || COMPILE_TEST
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
-- 
2.5.0

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

[PATCH 14/17] thermal: exynos: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to exynos driver to facilitate
maintenance.

Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin <edubez...@gmail.com>
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0fa5d20..9069cc7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -345,7 +345,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
 menu "Samsung thermal drivers"
-depends on ARCH_EXYNOS
+depends on ARCH_EXYNOS || COMPILE_TEST
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
-- 
2.5.0

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

Re: [PATCH] cpufreq: exynos: allow build for !THERMAL or !CPU_THERMAL cases

[Eduardo Valentin]

On Fri, Feb 20, 2015 at 05:20:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
 Allow driver build for !THERMAL or !CPU_THERMAL cases.
 
 The new dependency rule is the same as the one that CPUFREQ_DT
 option has (for cpufreq-dt driver which has the same issue with
 using of_cpufreq_cooling_register()).
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Eduardo Valentin edubez...@gmail.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Fixes: 8b2b4a4e5366 (cpufreq: exynos: allow modular build)
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com

Acked-by: Eduardo Valentin edubez...@gmail.com

 ---
  drivers/cpufreq/Kconfig.arm | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
 index 1b06fc4..f4df4af3 100644
 --- a/drivers/cpufreq/Kconfig.arm
 +++ b/drivers/cpufreq/Kconfig.arm
 @@ -28,7 +28,8 @@ config ARM_VEXPRESS_SPC_CPUFREQ
  config ARM_EXYNOS_CPUFREQ
   tristate SAMSUNG EXYNOS CPUfreq Driver
   depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || 
 SOC_EXYNOS5250
 - depends on THERMAL
 + # if CPU_THERMAL is on and THERMAL=m, ARM_EXYNOS_CPUFREQ cannot be =y:
 + depends on !CPU_THERMAL || THERMAL
   help
 This adds the CPUFreq driver for Samsung EXYNOS platforms.
 Supported SoC versions are:
 -- 
 1.8.2.3
 
 


signature.asc
Description: Digital signature

Re: [GIT PULL 2/2] Samsung fixes-2 for v4.0

[Eduardo Valentin]

On Fri, Mar 06, 2015 at 07:16:53PM +0900, Kukjin Kim wrote:
 Arnd Bergmann wrote:
  
 + Eduardo
 
 Hi Arnd,
 
  On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote:
   Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know
   this is quite big for fixes but I couldn't handle this series for
   previous merge window because of dependency with driver side...sorry for
   that and please pull so that we could support them in v4.0 on exynos
   platforms.
  
  What kind of dependency do you have there? It really should not be
  necessary to wait for driver changes, unless you do an incompatible
  DT binding change, which you should avoid.
  
 For TMU patches, I've asked Eduardo to provide topic branch for
 'include/dt-bindings/thermal/thermal_exynos.h' has been added via thermal tree
 because if I can't apply the patch in Samsung tree for arm-soc, kernel build
 breakage will be happened. But I couldn't get Eduardo's topic branch.


Specifically, the developer, while migrating the driver to support DT
and OF thermal, decided to create a header with constants. The header is
used by DT files and the driver code. The header was the dependency.


BR,

Eduardo Valentin

 
 http://www.spinics.net/lists/linux-samsung-soc/msg41877.html
 
 
 For HDMI patches, I thought the DT changes have a dependency with drm/exynos:
 add support for 'hdmi' clock so waited for its applying then in drm tree. But
 I couldn't send it to arm-soc after that...
 
 http://www.spinics.net/lists/linux-samsung-soc/msg42173.html
 
 
 I asked about the situation (late DT changes?) when I sent a pull-request, 
 then
 I couldn't get a access my kernel.org because of biz. trip to China :(
 
 http://www.spinics.net/lists/linux-samsung-soc/msg42235.html
 
 
  I've pulled it into fixes, but won't forward it until I hear a
  good explanation.
  
 As you know, basically I tried to make a clear branch for pull-request but in
 that case, I couldn't find a solution. Sorry for the inconvenience.
 
 I hope v4.0 can support them properly.
 
 Thanks,
 Kukjin
 


signature.asc
Description: Digital signature

Re: [PATCH v2] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used

[Eduardo Valentin]

On Thu, Feb 26, 2015 at 11:36:24AM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided possibility
  to use device tree to asses if cpu can be used as cooling device.
  Since the code was somewhat awkward, simpler approach has been
  proposed.
  
  Test HW: Exynos 4412 - Odroid U3.
  
  Suggested-by: Viresh Kumar viresh.ku...@linaro.org
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Acked-by: Viresh Kumar viresh.ku...@linaro.org
 
 This patch is also missing from linux-thermal-soc tree.
 
 I will add it to samsung thermal tree, since Viresh has ACK'ed it.

Do we have any dependency with something which is only in the thermal
tree(s)? If not, I suggest the cpufreq changes go via cpufreq tree(s).


BR,

Eduardo Valentin

 
  ---
  Changes for v2:
  - Remove superfluous *np pointer
  ---
   drivers/cpufreq/exynos-cpufreq.c | 21 ++---
   1 file changed, 6 insertions(+), 15 deletions(-)
  
  diff --git a/drivers/cpufreq/exynos-cpufreq.c
  b/drivers/cpufreq/exynos-cpufreq.c index 5e98c6b..82d2fbb 100644
  --- a/drivers/cpufreq/exynos-cpufreq.c
  +++ b/drivers/cpufreq/exynos-cpufreq.c
  @@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
   
   static int exynos_cpufreq_probe(struct platform_device *pdev)
   {
  -   struct device_node *cpus, *np;
  +   struct device_node *cpu0;
  int ret = -EINVAL;
   
  exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
  @@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct
  platform_device *pdev) if (ret)
  goto err_cpufreq_reg;
   
  -   cpus = of_find_node_by_path(/cpus);
  -   if (!cpus) {
  -   pr_err(failed to find cpus node\n);
  +   cpu0 = of_get_cpu_node(0, NULL);
  +   if (!cpu0) {
  +   pr_err(failed to find cpu0 node\n);
  return 0;
  }
   
  -   np = of_get_next_child(cpus, NULL);
  -   if (!np) {
  -   pr_err(failed to find cpus child node\n);
  -   of_node_put(cpus);
  -   return 0;
  -   }
  -
  -   if (of_find_property(np, #cooling-cells, NULL)) {
  -   cdev = of_cpufreq_cooling_register(np,
  +   if (of_find_property(cpu0, #cooling-cells, NULL)) {
  +   cdev = of_cpufreq_cooling_register(cpu0,
 cpu_present_mask);
  if (IS_ERR(cdev))
  pr_err(running cpufreq without cooling
  device: %ld\n, PTR_ERR(cdev));
  }
  -   of_node_put(np);
  -   of_node_put(cpus);
   
  return 0;
   
 
 
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH v5 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device

[Eduardo Valentin]

Hey Lukasz,

On Wed, Feb 25, 2015 at 04:34:22PM +0100, Lukasz Majewski wrote:
 The PWM FAN device can now be used as a thermal cooling device. Necessary
 infrastructure has been added in this commit.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
 - Update ctx-pwm_fan_state when correct data from device tree is available
 - Using therma_cdev_update() when thermal is ready for controlling the fan
 Changes for v3:
 - Rename patch heading
 - pwm_fan_of_get_cooling_data() now returns -EINVAL when no cooling-levels
   property defined
 - register of cooling device only when proper cooling data is present
 Changes for v4:
 - None
 Changes for v5:
 - Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
   executing thermal_* specific functions
 ---
  drivers/hwmon/pwm-fan.c | 83 
 -
  1 file changed, 82 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
 index e6ed353..2c1a8f0 100644
 --- a/drivers/hwmon/pwm-fan.c
 +++ b/drivers/hwmon/pwm-fan.c
 @@ -24,6 +24,7 @@
  #include linux/platform_device.h
  #include linux/pwm.h
  #include linux/sysfs.h
 +#include linux/thermal.h
  
  #define MAX_PWM 255
  
 @@ -68,6 +69,17 @@ exit_set_pwm_err:
   return ret;
  }
  
 +static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
 +{
 + int i;
 +
 + for (i = 0; i  ctx-pwm_fan_max_state; ++i)
 + if (pwm  ctx-pwm_fan_cooling_levels[i + 1])
 + break;
 +
 + ctx-pwm_fan_state = i;
 +}
 +
  static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t count)
  {
 @@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct 
 device_attribute *attr,
   if (ret)
   return ret;
  
 + pwm_fan_update_state(ctx, pwm);
   return count;
  }
  
 @@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
  
  ATTRIBUTE_GROUPS(pwm_fan);
  
 +/* thermal cooling device callbacks */
 +static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
 +  unsigned long *state)
 +{
 + struct pwm_fan_ctx *ctx = cdev-devdata;
 +

Why this call back is the only one you didn't add a check for ctx ==
NULL?

 + *state = ctx-pwm_fan_max_state;
 +
 + return 0;
 +}
 +
 +static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
 +  unsigned long *state)
 +{
 + struct pwm_fan_ctx *ctx = cdev-devdata;
 +
 + if (!ctx)
 + return -EINVAL;
 +
 + *state = ctx-pwm_fan_state;
 +
 + return 0;
 +}
 +
 +static int
 +pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long 
 state)
 +{
 + struct pwm_fan_ctx *ctx = cdev-devdata;
 + int ret;
 +
 + if (!ctx || (state  ctx-pwm_fan_max_state))
 + return -EINVAL;
 +
 + if (state == ctx-pwm_fan_state)
 + return 0;
 +
 + ret = __set_pwm(ctx, ctx-pwm_fan_cooling_levels[state]);
 + if (ret) {
 + dev_err(cdev-device, Cannot set pwm!\n);
 + return ret;
 + }
 +
 + ctx-pwm_fan_state = state;
 +
 + return ret;
 +}
 +
 +static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
 + .get_max_state = pwm_fan_get_max_state,
 + .get_cur_state = pwm_fan_get_cur_state,
 + .set_cur_state = pwm_fan_set_cur_state,
 +};
 +
  int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
  {
   struct device_node *np = dev-of_node;
 @@ -145,8 +211,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, 
 struct pwm_fan_ctx *ctx)
  
  static int pwm_fan_probe(struct platform_device *pdev)
  {
 - struct device *hwmon;
 + struct thermal_cooling_device *cdev;
   struct pwm_fan_ctx *ctx;
 + struct device *hwmon;
   int duty_cycle;
   int ret;
  
 @@ -193,6 +260,20 @@ static int pwm_fan_probe(struct platform_device *pdev)
   if (ret)
   return ret;
  
 + ctx-pwm_fan_state = ctx-pwm_fan_max_state;
 + if (IS_ENABLED(CONFIG_THERMAL)) {
 + cdev = thermal_of_cooling_device_register(pdev-dev.of_node,
 +   pwm-fan, ctx,
 +   pwm_fan_cooling_ops);


I know this is a PITA, but thermal subsystem still does not use devm
based helpers. That means, you need to be old school and unregister the
device yourself.

Please add the cdev to ctx structure:
+   ctx-cdev = cdev;

and add a call for:
thermal_cooling_device_unregister(ctx-cdev);

in static int pwm_fan_remove(struct platform_device *pdev)


despite the above two minor issues, you may add my
Acked-by: Eduardo Valentin edubez...@gmail.com

 + if (IS_ERR(cdev)) {
 + dev_err(pdev-dev

Re: [PATCH v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

On Wed, Feb 25, 2015 at 02:28:15PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
   With those bindings it is possible to use pwm-fan device available
   in Odroid U3 as a cooling device.
   
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
   Changes for v2:
   - Rename cooling-pwm-values property to cooling-levels
   Changes for v3:
   - Change patch's topic to ARM dts
   - Reduce maximal cooling-level to 230 from 255
   Changes for v4:
   - None
   ---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
   ++- 1 file changed, 32 insertions(+), 1
   deletion(-)
   
   diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
   b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 60bd1e4..3e5df3e
   100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
   +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
   @@ -32,11 +32,42 @@
 };
 };

   - pwm-fan {
   + fan0: pwm-fan {
 compatible = pwm-fan;
 pwms = pwm 0 1 0;
   + cooling-min-state = 0;
   + cooling-max-state = 3;
   + #cooling-cells = 2;
   + cooling-levels = 0 102 170 230;
 status = okay;
 };
   +
   + thermal-zones {
   + cpu_thermal: cpu-thermal {
  
  
  This thermal zone misses the mandatory properties as per 
   Documentation/devicetree/bindings/thermal/thermal.txt
 
 Following mandatory properties:
   thermal-sensors = tmu 0;
   polling-delay-passive = 0;
   polling-delay = 0;
   trips {
 
   }
 
 are defined in exynos4-cpu-thermal.dtsi included by this file.
 
 In this patch only device dependent changes are stated.

OK. I missed that.



 
  
   + cooling-maps {
   + map0 {
   +  trip = cpu_alert1;
   +  cooling-device = cpu0 7 7;
   + };
   + map1 {
   +  trip = cpu_alert2;
   +  cooling-device = cpu0 13
   13;
   + };
   + map2 {
   +  trip = cpu_alert0;
   +  cooling-device = fan0 0 1;
   + };
   + map3 {
   +  trip = cpu_alert1;
   +  cooling-device = fan0 1 2;
   + };
   + map4 {
   +  trip = cpu_alert2;
   +  cooling-device = fan0 2 3;
   + };
   + };
   + };
   + };
};

pwm {
   -- 
   2.0.0.rc2
   
 
 
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH v5 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan

[Eduardo Valentin]

Guenter,

On Wed, Feb 25, 2015 at 09:18:20AM -0800, Guenter Roeck wrote:
 On Wed, Feb 25, 2015 at 04:34:16PM +0100, Lukasz Majewski wrote:
  Presented patches add support for Odroid's U3 optional CPU FAN, which uses 
  PWM
  subsystem for low level control.
  
  After successful probe it registers itself as a cooling device for thermal
  subsystem.
  
  This driver also supports devices without DTS specified.
  
  To provide correct functionality, new properties to device tree description 
  for
  Exynos4412 and in particular Odroid U3 have been added.
  
  Those patches were tested at Exynos4412 - Odroid U3 board.
  
  Patches were applied on:
  linux-soc-thermal/fixes branch (Linux v4.0-rc1)
  SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a
  
  Kamil Debski (1):
ARM: dts: Add pwm-fan node to the Odroid-U3 board
  
  Lukasz Majewski (5):
Documentation: dts: Documentation entry to explain how to use PWM FAN
  as a cooling device
ARM: dts: Add properties to use pwm-fan device as a cooling device in
  Odroid U3
hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty
  cycle
hwmon: pwm-fan: Read PWM FAN configuration from device tree
hwmon: pwm-fan: Code for using PWM FAN as a cooling device
  
   .../devicetree/bindings/hwmon/pwm-fan.txt  |  25 +++-
   arch/arm/boot/dts/exynos4.dtsi |   2 +-
   arch/arm/boot/dts/exynos4412-odroidu3.dts  |  43 ++
   drivers/hwmon/pwm-fan.c| 166 
  +++--
   4 files changed, 220 insertions(+), 16 deletions(-)
  
 For the series:
 
 Acked-by: Guenter Roeck li...@roeck-us.net
 
 Should I take it through hwmon ? Might make sense given the majority
 of the changes is in hwmon code.

I believe the series should go via your tree, yes. I had only minor
comments in the code added for the cooling device code, as it lacks the
unregistration call in the .remove callback. 

Also, the DTS changes may generate conflicts with platform code. Lukasz
may probably ask  Kukjin Kim to add them via the samsung tree.

BR,

Eduardo Valentin

 
 Thanks,
 Guenter


signature.asc
Description: Digital signature

Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Eduardo Valentin]

On Wed, Feb 25, 2015 at 01:25:08PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  Hi Lukasz,
  
  On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski
  l.majew...@samsung.com wrote:
   Hi Abhilash,
  
   This patch fixes the wrong control of PD_DET_EN (power down
   detection mode) for Exynos7 because exynos7_tmu_control() always
   enables the power down detection mode regardless 'on' parameter.
  
   Cc: Zhang Rui rui.zh...@intel.com
   Cc: Eduardo Valentin edubez...@gmail.com
   Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
   ---
drivers/thermal/samsung/exynos_tmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
  
   diff --git a/drivers/thermal/samsung/exynos_tmu.c
   b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527
   100644 --- a/drivers/thermal/samsung/exynos_tmu.c
   +++ b/drivers/thermal/samsung/exynos_tmu.c
   @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
   platform_device *pdev, bool on)
 if (on) {
 con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
   + con |= (1  EXYNOS7_PD_DET_EN_SHIFT);
 interrupt_en =
 (of_thermal_is_trip_valid(tz, 7)
  EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
   @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
   platform_device *pdev, bool on) interrupt_en 
   EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
 con = ~(1  EXYNOS_TMU_CORE_EN_SHIFT);
   + con = ~(1  EXYNOS7_PD_DET_EN_SHIFT);
 interrupt_en = 0; /* Disable all interrupts */
 }
   - con |= 1  EXYNOS7_PD_DET_EN_SHIFT;
  
 writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
 writel(con, data-base + EXYNOS_TMU_REG_CONTROL);
  
   Could you test this patch if it isn't introducing any regression on
   your HW?
  
  The patch does not cause any regression on exynos7 and seems
  logically correct.
  
  Tested-by: Abhilash Kesavan a.kesa...@samsung.com
  
 
 Eduardo, it is up to you if you prefer to take this fix directly or via
 the new thermal-samsung tree ?
 
 From when shall I regard myself as a maintainer? :-)
 

Yeah. Go ahead and collect it.

 
  
  Regards,
  Abhilash
  
   --
   Best regards,
  
   Lukasz Majewski
  
   Samsung RD Institute Poland (SRPOL) | Linux Platform Group
 
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH v5 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

On Wed, Feb 25, 2015 at 04:34:19PM +0100, Lukasz Majewski wrote:
 With those bindings it is possible to use pwm-fan device available in
 Odroid U3 as a cooling device.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

Acked-by: Eduardo Valentin edubez...@gmail.com

 ---
 Changes for v2:
 - Rename cooling-pwm-values property to cooling-levels
 Changes for v3:
 - Change patch's topic to ARM dts
 - Reduce maximal cooling-level to 230 from 255
 Changes for v4:
 - None
 Changes for v5:
 - None
 ---
  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 
 ++-
  1 file changed, 32 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
 b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 index 4c04837..abcfa3c 100644
 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
 +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 @@ -32,9 +32,40 @@
   };
   };
  
 - pwm-fan {
 + fan0: pwm-fan {
   compatible = pwm-fan;
   pwms = pwm 0 1 0;
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + cooling-levels = 0 102 170 230;
 + };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = cpu0 7 7;
 + };
 + map1 {
 +  trip = cpu_alert2;
 +  cooling-device = cpu0 13 13;
 + };
 + map2 {
 +  trip = cpu_alert0;
 +  cooling-device = fan0 0 1;
 + };
 + map3 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 1 2;
 + };
 + map4 {
 +  trip = cpu_alert2;
 +  cooling-device = fan0 2 3;
 + };
 + };
 + };
   };
  };
  
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Wed, Feb 25, 2015 at 03:11:24PM -0400, Eduardo Valentin wrote:
 On Wed, Feb 25, 2015 at 04:34:17PM +0100, Lukasz Majewski wrote:
  Explanation of several properties, which allow PWM fan working as a cooling
  device, have been embraced in this commit.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  ---
  Changes for v2:
  - Rename cooling-pwm-values to cooling-levels
  - Remove default-pulse-width property and stick to default hwmon policy
  Changes for v3:
  - Changing commit title from hwmon: dts: Doc: to Documentation: dts
  - Remove unnecessary properties
  - Set maximal cooling level to 230 instead of 255
  Changes for v4:
  - None
  Changes for v5:
  - Move thermal-zones description to example section
  - Extending example section
  
  ---
   .../devicetree/bindings/hwmon/pwm-fan.txt  | 25 
  +-
   1 file changed, 24 insertions(+), 1 deletion(-)
  
  diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
  b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
  index 610757c..645251b 100644
  --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
  +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
  @@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
   Required properties:
   - compatible   : pwm-fan
   - pwms : the PWM that is used to control the PWM fan
  +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
  +   which correspond to thermal cooling states
   
   Example:
  -   pwm-fan {
  +   fan0: pwm-fan {
  compatible = pwm-fan;
  status = okay;
  pwms = pwm 0 1 0;
  +   cooling-levels = 0 102 170 230;
  +   };
  +
  +   thermal-zones {
  +   cpu_thermal: cpu-thermal {
  +   cooling-min-state = 0;
  +   cooling-max-state = 3;
  +   #cooling-cells = 2;
  +   trips {
  +   cpu_alert1: cpu-alert1 {
  +   temperature = 10; /* millicelsius */
  +   hysteresis = 2000; /* millicelsius */
  +   type = passive;
  +   };
  +   };
  +   cooling-maps {
  +   map0 {
  +trip = cpu_alert1;
  +cooling-device = fan0 0 1;
  +   };
  +   };
 
 The above example has two issues:
 (1) it is wrong, as the cooling device properties are in the thermal
 zone node.
 (2) has a misalignment / tabulation
 
 Can you please fix that in your next version too?


Apart from the above two issues you may add my 
Acked-by: Eduardo Valentin edubez...@gmail.com

 
  };
  -- 
  2.0.0.rc2
  




signature.asc
Description: Digital signature

Re: [PATCH v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Wed, Feb 25, 2015 at 04:34:17PM +0100, Lukasz Majewski wrote:
 Explanation of several properties, which allow PWM fan working as a cooling
 device, have been embraced in this commit.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Rename cooling-pwm-values to cooling-levels
 - Remove default-pulse-width property and stick to default hwmon policy
 Changes for v3:
 - Changing commit title from hwmon: dts: Doc: to Documentation: dts
 - Remove unnecessary properties
 - Set maximal cooling level to 230 instead of 255
 Changes for v4:
 - None
 Changes for v5:
 - Move thermal-zones description to example section
 - Extending example section
 
 ---
  .../devicetree/bindings/hwmon/pwm-fan.txt  | 25 
 +-
  1 file changed, 24 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
 b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 index 610757c..645251b 100644
 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 @@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
  Required properties:
  - compatible : pwm-fan
  - pwms   : the PWM that is used to control the PWM fan
 +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
 + which correspond to thermal cooling states
  
  Example:
 - pwm-fan {
 + fan0: pwm-fan {
   compatible = pwm-fan;
   status = okay;
   pwms = pwm 0 1 0;
 + cooling-levels = 0 102 170 230;
 + };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + trips {
 + cpu_alert1: cpu-alert1 {
 + temperature = 10; /* millicelsius */
 + hysteresis = 2000; /* millicelsius */
 + type = passive;
 + };
 + };
 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 0 1;
 + };
 + };

The above example has two issues:
(1) it is wrong, as the cooling device properties are in the thermal
zone node.
(2) has a misalignment / tabulation

Can you please fix that in your next version too?

   };
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
 With those bindings it is possible to use pwm-fan device available in
 Odroid U3 as a cooling device.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Rename cooling-pwm-values property to cooling-levels
 Changes for v3:
 - Change patch's topic to ARM dts
 - Reduce maximal cooling-level to 230 from 255
 Changes for v4:
 - None
 ---
  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 
 ++-
  1 file changed, 32 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
 b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 index 60bd1e4..3e5df3e 100644
 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
 +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 @@ -32,11 +32,42 @@
   };
   };
  
 - pwm-fan {
 + fan0: pwm-fan {
   compatible = pwm-fan;
   pwms = pwm 0 1 0;
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + cooling-levels = 0 102 170 230;
   status = okay;
   };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {


This thermal zone misses the mandatory properties as per 
 Documentation/devicetree/bindings/thermal/thermal.txt

 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = cpu0 7 7;
 + };
 + map1 {
 +  trip = cpu_alert2;
 +  cooling-device = cpu0 13 13;
 + };
 + map2 {
 +  trip = cpu_alert0;
 +  cooling-device = fan0 0 1;
 + };
 + map3 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 1 2;
 + };
 + map4 {
 +  trip = cpu_alert2;
 +  cooling-device = fan0 2 3;
 + };
 + };
 + };
 + };
  };
  
  pwm {
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Eduardo Valentin]

On Tue, Feb 24, 2015 at 01:56:54PM +0900, Chanwoo Choi wrote:
 This patch fixes the wrong control of PD_DET_EN (power down detection mode)
 for Exynos7 because exynos7_tmu_control() always enables the power down 
 detection
 mode regardless 'on' parameter.
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: Eduardo Valentin edubez...@gmail.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Lukasz,

Any objections to this code?

BR,

Eduardo Valentin

 ---
  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 933cd80..a60f527 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct platform_device 
 *pdev, bool on)
  
   if (on) {
   con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
 + con |= (1  EXYNOS7_PD_DET_EN_SHIFT);
   interrupt_en =
   (of_thermal_is_trip_valid(tz, 7)
EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
 @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct platform_device 
 *pdev, bool on)
   interrupt_en  EXYNOS_TMU_INTEN_FALL0_SHIFT;
   } else {
   con = ~(1  EXYNOS_TMU_CORE_EN_SHIFT);
 + con = ~(1  EXYNOS7_PD_DET_EN_SHIFT);
   interrupt_en = 0; /* Disable all interrupts */
   }
 - con |= 1  EXYNOS7_PD_DET_EN_SHIFT;
  
   writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
   writel(con, data-base + EXYNOS_TMU_REG_CONTROL);
 -- 
 1.8.5.5
 


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] thermal: Provide stub for thermal_cdev_update() function

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:30AM +0100, Lukasz Majewski wrote:
 Odroid U3 fan can work without being registered as OF cooling device
 (with CONFIG_THERMAL{_OF|} disabled).
 In this situation it can be controlled via PWM entry at
 /sys/class/hwmon/hwmon0/pwm1.
 
 Therefore, the thermal_cdev_update() function needs a stub
 to allow clean compilation.

I've just applied a patch on this same matter from Nishanth Menon [1].
Can you please check if his patch is enough for you?

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixesid=12ca7188468ee29c4e717f73db4bf43c90954fc7

 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - New patch
 Changes for v3:
 - thermal_cdev_update() now depends on CONFIG_THERMAL flag
 Changes for v4:
 - None
 ---
  include/linux/thermal.h | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index eacf2de..25382e6 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -298,6 +298,7 @@ struct thermal_cooling_device *
  thermal_of_cooling_device_register(struct device_node *np,
  char *type, void *devdata,
  const struct thermal_cooling_device_ops *);
 +void thermal_cdev_update(struct thermal_cooling_device *);
  #else
  static inline struct thermal_cooling_device *
  thermal_of_cooling_device_register(struct device_node *np,
 @@ -306,6 +307,9 @@ thermal_of_cooling_device_register(struct device_node *np,
  {
   return NULL;
  }
 +static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
 +{
 +}
  #endif
  #ifdef CONFIG_THERMAL_OF
  struct thermal_zone_device *
 @@ -349,7 +353,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
 unsigned long *temp);
  int get_tz_trend(struct thermal_zone_device *, int);
  struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
   struct thermal_cooling_device *, int);
 -void thermal_cdev_update(struct thermal_cooling_device *);
  void thermal_notify_framework(struct thermal_zone_device *, int);
  
  #ifdef CONFIG_NET
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:29AM +0100, Lukasz Majewski wrote:
 Odroid U3 fan can work without being registered as OF cooling device
 (with CONFIG_THERMAL_OF disabled).
 In this situation it can be controlled via PWM entry at
 /sys/class/hwmon/hwmon0/pwm1.
 
 Therefore, the thermal_of_cooling_device_register() function needs a stub
 to allow clean compilation.


I've just applied a patch on this same matter from Nishanth Menon [1].
Can you please check if his patch is enough for you?

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixesid=12ca7188468ee29c4e717f73db4bf43c90954fc7


 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 Changes for v3:
 - Provide stub declaration when CONFIG_THERMAL is not set
 Changes for v4:
 - None
 ---
  include/linux/thermal.h | 17 ++---
  1 file changed, 14 insertions(+), 3 deletions(-)
 
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index fc52e30..eacf2de 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -293,6 +293,20 @@ struct thermal_trip {
  };
  
  /* Function declarations */
 +#ifdef CONFIG_THERMAL
 +struct thermal_cooling_device *
 +thermal_of_cooling_device_register(struct device_node *np,
 +char *type, void *devdata,
 +const struct thermal_cooling_device_ops *);
 +#else
 +static inline struct thermal_cooling_device *
 +thermal_of_cooling_device_register(struct device_node *np,
 +char *type, void *devdata,
 +const struct thermal_cooling_device_ops *ops)
 +{
 + return NULL;
 +}
 +#endif
  #ifdef CONFIG_THERMAL_OF
  struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
 @@ -328,9 +342,6 @@ void thermal_zone_device_update(struct 
 thermal_zone_device *);
  
  struct thermal_cooling_device *thermal_cooling_device_register(char *, void 
 *,
   const struct thermal_cooling_device_ops *);
 -struct thermal_cooling_device *
 -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
 -const struct thermal_cooling_device_ops *);
  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
  struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
  int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
 *temp);
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v4 3/8] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:31AM +0100, Lukasz Majewski wrote:
 Explanation of several properties, which allow PWM fan working as a cooling
 device, have been embraced in this commit.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Rename cooling-pwm-values to cooling-levels
 - Remove default-pulse-width property and stick to default hwmon policy
 Changes for v3:
 - Changing commit title from hwmon: dts: Doc: to Documentation: dts
 - Remove unnecessary properties
 - Set maximal cooling level to 230 instead of 255
 Changes for v4:
 - None
 ---
  Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 20 
  1 file changed, 20 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
 b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 index 610757c..d53fe0c 100644
 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 @@ -3,10 +3,30 @@ Bindings for a fan connected to the PWM lines
  Required properties:
  - compatible : pwm-fan
  - pwms   : the PWM that is used to control the PWM fan
 +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
 + which correspond to thermal cooling states
 +
 +Thorough description of the following bindings:
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + thermal-zone {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 0 1;
 + };
 + };
 + };

I am fine if you leave the reference to thermal.txt biding description,
but I would prefer if you move the above lines to a proper example section.

 +
 +for PWM FAN used as cooling device can be found at:
 +./Documentation/devicetree/bindings/thermal/thermal.txt
  
  Example:
   pwm-fan {
   compatible = pwm-fan;
   status = okay;
   pwms = pwm 0 1 0;
 + cooling-levels = 0 102 170 230;
   };
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

[PATCH 14/14] cpufreq: exynos-cpufreq: release resources by using managed allocation

[Eduardo Valentin]

This change allows the proper resource release used by this driver.
The resources are now allocated using managed allocation by means
of the devm_* helper functions. Those resources that cannot be managed
are properly released during the device removal time.

The global variables have been removed as well. All static variables
were moved to driver data and properly assigned to cpufreq
driver data. In callbacks, now the data structure allocated
in probe time is fetched from cpufreq policy.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos-cpufreq.c | 99 +---
 drivers/cpufreq/exynos-cpufreq.h |  5 ++
 2 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index a964602..f1a13e8 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -23,12 +23,8 @@
 
 #include exynos-cpufreq.h
 
-static struct exynos_dvfs_info *exynos_info;
-static struct thermal_cooling_device *cdev;
-static struct regulator *arm_regulator;
-static unsigned int locking_frequency;
-
-static int exynos_cpufreq_get_index(unsigned int freq)
+static int exynos_cpufreq_get_index(struct exynos_dvfs_info *exynos_info,
+   unsigned int freq)
 {
struct cpufreq_frequency_table *freq_table = exynos_info-freq_table;
struct cpufreq_frequency_table *pos;
@@ -43,7 +39,8 @@ static int exynos_cpufreq_get_index(unsigned int freq)
return pos - freq_table;
 }
 
-static int exynos_cpufreq_scale(unsigned int target_freq)
+static int exynos_cpufreq_scale(struct exynos_dvfs_info *exynos_info,
+   unsigned int target_freq)
 {
struct cpufreq_frequency_table *freq_table = exynos_info-freq_table;
unsigned int *volt_table = exynos_info-volt_table;
@@ -62,13 +59,13 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
 * old_index with cpufreq_frequency_table_target(). Thus, ignore
 * policy and get the index from the raw frequency table.
 */
-   old_index = exynos_cpufreq_get_index(old_freq);
+   old_index = exynos_cpufreq_get_index(exynos_info, old_freq);
if (old_index  0) {
ret = old_index;
goto out;
}
 
-   index = exynos_cpufreq_get_index(target_freq);
+   index = exynos_cpufreq_get_index(exynos_info, target_freq);
if (index  0) {
ret = index;
goto out;
@@ -90,7 +87,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
/* When the new frequency is higher than current frequency */
if ((target_freq  old_freq)  !safe_arm_volt) {
/* Firstly, voltage up to increase frequency */
-   ret = regulator_set_voltage(arm_regulator, arm_volt, arm_volt);
+   ret = regulator_set_voltage(exynos_info-arm_regulator,
+   arm_volt, arm_volt);
if (ret) {
dev_err(dev, failed to set cpu voltage to %d\n,
arm_volt);
@@ -99,8 +97,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
}
 
if (safe_arm_volt) {
-   ret = regulator_set_voltage(arm_regulator, safe_arm_volt,
- safe_arm_volt);
+   ret = regulator_set_voltage(exynos_info-arm_regulator,
+   safe_arm_volt, safe_arm_volt);
if (ret) {
dev_err(dev, failed to set cpu voltage to %d\n,
safe_arm_volt);
@@ -114,8 +112,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
if ((target_freq  old_freq) ||
   ((target_freq  old_freq)  safe_arm_volt)) {
/* down the voltage after frequency change */
-   ret = regulator_set_voltage(arm_regulator, arm_volt,
-   arm_volt);
+   ret = regulator_set_voltage(exynos_info-arm_regulator,
+   arm_volt, arm_volt);
if (ret) {
dev_err(dev, failed to set cpu voltage to %d\n,
arm_volt);
@@ -131,22 +129,39 @@ out:
 
 static int exynos_target(struct cpufreq_policy *policy, unsigned int index)
 {
-   return exynos_cpufreq_scale(exynos_info-freq_table[index].frequency);
+   struct exynos_dvfs_info *exynos_info = policy-driver_data;
+
+   return exynos_cpufreq_scale(exynos_info,
+   exynos_info-freq_table[index].frequency);
 }
 
 static int

[PATCH 06/14] cpufreq: exynos4x12: use devm_clk_get

[Eduardo Valentin]

Switch to managed clk_get to properly release resources when
they are not needed.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4x12-cpufreq.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c 
b/drivers/cpufreq/exynos4x12-cpufreq.c
index 3da36baf..7e0dd2a 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -189,23 +189,23 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
return -EFAULT;
}
 
-   cpu_clk = clk_get(NULL, armclk);
+   cpu_clk = devm_clk_get(info-dev, armclk);
if (IS_ERR(cpu_clk))
-   return PTR_ERR(cpu_clk);
+   goto err;
 
-   moutcore = clk_get(NULL, moutcore);
+   moutcore = devm_clk_get(info-dev, moutcore);
if (IS_ERR(moutcore))
-   goto err_moutcore;
+   goto err;
 
-   mout_mpll = clk_get(NULL, mout_mpll);
+   mout_mpll = devm_clk_get(info-dev, mout_mpll);
if (IS_ERR(mout_mpll))
-   goto err_mout_mpll;
+   goto err;
 
rate = clk_get_rate(mout_mpll) / 1000;
 
-   mout_apll = clk_get(NULL, mout_apll);
+   mout_apll = devm_clk_get(info-dev, mout_apll);
if (IS_ERR(mout_apll))
-   goto err_mout_apll;
+   goto err;
 
if (info-type == EXYNOS_SOC_4212)
apll_freq_4x12 = apll_freq_4212;
@@ -225,13 +225,7 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 
return 0;
 
-err_mout_apll:
-   clk_put(mout_mpll);
-err_mout_mpll:
-   clk_put(moutcore);
-err_moutcore:
-   clk_put(cpu_clk);
-
+err:
iounmap(info-cmu_regs);
of_node_put(np);
pr_debug(%s: failed initialization\n, __func__);
-- 
2.1.3

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

[PATCH 01/14] cpufreq: exynos4210: properly put of node

[Eduardo Valentin]

Call of_node_put when necessary during init.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4210-cpufreq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index 843ec82..dba48f0 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -169,6 +169,7 @@ int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
info-set_freq = exynos4210_set_frequency;
 
cpufreq = info;
+   of_node_put(np);
 
return 0;
 
@@ -179,6 +180,8 @@ err_mout_mpll:
 err_moutcore:
clk_put(cpu_clk);
 
+   of_node_put(np);
pr_debug(%s: failed initialization\n, __func__);
+
return -EINVAL;
 }
-- 
2.1.3

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

[PATCH 08/14] cpufreq: exynos5250: iounmap in error path

[Eduardo Valentin]

When error occurs, allow systems to release iomapped area.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos5250-cpufreq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/exynos5250-cpufreq.c 
b/drivers/cpufreq/exynos5250-cpufreq.c
index 50b0cdf..e61d149 100644
--- a/drivers/cpufreq/exynos5250-cpufreq.c
+++ b/drivers/cpufreq/exynos5250-cpufreq.c
@@ -206,6 +206,7 @@ err_mout_mpll:
 err_moutcore:
clk_put(cpu_clk);
 
+   iounmap(info-cmu_regs);
of_node_put(np);
pr_err(%s: failed initialization\n, __func__);
 
-- 
2.1.3

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

[PATCH 11/14] cpufreq: exynos4210: remove unused symbol cpufreq

[Eduardo Valentin]

Now that the set_freq call back receives the intended
data struct, the global cpufreq variable may be removed.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4210-cpufreq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index 00889a4..6757bda 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -25,7 +25,6 @@ static struct clk *cpu_clk;
 static struct clk *moutcore;
 static struct clk *mout_mpll;
 static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
 
 static unsigned int exynos4210_volt_table[] = {
125, 115, 105, 975000, 95,
@@ -171,7 +170,6 @@ int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
info-freq_table = exynos4210_freq_table;
info-set_freq = exynos4210_set_frequency;
 
-   cpufreq = info;
of_node_put(np);
 
return 0;
-- 
2.1.3

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

[PATCH 13/14] cpufreq: exynos5250: remove unused symbol cpufreq

[Eduardo Valentin]

Now that the set_freq call back receives the intended
data struct, the global cpufreq variable may be removed.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos5250-cpufreq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/cpufreq/exynos5250-cpufreq.c 
b/drivers/cpufreq/exynos5250-cpufreq.c
index 191a511..ee274c9 100644
--- a/drivers/cpufreq/exynos5250-cpufreq.c
+++ b/drivers/cpufreq/exynos5250-cpufreq.c
@@ -25,7 +25,6 @@ static struct clk *cpu_clk;
 static struct clk *moutcore;
 static struct clk *mout_mpll;
 static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
 
 static unsigned int exynos5250_volt_table[] = {
130, 125, 1225000, 120, 115,
@@ -197,7 +196,6 @@ int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
info-freq_table = exynos5250_freq_table;
info-set_freq = exynos5250_set_frequency;
 
-   cpufreq = info;
of_node_put(np);
 
return 0;
-- 
2.1.3

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

Re: [PATCHv2 1/1] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Mon, Feb 02, 2015 at 09:33:09AM +0530, Viresh Kumar wrote:
 On 1 February 2015 at 00:29, Eduardo Valentin edubez...@gmail.com wrote:
  From: Arnd Bergmann a...@arndb.de
 

big cut

 
 Acked-by: Viresh Kumar viresh.ku...@linaro.org

Thanks!

 
 Now as these are all compilable as modules, should we look into the drivers as
 well to see what they are doing on module unload ?

hmm.. it seams to be the case, yes. From a quick look, there are unreleased 
resources
that needs to be freed. However, they are not really on module unload,
but on device removal. Which should be a reproducible but even today, in
case one manually unbinds the device.

Let me have a look here and will be sending something soon.


Thanks,

Eduardo Valentin



signature.asc
Description: Digital signature

[PATCH 03/14] cpufreq: exynos4210: use devm_clk_get

[Eduardo Valentin]

Switch to managed clk_get to properly release resources when
they are not needed.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4210-cpufreq.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index 8a25dce..fc02a39 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -142,23 +142,23 @@ int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
return -EFAULT;
}
 
-   cpu_clk = clk_get(NULL, armclk);
+   cpu_clk = devm_clk_get(info-dev, armclk);
if (IS_ERR(cpu_clk))
-   return PTR_ERR(cpu_clk);
+   goto err;
 
-   moutcore = clk_get(NULL, moutcore);
+   moutcore = devm_clk_get(info-dev, moutcore);
if (IS_ERR(moutcore))
-   goto err_moutcore;
+   goto err;
 
-   mout_mpll = clk_get(NULL, mout_mpll);
+   mout_mpll = devm_clk_get(info-dev, mout_mpll);
if (IS_ERR(mout_mpll))
-   goto err_mout_mpll;
+   goto err;
 
rate = clk_get_rate(mout_mpll) / 1000;
 
-   mout_apll = clk_get(NULL, mout_apll);
+   mout_apll = devm_clk_get(info-dev, mout_apll);
if (IS_ERR(mout_apll))
-   goto err_mout_apll;
+   goto err;
 
info-mpll_freq_khz = rate;
/* 800Mhz */
@@ -173,13 +173,7 @@ int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
 
return 0;
 
-err_mout_apll:
-   clk_put(mout_mpll);
-err_mout_mpll:
-   clk_put(moutcore);
-err_moutcore:
-   clk_put(cpu_clk);
-
+err:
iounmap(info-cmu_regs);
of_node_put(np);
pr_debug(%s: failed initialization\n, __func__);
-- 
2.1.3

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

[PATCH 09/14] cpufreq: exynos5250: use devm_clk_get

[Eduardo Valentin]

Switch to managed clk_get to properly release resources when
they are not needed.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos5250-cpufreq.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/exynos5250-cpufreq.c 
b/drivers/cpufreq/exynos5250-cpufreq.c
index e61d149..d3ce829 100644
--- a/drivers/cpufreq/exynos5250-cpufreq.c
+++ b/drivers/cpufreq/exynos5250-cpufreq.c
@@ -168,23 +168,23 @@ int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
return -EFAULT;
}
 
-   cpu_clk = clk_get(NULL, armclk);
+   cpu_clk = devm_clk_get(info-dev, armclk);
if (IS_ERR(cpu_clk))
-   return PTR_ERR(cpu_clk);
+   goto err;
 
-   moutcore = clk_get(NULL, mout_cpu);
+   moutcore = devm_clk_get(info-dev, mout_cpu);
if (IS_ERR(moutcore))
-   goto err_moutcore;
+   goto err;
 
-   mout_mpll = clk_get(NULL, mout_mpll);
+   mout_mpll = devm_clk_get(info-dev, mout_mpll);
if (IS_ERR(mout_mpll))
-   goto err_mout_mpll;
+   goto err;
 
rate = clk_get_rate(mout_mpll) / 1000;
 
-   mout_apll = clk_get(NULL, mout_apll);
+   mout_apll = devm_clk_get(info-dev, mout_apll);
if (IS_ERR(mout_apll))
-   goto err_mout_apll;
+   goto err;
 
info-mpll_freq_khz = rate;
/* 800Mhz */
@@ -199,13 +199,7 @@ int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
 
return 0;
 
-err_mout_apll:
-   clk_put(mout_mpll);
-err_mout_mpll:
-   clk_put(moutcore);
-err_moutcore:
-   clk_put(cpu_clk);
-
+err:
iounmap(info-cmu_regs);
of_node_put(np);
pr_err(%s: failed initialization\n, __func__);
-- 
2.1.3

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

[PATCH 04/14] cpufreq: exynos4x12: properly put of node

[Eduardo Valentin]

Call of_node_put when necessary during init.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4x12-cpufreq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c 
b/drivers/cpufreq/exynos4x12-cpufreq.c
index 9e78a85..3d067f2 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -221,6 +221,7 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
info-set_freq = exynos4x12_set_frequency;
 
cpufreq = info;
+   of_node_put(np);
 
return 0;
 
@@ -231,6 +232,8 @@ err_mout_mpll:
 err_moutcore:
clk_put(cpu_clk);
 
+   of_node_put(np);
pr_debug(%s: failed initialization\n, __func__);
+
return -EINVAL;
 }
-- 
2.1.3

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

[PATCH 02/14] cpufreq: exynos4210: iounmap in error path

[Eduardo Valentin]

When error occurs, allow systems to release iomapped area.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos4210-cpufreq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index dba48f0..8a25dce 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -180,6 +180,7 @@ err_mout_mpll:
 err_moutcore:
clk_put(cpu_clk);
 
+   iounmap(info-cmu_regs);
of_node_put(np);
pr_debug(%s: failed initialization\n, __func__);
 
-- 
2.1.3

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

[PATCH 10/14] cpufreq: exynox-cpufreq: pass exynos_dvfs_info to .set_freq callback

[Eduardo Valentin]

This change passes the exynos_dvfs_info to the .set_freq callback
to avoid using local static variables. Now, the core can use
same allocated data structure and child code can work on same
data structure.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/exynos-cpufreq.c |  2 +-
 drivers/cpufreq/exynos-cpufreq.h |  2 +-
 drivers/cpufreq/exynos4210-cpufreq.c | 17 ++---
 drivers/cpufreq/exynos4x12-cpufreq.c | 19 +++
 drivers/cpufreq/exynos5250-cpufreq.c | 19 +++
 5 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 5e98c6b..a964602 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -108,7 +108,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
}
}
 
-   exynos_info-set_freq(old_index, index);
+   exynos_info-set_freq(exynos_info, old_index, index);
 
/* When the new frequency is lower than current frequency */
if ((target_freq  old_freq) ||
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 9f2062a..b59558e 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -48,7 +48,7 @@ struct exynos_dvfs_info {
struct clk  *cpu_clk;
unsigned int*volt_table;
struct cpufreq_frequency_table  *freq_table;
-   void (*set_freq)(unsigned int, unsigned int);
+   void (*set_freq)(struct exynos_dvfs_info *, unsigned int, unsigned int);
bool (*need_apll_change)(unsigned int, unsigned int);
void __iomem*cmu_regs;
 };
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index fc02a39..00889a4 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -55,7 +55,8 @@ static struct apll_freq apll_freq_4210[] = {
APLL_FREQ(200,  0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
 };
 
-static void exynos4210_set_clkdiv(unsigned int div_index)
+static void exynos4210_set_clkdiv(struct exynos_dvfs_info *cpufreq,
+ unsigned int div_index)
 {
unsigned int tmp;
 
@@ -80,7 +81,8 @@ static void exynos4210_set_clkdiv(unsigned int div_index)
} while (tmp  0x11);
 }
 
-static void exynos4210_set_apll(unsigned int index)
+static void exynos4210_set_apll(struct exynos_dvfs_info *cpufreq,
+   unsigned int index)
 {
unsigned int tmp, freq = apll_freq_4210[index].freq;
 
@@ -104,15 +106,16 @@ static void exynos4210_set_apll(unsigned int index)
} while (tmp != (0x1  EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
 }
 
-static void exynos4210_set_frequency(unsigned int old_index,
+static void exynos4210_set_frequency(struct exynos_dvfs_info *cpufreq,
+unsigned int old_index,
 unsigned int new_index)
 {
if (old_index  new_index) {
-   exynos4210_set_clkdiv(new_index);
-   exynos4210_set_apll(new_index);
+   exynos4210_set_clkdiv(cpufreq, new_index);
+   exynos4210_set_apll(cpufreq, new_index);
} else if (old_index  new_index) {
-   exynos4210_set_apll(new_index);
-   exynos4210_set_clkdiv(new_index);
+   exynos4210_set_apll(cpufreq, new_index);
+   exynos4210_set_clkdiv(cpufreq, new_index);
}
 }
 
diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c 
b/drivers/cpufreq/exynos4x12-cpufreq.c
index 7e0dd2a..d12087b 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -100,7 +100,8 @@ static struct apll_freq apll_freq_4412[] = {
APLL_FREQ(200,  0, 1, 3, 0, 1, 1, 1, 0, 3, 0, 0, 100, 3, 2),
 };
 
-static void exynos4x12_set_clkdiv(unsigned int div_index)
+static void exynos4x12_set_clkdiv(struct exynos_dvfs_info *cpufreq,
+ unsigned int div_index)
 {
unsigned int tmp;
 
@@ -125,7 +126,8 @@ static void exynos4x12_set_clkdiv(unsigned int div_index)
} while (tmp != 0x0);
 }
 
-static void exynos4x12_set_apll(unsigned int index)
+static void exynos4x12_set_apll(struct exynos_dvfs_info *cpufreq,
+   unsigned int index)
 {
unsigned int tmp, freq = apll_freq_4x12[index].freq;
 
@@ -151,15 +153,16 @@ static void exynos4x12_set_apll(unsigned int index)
} while (tmp != (0x1  EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
 }
 
-static void exynos4x12_set_frequency(unsigned int old_index,
- unsigned int new_index)
+static void

Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Eduardo Valentin]

On Tue, Jan 27, 2015 at 11:18:22AM +0530, Abhilash Kesavan wrote:
 Add registers, bit fields and compatible strings for Exynos7 TMU
 (Thermal Management Unit). Following are a few of the differences
 in the Exynos7 TMU from earlier SoCs:
 - 8 trigger levels
 - Different bit offsets and more registers for the rising
 and falling thresholds.
 - New power down detection bit in the TMU_CONTROL register
 which does not update the CURRENT_TEMP0 when tmu power down
 is detected.
 - Change in bit offset for the NEXT_DATA field of EMUL_CON
 register. EMUL_CON register address has also changed.
 - INTSTAT and INTCLEAR registers present in earlier SoCs
 have been combined into one INTPEND register. The register
 address for INTCLEAR and INTPEND is also different.
 - Since there are 8 rising/falling interrupts as against
 at most 4 in earlier SoCs the INTEN bit offsets are different.
 - Multiple probe support which is handled by a TMU_CONTROL1
 register (No support for this in the current patch).
 
 This patch adds special clock support required only for Exynos7. It
 also updates the code_to_temp prototype as Exynos7 has 9 bit
 code-temp mapping.
 
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com

Applied to my -fixes branch. However, I had to amend it myself to make
checkpatch.pl --strict silent. In this version, it still outputs:
CHECK: Alignment should match open parenthesis
#209: FILE: drivers/thermal/samsung/exynos_tmu.c:558:
+   if (!data-temp_error1 ||
+  (pdata-min_efuse_value  data-temp_error1) ||

CHECK: multiple assignments should be avoided
#366: FILE: drivers/thermal/samsung/exynos_tmu.c:882:
+   tmu_intstat = tmu_intclear = EXYNOS7_TMU_REG_INTPEND;

total: 0 errors, 0 warnings, 2 checks, 314 lines checked

next, make sure you run checkpatch.pl --strict before sending patches.


 ---
 This patch set has been tested on linux next-20150123 with Eduardo's
 thermal-next branch merged along with the arch-side exynos7 related
 dts changes applied.
 
 Changes since v3:
 Addressed comments from Lukasz Majewski:
   - Added more comments in the code setting the thresholds.
   - Split the documentation out into another patch.
 Changes since v2:
   - Rebased on top of Lukasz' latest exynos tmu series (v4).
   - Added new exynos7 soc_type.
 Changes since v1:
   - Rebased on top of Lukasz' latest exynos tmu series (v2).
   - Added sclk support to patch adding Exynos7 tmu support.
   Previously, it was a separate patch.
   - Used the SOC type to decide if sclk is present.
 
  drivers/thermal/samsung/exynos_tmu.c |  204 
 --
  drivers/thermal/samsung/exynos_tmu.h |1 +
  2 files changed, 197 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 852e622..660ff69 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -119,6 +119,26 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
  
 +/* Exynos7 specific registers */
 +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
 +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
 +#define EXYNOS7_TMU_REG_INTEN0x110
 +#define EXYNOS7_TMU_REG_INTPEND  0x118
 +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
 +
 +#define EXYNOS7_TMU_TEMP_MASK0x1ff
 +#define EXYNOS7_PD_DET_EN_SHIFT  23
 +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
 +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
 +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
 +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
 +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
 +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
 +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
 +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
 +#define EXYNOS7_EMUL_DATA_SHIFT  7
 +#define EXYNOS7_EMUL_DATA_MASK   0x1ff
 +
  #define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of the TMU
 @@ -133,6 +153,7 @@
   * @lock: lock to implement synchronization.
   * @clk: pointer to the clock structure.
   * @clk_sec: pointer to the clock structure for accessing the base_second.
 + * @sclk: pointer to the clock structure for accessing the tmu special clk.
   * @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.
 @@ -152,8 +173,8 @@ struct exynos_tmu_data {
   enum soc_type soc;
   struct work_struct irq_work;
   struct mutex lock;
 - struct clk *clk, *clk_sec;
 - u8 temp_error1, temp_error2;
 + struct clk 

[PATCHv2 1/1] cpufreq: exynos: allow modular build

[Eduardo Valentin]

From: Arnd Bergmann a...@arndb.de

The exynos cpufreq driver code recently gained a dependency on the
cooling code, which may be a loadable module. This breaks an ARM
allmodconfig build:

drivers/built-in.o: In function `exynos_cpufreq_probe':
:(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register'

To avoid this problem, change cpufreq Kconfig to allow the drivers
to be loadable modules as well and enforce a dependency on the
thermal module.

This change, in order to allow module builds on this cpufreq
driver, properly constructs the driver into a single module,
instead of several modules. The change also keeps the proper
platform dependency, and therefore, it wont load in platforms
that are not supposed to be loaded. The user will be able to
build the support for all platforms, or select which platforms
(s)he wants (as originally), except that now it can be a module,
instead.

Besides, it will still keep the driver only on those configs
that expect it to be on. And it won't compile/load on platforms
that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW
closer to this driver, so it looks better in the menuconfig.

We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to
avoid future troubles.

Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Fixes: e725d26c4857 (cpufreq: exynos: Use device tree to determine if cpufreq 
cooling should be registered)
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/cpufreq/Kconfig.arm | 44 ++--
 drivers/cpufreq/Makefile|  9 +
 2 files changed, 31 insertions(+), 22 deletions(-)
---
Changes from V1:
- Instead of having several modules, the driver now is constructed by several
files into a single module, depending on config.
- The patch does not change existing user defconfigs.

If no objections, I will include this in into my -fixes branch.

Cheers,

Eduardo Valentin


diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0f9a2c3..1b06fc4 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 
 
 config ARM_EXYNOS_CPUFREQ
-   bool
+   tristate SAMSUNG EXYNOS CPUfreq Driver
+   depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || 
SOC_EXYNOS5250
+   depends on THERMAL
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS platforms.
+ Supported SoC versions are:
+Exynos4210, Exynos4212, Exynos4412, and Exynos5250.
+
+ If in doubt, say N.
 
 config ARM_EXYNOS4210_CPUFREQ
bool SAMSUNG EXYNOS4210
depends on CPU_EXYNOS4210
+   depends on ARM_EXYNOS_CPUFREQ
default y
-   select ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS4210
  SoC (S5PV310 or S5PC210).
@@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ
 config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
+   depends on ARM_EXYNOS_CPUFREQ
default y
-   select ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS4X12
  SoC (EXYNOS4212 or EXYNOS4412).
@@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ
 config ARM_EXYNOS5250_CPUFREQ
bool SAMSUNG EXYNOS5250
depends on SOC_EXYNOS5250
+   depends on ARM_EXYNOS_CPUFREQ
default y
-   select ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS5250
  SoC.
 
  If in doubt, say N.
 
-config ARM_EXYNOS5440_CPUFREQ
-   bool SAMSUNG EXYNOS5440
-   depends on SOC_EXYNOS5440
-   depends on HAVE_CLK  OF
-   select PM_OPP
-   default y
-   help
- This adds the CPUFreq driver for Samsung EXYNOS5440
- SoC. The nature of exynos5440 clock controller is
- different than previous exynos controllers so not using
- the common exynos framework.
-
- If in doubt, say N.
-
 config ARM_EXYNOS_CPU_FREQ_BOOST_SW
bool EXYNOS Frequency Overclocking - Software
depends on ARM_EXYNOS_CPUFREQ  THERMAL
@@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 
  If in doubt, say N.
 
+config ARM_EXYNOS5440_CPUFREQ
+   tristate SAMSUNG EXYNOS5440
+   depends on SOC_EXYNOS5440
+   depends on HAVE_CLK  OF
+   select PM_OPP
+   default y
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
+ If in doubt, say N.
+
 config ARM_HIGHBANK_CPUFREQ
tristate Calxeda Highbank-based

Re: [PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Fri, Jan 30, 2015 at 10:24:12PM +0100, Arnd Bergmann wrote:
 On Thursday 29 January 2015 18:21:51 Eduardo Valentin wrote:
  Hello Arnd and Viresh,
  
  On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
   On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o 
exynos4210-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o 
exynos4x12-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o 
exynos5250-cpufreq.o

   
   I'd have to try it, but this might fail if one of the three drivers
   is built-in and another one is a module.
   
 Arnd
  
  Let me make one step back here. The original issue is, now this exynos
  cpufreq driver depends on of thermal; but of thermal can be built as
  module, while this cpufreq driver cannot. Original proposal is to allow
  module build in the exynos cpufreq driver.
  
  On the original proposal, my concern is that the driver code does not
  have separated modules, but one single module platform driver,  which uses 
  functions from
  other c files. On top of that, the patch originally allows four
  (independent) modules builds. Although the children drivers still
  selects the core part, we would still need to change the original patch
  to add module dependency too.
  
  So, my proposal was to, in order to allow module builds on this cpufreq
  driver, we also need to properly construct the driver into a single
  module, instead of several modules. The issue with my patch was the fact
  that it was allowing platforms that do not use that driver, to select it
  by default. And eventually this may cause a unusable module being loaded
  into those systems.
  
  Well, trying harder here in the same approach. The diff bellow is based
  on Arnd's original patch and on Viresh's amendment, except that the core
  part is now dependent on all the supported platforms, instead of
  ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
  to be loaded. The user will be able to build the support for all
  platforms, or select which platforms he/she wants (as originally),
  except that now it can be a module, instead.
  
  I believe now by default it will still keep the driver only on those
  configs that expect it to be on. And it won't compile/load on platforms
  that it is not supposed to. It brings closer a config that is dependent on 
  this
  driver, so it looks better in the menuconfig.
  
  Let me know if I missed something (feel free to amend to your patch):
 
 Yes, I think your refined approach works and is better than my
 original patch, thanks a lot for giving it more thought!
 
 One tiny problem:
 
  @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
   
If in doubt, say N.
   
  +config ARM_EXYNOS5440_CPUFREQ
  +   bool SAMSUNG EXYNOS5440
  +   depends on SOC_EXYNOS5440
  +   depends on HAVE_CLK  OF
  +   select PM_OPP
  +   default y
  +   help
  + This adds the CPUFreq driver for Samsung EXYNOS5440
  + SoC. The nature of exynos5440 clock controller is
  + different than previous exynos controllers so not using
  + the common exynos framework.
  +
  + If in doubt, say N.
 
 I believe this one also has to be tristate, for the same reason.
 

I agree with you that it is better if we make it tristate. So, on my
side, I have no concerns changing it to tristate.

However, the exynos5440 cpufreq driver does not depend on of thermal as
of today, and therefore, I did not touch this driver for this matter.
Meaning, if it is not causing troubles, no need to mess with it.

But I can add this change. No issues, on my side.

   
  -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
   extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
   #else
   static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
  @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct 
  exynos_dvfs_info *info)
  return -EOPNOTSUPP;
   }
   #endif
  -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
   extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
   #else
   static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
  @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct 
  exynos_dvfs_info *info)
  return -EOPNOTSUPP;
   }
   #endif
  -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
   extern int exynos5250_cpufreq_init(struct

Re: [PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

  THERMAL
@@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 
  If in doubt, say N.
 
+config ARM_EXYNOS5440_CPUFREQ
+   bool SAMSUNG EXYNOS5440
+   depends on SOC_EXYNOS5440
+   depends on HAVE_CLK  OF
+   select PM_OPP
+   default y
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
+ If in doubt, say N.
+
 config ARM_HIGHBANK_CPUFREQ
tristate Calxeda Highbank-based
depends on ARCH_HIGHBANK  CPUFREQ_DT  REGULATOR
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b3ca7b0..b26e2bf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,10 +51,11 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += 
arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += arm-exynos-cpufreq.o
+arm-exynos-cpufreq-y   := exynos-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)+= exynos4210-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)+= exynos4x12-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)+= exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 9f2062a..32a895a 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -53,7 +53,7 @@ struct exynos_dvfs_info {
void __iomem*cmu_regs;
 };
 
-#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
@@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct 
exynos_dvfs_info *info)
return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
 extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
@@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct 
exynos_dvfs_info *info)
return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
 extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)

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

Re: [PATCH 1/3] exynos: config: Remove CONFIG_EXYNOS_THERMAL_CORE define (exynos_defconfig)

[Eduardo Valentin]

On Wed, Jan 28, 2015 at 04:28:38PM +0100, Lukasz Majewski wrote:
 After Exynos TMU rework to use device tree for configuration this flag
 can be removed. It is not used anymore.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

I dont see problems with this patch:

Acked-by: Eduardo Valentin edubez...@gmail.com

This should go, obviously, via the correct platform tree.

 ---
  arch/arm/configs/exynos_defconfig | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index 3d0c5d6..3691a68 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -88,7 +88,6 @@ CONFIG_HWMON=y
  CONFIG_SENSORS_LM90=y
  CONFIG_THERMAL=y
  CONFIG_EXYNOS_THERMAL=y
 -CONFIG_EXYNOS_THERMAL_CORE=y
  CONFIG_WATCHDOG=y
  CONFIG_S3C2410_WATCHDOG=y
  CONFIG_MFD_CROS_EC=y
 -- 
 2.0.0.rc2
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] exynos: config: Enable thermal emulation for Exynos TMU (exynos_defconfig)

[Eduardo Valentin]

On Wed, Jan 28, 2015 at 04:28:39PM +0100, Lukasz Majewski wrote:
 Enabling thermal emulation on Exynos SoCs. New sysfs attribute - emul_temp
 is created.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

I dont see problems with this patch:

Acked-by: Eduardo Valentin edubez...@gmail.com

 ---
  arch/arm/configs/exynos_defconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index 3691a68..376dbf4 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -88,6 +88,7 @@ CONFIG_HWMON=y
  CONFIG_SENSORS_LM90=y
  CONFIG_THERMAL=y
  CONFIG_EXYNOS_THERMAL=y
 +CONFIG_THERMAL_EMULATION=y
  CONFIG_WATCHDOG=y
  CONFIG_S3C2410_WATCHDOG=y
  CONFIG_MFD_CROS_EC=y
 -- 
 2.0.0.rc2
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function

[Eduardo Valentin]

On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
 Hi Lukasz,
 
 On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski l.majew...@samsung.com 
 wrote:
  Hi Abhilash,
 
  Hi Lukasz,
 
  On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
  l.majew...@samsung.com wrote:
   The exynos_map_dt_data() function must be called before
   thermal_zone_of_sensor_register(), and hence provide tmu_read()
   function, before it is needed.
  
   This change is driven by adding support for enabling thermal_zoneX
   when it is properly initialized.
  
   One can read the mode of operation
   at /sys/class/thermal/thermal_zone0/mode Such functionality was
   missing in the of-thermal.c code.
  
   Reported-by: Abhilash Kesavan a.kesa...@samsung.com
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/thermal/samsung/exynos_tmu.c
   b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab 100644
   --- a/drivers/thermal/samsung/exynos_tmu.c
   +++ b/drivers/thermal/samsung/exynos_tmu.c
   @@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
   platform_device *pdev) platform_set_drvdata(pdev, data);
   mutex_init(data-lock);
  
   +   ret = exynos_map_dt_data(pdev);
   +   if (ret)
   +   goto err_sensor;
   +
   data-tzd = thermal_zone_of_sensor_register(pdev-dev, 0,
   data, exynos_sensor_ops);
   if (IS_ERR(data-tzd)) {
   pr_err(thermal: tz: %p ERROR\n, data-tzd);
   return PTR_ERR(data-tzd);
   }
   -   ret = exynos_map_dt_data(pdev);
   -   if (ret)
   -   goto err_sensor;
  
   pdata = data-pdata;
 
  I have been testing this along with your v5 patch set and am seeing
  incorrect temperature being reported at boot-up on exynos7.
 
  Does it show a maximal temperature value (0x1FF)?
 
 I did not print the current temperature register, but I remember the
 message showing ~105C. Will give you the register value when I test
 with more debug prints tomorrow.
 
 
   It looks
  like exynos_tmu_read gets called from thermal_zone_of_device_update
  during boot-up, now that we have it populated early. However, as the
  tmu initialization function has not been called yet it returns a wrong
  value. Does that sound correct ?
 
  No, this is a mistake. However, I'm wondering why on Exynos4/5 this
  error didn't show up...
 
 I have been lowering the software trip point temperature in the
 exynos7 dts file (to 55C) for testing purposes. Hence, when the
 temperature is read incorrectly as ~105C the board trips at boot-up
 itself. Maybe for exynos4/5 the incorrect value read during boot-up is
 in the non-tripping range and once the tmu is initialized later it
 continues to function properly thereafter ?
 
 
  The reordering is needed to be able to call set_mode callback at
  of-thermal.c to set the mode.
 
  If this change causes problems, then another solution (probably not so
  neat) must be found.
 
 Please let me know if you need any further details.

What is the status of this patch? Is it still required?

Cheers,

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

Re: [PATCH 3/3] exynos: config: Enable support for cpufreq on Exynos SoCs (exynos_defconfig)

[Eduardo Valentin]

On Wed, Jan 28, 2015 at 04:28:40PM +0100, Lukasz Majewski wrote:
 This commit enables the cpufreq subsystem. Moreover, support for using
 CPU as a cooling device is provided.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

I dont see problems with this patch:

Acked-by: Eduardo Valentin edubez...@gmail.com


Again, it must go via the correct tree.

 ---
  arch/arm/configs/exynos_defconfig | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index 376dbf4..d6be7e8 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -86,6 +86,8 @@ CONFIG_BATTERY_SBS=y
  CONFIG_CHARGER_TPS65090=y
  CONFIG_HWMON=y
  CONFIG_SENSORS_LM90=y
 +CONFIG_CPU_FREQ=y
 +CONFIG_CPU_THERMAL=y
  CONFIG_THERMAL=y
  CONFIG_EXYNOS_THERMAL=y
  CONFIG_THERMAL_EMULATION=y
 -- 
 2.0.0.rc2
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Wed, Jan 28, 2015 at 02:16:55PM +0100, Arnd Bergmann wrote:
 The exynos cpufreq driver code recently gained a dependency on the
 cooling code, which may be a loadable module. This breaks an ARM
 allmodconfig build:
 
 drivers/built-in.o: In function `exynos_cpufreq_probe':
 :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register'
 
 To avoid this problem, change cpufreq Kconfig to allow the drivers
 to be loadable modules as well and enforce a dependency on the
 thermal module. Also, export the symbols that are used for communicating
 between the three cpu-specific parts of the driver and the main module.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 Fixes: e725d26c4857 (cpufreq: exynos: Use device tree to determine if 
 cpufreq cooling should be registered)
 ---
  drivers/cpufreq/Kconfig.arm  | 14 +-
  drivers/cpufreq/exynos-cpufreq.h |  6 +++---
  drivers/cpufreq/exynos4210-cpufreq.c |  1 +
  drivers/cpufreq/exynos4x12-cpufreq.c |  1 +
  drivers/cpufreq/exynos5250-cpufreq.c |  1 +
  5 files changed, 15 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
 index 0f9a2c3c0e0d..99ac56746ebd 100644
 --- a/drivers/cpufreq/Kconfig.arm
 +++ b/drivers/cpufreq/Kconfig.arm
 @@ -26,11 +26,12 @@ config ARM_VEXPRESS_SPC_CPUFREQ
  
  
  config ARM_EXYNOS_CPUFREQ
 - bool
 + tristate
  
  config ARM_EXYNOS4210_CPUFREQ
 - bool SAMSUNG EXYNOS4210
 + tristate SAMSUNG EXYNOS4210
   depends on CPU_EXYNOS4210
 + depends on THERMAL
   default y
   select ARM_EXYNOS_CPUFREQ
   help
 @@ -40,8 +41,9 @@ config ARM_EXYNOS4210_CPUFREQ
 If in doubt, say N.
  
  config ARM_EXYNOS4X12_CPUFREQ
 - bool SAMSUNG EXYNOS4x12
 + tristate SAMSUNG EXYNOS4x12
   depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
 + depends on THERMAL
   default y
   select ARM_EXYNOS_CPUFREQ
   help
 @@ -51,8 +53,9 @@ config ARM_EXYNOS4X12_CPUFREQ
 If in doubt, say N.
  
  config ARM_EXYNOS5250_CPUFREQ
 - bool SAMSUNG EXYNOS5250
 + tristate SAMSUNG EXYNOS5250
   depends on SOC_EXYNOS5250
 + depends on THERMAL
   default y
   select ARM_EXYNOS_CPUFREQ
   help
 @@ -62,9 +65,10 @@ config ARM_EXYNOS5250_CPUFREQ
 If in doubt, say N.
  
  config ARM_EXYNOS5440_CPUFREQ
 - bool SAMSUNG EXYNOS5440
 + tristate SAMSUNG EXYNOS5440
   depends on SOC_EXYNOS5440
   depends on HAVE_CLK  OF
 + depends on THERMAL
   select PM_OPP
   default y
   help

Reading the code briefly, looks like the intention is to separate soc
specific code into different files, but they all compose one single
driver. Translating into module, I believe it makes sense to build them
into a single module, instead of having all of them as separate module.

Meaning, only ARM_EXYNOS_CPUFREQ becomes tristate, all the remaining
continues bool. And we add the following Makefile change to your patch

---
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0f9a2c3..c3c3cf5 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -26,13 +26,19 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 
 
 config ARM_EXYNOS_CPUFREQ
-   bool
+   tristate SAMSUNG EXYNOS CPUfreq Driver
+   depends on THERMAL
+   default y
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS platforms
+
+ If in doubt, say N.
 
 config ARM_EXYNOS4210_CPUFREQ
bool SAMSUNG EXYNOS4210
depends on CPU_EXYNOS4210
+   depends on ARM_EXYNOS_CPUFREQ
default y
-   select ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS4210
  SoC (S5PV310 or S5PC210).
@@ -42,8 +48,8 @@ config ARM_EXYNOS4210_CPUFREQ
 config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
+   depends on ARM_EXYNOS_CPUFREQ
default y
-   select ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS4X12
  SoC (EXYNOS4212 or EXYNOS4412).
@@ -54,7 +60,7 @@ config ARM_EXYNOS5250_CPUFREQ
bool SAMSUNG EXYNOS5250
depends on SOC_EXYNOS5250
default y
-   select ARM_EXYNOS_CPUFREQ
+   depends on ARM_EXYNOS_CPUFREQ
help
  This adds the CPUFreq driver for Samsung EXYNOS5250
  SoC.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b3ca7b0..b26e2bf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,10 +51,11 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += 
arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o

Re: [PATCH] thermal: Kconfig: Remove config for not used EXYNOS_THERMAL_CORE

[Eduardo Valentin]

On Tue, Jan 27, 2015 at 12:13:59PM +0100, Lukasz Majewski wrote:
 After removing exynos_thermal_common.[c|h] files the CONFIG_EXYNOS_THERMA_CORE
 is not needed anymore.
 This patch removes this entry from Kconfig.
 
 Reported-by: Paul Bolle pebo...@tiscali.nl
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

This patch looks fine to me and I am about to queue it in my fixes tree.
However, you must carry along another patch to remove this entry:
arch/arm/configs/exynos_defconfig:CONFIG_EXYNOS_THERMAL_CORE=y

Can you please post it and ask Kim to queue the above suggested removal
too?

 ---
  drivers/thermal/samsung/Kconfig | 9 -
  1 file changed, 9 deletions(-)
 
 diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
 index c43306e..c8e35c1 100644
 --- a/drivers/thermal/samsung/Kconfig
 +++ b/drivers/thermal/samsung/Kconfig
 @@ -7,12 +7,3 @@ config EXYNOS_THERMAL
 the TMU, reports temperature and handles cooling action if defined.
 This driver uses the Exynos core thermal APIs and TMU configuration
 data from the supported SoCs.
 -
 -config EXYNOS_THERMAL_CORE
 - bool Core thermal framework support for EXYNOS SOCs
 - 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 APIs.
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v4 00/17] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

| 106 -
drivers/thermal/samsung/exynos_tmu.c   | 354
+++--
drivers/thermal/samsung/exynos_tmu.h   |  68 +---
drivers/thermal/samsung/exynos_tmu_data.c  | 264
- include/dt-bindings/thermal/thermal_exynos.h   |
28 ++ 26 files changed, 638 insertions(+), 1001 deletions(-) create
mode 100644 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi create mode
100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi create
mode 100644 arch/arm/boot/dts/exynos5420-trip-points.dtsi create
mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
create mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.c create
mode 100644 include/dt-bindings/thermal/thermal_exynos.h
   
--
  
   I hope will apply DT changes in Samsung tree. Is it OK to thermal
   tree?
  
  I think that it is up to you and Eduardo to decide :-).
  
  I'd personally prefer to add this patch set at once to Eduardo's tree
  (of course with your ACKs).
  
 If so, we could see too many useless merge conflicts. Because your patches
 touch most of exynos DT stuff and that's why DT changes should be handled in
 Samsung tree if there is no problem ;) Let's wait for thermal guys.

Let's target the latest version (v6) of this series. You can add my
Acked-by: Eduardo Valentin edubez...@gmail.com

in the DTS changes. And add them via your tree. I believe we will avoid
merge conflicts this way. I will handle the patches touching drivers/.

Thanks.

 
 - Kukjin
 


signature.asc
Description: Digital signature

Re: [PATCH v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Wed, Jan 21, 2015 at 09:10:15AM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Thu, Jan 15, 2015 at 04:17:52PM +0100, Lukasz Majewski wrote:
   Hi Eduardo,
   
On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
 This patch brings support for providing configuration via device
 tree. Previously this data has been hardcoded in the
 exynos_tmu_data.c file. Such approach was not scalable and very
 often required copying the whole data.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Adjust exynos_tmu.c code to the newest ti-soc-thermal
 repository
 - Usage of of-thermal.c exported trip points table
 Changes for v3:
 - Adding exynos_of_get_soc_type() method to set SOC type from
 device's compatible string
 - samsung,tmu_ prefix for TMU specific properties has been
 added
 
 ---
  drivers/thermal/samsung/Makefile |   2 -
  drivers/thermal/samsung/exynos_tmu.c | 345
 +++
 drivers/thermal/samsung/exynos_tmu.h |  53 +- 3 files
 changed, 226 insertions(+), 174 deletions(-)
 
 diff --git a/drivers/thermal/samsung/Makefile
 b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,5 +3,3 @@
  #
  obj-$(CONFIG_EXYNOS_THERMAL) +=
 exynos_thermal.o
 exynos_thermal-y  := exynos_tmu.o
 -exynos_thermal-y +=
 exynos_tmu_data.o

Can this makefile change be part of the patch that removes
exynos_tmu_data.c?

 -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
 exynos_thermal_common.o

Can this makefile change be part of the patch that removes
exynos_thermal_common.c?
   
   Unfortunately, this code cannot be moved to the next patch, in
   which I remove the files, since this causes build break of the
   series.
   
   The code structure as is, provides working, bisectable thermal
   solution - thermal and cpu_cooling functionality is preserved across
   all commits in the series.
  
  My concern here is simply that this specific commit is leaving unused
  files in the tree.
  
  One option would be to remove the files altogether in this specific
  commit.
 
 Is is really necessary?
 
 This patch itself changes around 400 LOC. Those changes __are__
 important and in my opinion deserve their own commit.
 
 When I squash following patches, which remove old exynos files, we
 would have around 1.2K LOC in a single commit.
 
 I think that current approach is far more readable. 

I agree that separating is far more readable. However, the commit leaves
zombie files.

 
 Eduardo, is there a chance for this series (the newest version is v5 -
 which include Ablibash comments) to be included to yours -next tree
 before v3.19 is out?

Yes, we can target this. I have sent couple of minor comments on v5.
Despite them, there are also some parts of this series that are supposed
to be merged via other trees. The cpufreq part seams to be too little
and Viresh has already flagged that I can merge it as long it is in a
separated patch. However, most part of this series touches arch/arm
directory and those should go via your platform tree. Is there a change
you could either as your Exynos maintainer to queue the patches touching
arch/arm or ask him if he is fine if I merge them via my tree?

Cheers,

 
  
   

 diff --git a/drivers/thermal/samsung/exynos_tmu.c
 b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..633a9e2
 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -1,6 +1,10 @@
  /*
   * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
   *
 + *  Copyright (C) 2014 Samsung Electronics
 + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 + *  Lukasz Majewski l.majew...@samsung.com
 + *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com
   *  Amit Daniel Kachhap amit.kach...@linaro.org
 @@ -31,8 +35,8 @@
  #include linux/platform_device.h
  #include linux/regulator/consumer.h
  
 -#include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include ../thermal_core.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -115,6 +119,7 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
  
 +#define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private
 data of the TMU driver
 @@ -150,7 +155,8 @@ struct exynos_tmu_data {
   struct clk *clk, *clk_sec;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
 - struct 

Re: [PATCH v3 00/16] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

On Thu, Jan 22, 2015 at 02:06:10AM +0100, Tobias Jakobi wrote:
 Hello!
 
 
 Lukasz Majewski wrote:
  The point is that I'm still working with a rather old version of the
  cpufreq series, a version which still had the Exynos4x12 code in it
  (this was removed later, if I remember correctly because of problems
  with how to properly describe boost configuration in DT).
  
  Is your board Odroid-U3/Trats2 ?
 It's an Odroid-X2, so pretty similar to the U3, except that it doesn't
 have any active cooling device.
 
 
  Anyway, to not get completly off-topic here, I noticed some small
  issue with v3 of the thermal series. I've enabled
  CONFIG_THERMAL_HWMON so that I can use lm_sensors to query
  temperature of the board. However while the thermal_zone is created,
  there is no hwmon node to be found. 
  
  I'm not surprised, that some use cases (about which I wasn't even
  aware) show up. 
  I've already fixed issues reported by Abhilash (with v5 and a following
  patch) and look closer into the THERMAL_HWMON.
 The problem seems to be that of_parse_thermal_zones always sets
 'no_hwmon' to true, so that thermal_zone_device_register never registers
 a hwmon device when the underlaying thermal zone is setup through DT. I
 don't understand the rationale behind this, even with the comment ('No
 hwmon because there might be hwmon drivers registering').
 

The reason is that hwmon sensor device drivers also register via of-thermal.
So, adding hwmon interface by default will create a cyclic problem.

Cheers,

 
  I've also done some work regarding FAN controlled by hwmon for Odroid
  U3.
  Could you look on following series:
  http://www.spinics.net/lists/linux-samsung-soc/msg40471.html
  
  I can only guess that your board might need similar entries for your
  DTS file(s).
 
 Like I said, the X2 only has a passive heatsink, so no fan controlling here.
 
 
 With best wishes,
 Tobias
 


signature.asc
Description: Digital signature

Re: [PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Wed, Jan 21, 2015 at 09:40:55AM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Mon, Jan 19, 2015 at 12:20:59PM +0100, Lukasz Majewski wrote:
   This patch brings support for providing configuration via device
   tree. Previously this data has been hardcoded in the
   exynos_tmu_data.c file. Such approach was not scalable and very
   often required copying the whole data.
   
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
   Changes for v2:
   - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
   - Usage of of-thermal.c exported trip points table
   Changes for v3:
   - Adding exynos_of_get_soc_type() method to set SOC type from
   device's compatible string
   - samsung,tmu_ prefix for TMU specific properties has been added
   Changes for v4:
   - None
   Changes for v5:
   - Remove duplicated exynos_tmu_initialize() - reported by Abhilash
   Kesavan a.kesa...@samsung.com
   
  
  several checkpatch.pl items to be reviewed in this patch:
  CHECK: No space is necessary after a cast
  #509: FILE: drivers/thermal/samsung/exynos_tmu.c:821:
  +   pdata-gain = (u8) value;
  
  CHECK: No space is necessary after a cast
  #511: FILE: drivers/thermal/samsung/exynos_tmu.c:823:
  +   pdata-reference_voltage = (u8) value;
  
  
  Can you please make sure all of your patches pass:
  checkpatch.pl --strict
 
 ` ^ Is now checkpatch.pl required to run with
 --strict rule? 
 
 I've tested those patches only with checkpatch with no errors.
 
 Has kernel policy changed recently? Are all developers now obliged to
 use the --strict rule?

no change in policy. the --strict is just appreciated. it depends on
maintainer to maintainer. --strict catches more checks and warnings
though. that is probably why I see people asking for it.

 
 
  
  ?
  
  
   ---
drivers/thermal/samsung/Makefile |   2 -
drivers/thermal/samsung/exynos_tmu.c | 339
   ++-
   drivers/thermal/samsung/exynos_tmu.h |  53 +- 3 files changed,
   220 insertions(+), 174 deletions(-)
   
   diff --git a/drivers/thermal/samsung/Makefile
   b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
   --- a/drivers/thermal/samsung/Makefile
   +++ b/drivers/thermal/samsung/Makefile
   @@ -3,5 +3,3 @@
#
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 ae30f6a..9d2d685
   100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++
   b/drivers/thermal/samsung/exynos_tmu.c @@ -1,6 +1,10 @@ /*
 * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
 *
   + *  Copyright (C) 2014 Samsung Electronics
   + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
   + *  Lukasz Majewski l.majew...@samsung.com
   + *
 *  Copyright (C) 2011 Samsung Electronics
 *  Donggeun Kim dg77@samsung.com
 *  Amit Daniel Kachhap amit.kach...@linaro.org
   @@ -31,8 +35,8 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h

   -#include exynos_thermal_common.h
#include exynos_tmu.h
   +#include ../thermal_core.h

/* Exynos generic registers */
#define EXYNOS_TMU_REG_TRIMINFO  0x0
   @@ -115,6 +119,7 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8

   +#define MCELSIUS 1000
/**
 * struct exynos_tmu_data : A structure to hold the private data
   of the TMU driver
   @@ -150,7 +155,8 @@ struct exynos_tmu_data {
 struct clk *clk, *clk_sec;
 u8 temp_error1, temp_error2;
 struct regulator *regulator;
   - struct thermal_sensor_conf *reg_conf;
   + struct thermal_zone_device *tzd;
   +
 int (*tmu_initialize)(struct platform_device *pdev);
 void (*tmu_control)(struct platform_device *pdev, bool on);
 int (*tmu_read)(struct exynos_tmu_data *data);
   @@ -159,6 +165,33 @@ struct exynos_tmu_data {
 void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
};

   +static void exynos_report_trigger(struct exynos_tmu_data *p)
   +{
   + char data[10], *envp[] = { data, NULL };
   + struct thermal_zone_device *tz = p-tzd;
   + unsigned long temp;
   + unsigned int i;
   +
   + if (!p) {
   + pr_err(Wrong temperature configuration data\n);
   + return;
   + }
   +
   + thermal_zone_device_update(tz);
   +
   + mutex_lock(tz-lock);
   + /* Find the level for which trip happened */
   + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
   + tz-ops-get_trip_temp(tz, i, temp);
   + if (tz-last_temperature  temp)
   + break;
   + }
   +
   + snprintf(data, sizeof(data), %u, i);
   + kobject_uevent_env(tz-device.kobj, 

Re: [PATCH v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Thu, Jan 15, 2015 at 04:17:52PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
   This patch brings support for providing configuration via device
   tree. Previously this data has been hardcoded in the
   exynos_tmu_data.c file. Such approach was not scalable and very
   often required copying the whole data.
   
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
   Changes for v2:
   - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
   - Usage of of-thermal.c exported trip points table
   Changes for v3:
   - Adding exynos_of_get_soc_type() method to set SOC type from
   device's compatible string
   - samsung,tmu_ prefix for TMU specific properties has been added
   
   ---
drivers/thermal/samsung/Makefile |   2 -
drivers/thermal/samsung/exynos_tmu.c | 345
   +++
   drivers/thermal/samsung/exynos_tmu.h |  53 +- 3 files changed,
   226 insertions(+), 174 deletions(-)
   
   diff --git a/drivers/thermal/samsung/Makefile
   b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
   --- a/drivers/thermal/samsung/Makefile
   +++ b/drivers/thermal/samsung/Makefile
   @@ -3,5 +3,3 @@
#
obj-$(CONFIG_EXYNOS_THERMAL) +=
   exynos_thermal.o exynos_thermal-y :=
   exynos_tmu.o -exynos_thermal-y+=
   exynos_tmu_data.o
  
  Can this makefile change be part of the patch that removes
  exynos_tmu_data.c?
  
   -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
   exynos_thermal_common.o
  
  Can this makefile change be part of the patch that removes
  exynos_thermal_common.c?
 
 Unfortunately, this code cannot be moved to the next patch, in which I
 remove the files, since this causes build break of the series.
 
 The code structure as is, provides working, bisectable thermal
 solution - thermal and cpu_cooling functionality is preserved across
 all commits in the series.

My concern here is simply that this specific commit is leaving unused files in 
the tree.

One option would be to remove the files altogether in this specific
commit.

 
  
   diff --git a/drivers/thermal/samsung/exynos_tmu.c
   b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..633a9e2 100644
   --- a/drivers/thermal/samsung/exynos_tmu.c
   +++ b/drivers/thermal/samsung/exynos_tmu.c
   @@ -1,6 +1,10 @@
/*
 * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
 *
   + *  Copyright (C) 2014 Samsung Electronics
   + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
   + *  Lukasz Majewski l.majew...@samsung.com
   + *
 *  Copyright (C) 2011 Samsung Electronics
 *  Donggeun Kim dg77@samsung.com
 *  Amit Daniel Kachhap amit.kach...@linaro.org
   @@ -31,8 +35,8 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h

   -#include exynos_thermal_common.h
#include exynos_tmu.h
   +#include ../thermal_core.h

/* Exynos generic registers */
#define EXYNOS_TMU_REG_TRIMINFO  0x0
   @@ -115,6 +119,7 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8

   +#define MCELSIUS 1000
/**
 * struct exynos_tmu_data : A structure to hold the private data
   of the TMU driver
   @@ -150,7 +155,8 @@ struct exynos_tmu_data {
 struct clk *clk, *clk_sec;
 u8 temp_error1, temp_error2;
 struct regulator *regulator;
   - struct thermal_sensor_conf *reg_conf;
   + struct thermal_zone_device *tzd;
   +
 int (*tmu_initialize)(struct platform_device *pdev);
 void (*tmu_control)(struct platform_device *pdev, bool on);
 int (*tmu_read)(struct exynos_tmu_data *data);
   @@ -159,6 +165,33 @@ struct exynos_tmu_data {
 void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
};

   +static void exynos_report_trigger(struct exynos_tmu_data *p)
   +{
   + char data[10], *envp[] = { data, NULL };
   + struct thermal_zone_device *tz = p-tzd;
   + unsigned long temp;
   + unsigned int i;
   +
   + if (!p) {
   + pr_err(Wrong temperature configuration data\n);
   + return;
   + }
   +
   + thermal_zone_device_update(tz);
   +
   + mutex_lock(tz-lock);
   + /* Find the level for which trip happened */
   + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
   + tz-ops-get_trip_temp(tz, i, temp);
   + if (tz-last_temperature  temp)
   + break;
   + }
   +
   + snprintf(data, sizeof(data), %u, i);
   + kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
   + mutex_unlock(tz-lock);
   +}
   +
/*
 * TMU treats temperature as a mapped temperature code.
 * The temperature is converted differently depending on the
   calibration type. @@ -234,14 +267,25 @@ static void
   sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info) 
static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold,
   

Re: [PATCH v5 00/18] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

Hello Arnd,

On Mon, Jan 19, 2015 at 12:20:44PM +0100, Lukasz Majewski wrote:
 1. Introduction
 
 Following patches aim to clean up the current implementation of the thermal
 framework on Exynos devices.
 
 The main goal was to use a generic code for reading thermal configuration
 (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files
 were removed.
 
 Around 400 lines of code (LOC) were removed directly by this patch, which
 is around 20% of the Exynos thermal code base.
 
 This work should NOT bring any functional changes to Exynos thermal 
 subsystem.
 
 2. Patch-set structure
 
 Then the cpu_cooling functionality has been preserved to allow cooling
 devices by reducing operating frequency. Definition of trip points and
 cpufreq's cooling properties were moved to device tree.
 
 Then the rework of the way in which configuration data is provided to
 the Exynos thermal subsystem was performed. Now device tree is used for
 configuration.
 
 3. Dead code removal
 
 Thermal support for some SoCs, previously available in the exynos_tmu_data.c 
 file, was removed since, as of (almost) 3.19-rc3, they didn't have TMU 
 bindings.
 
 Moreover, support for cpu_cooling devices was preserved only on those
 SoCs which had available and working cpufreq driver.
 
 4. Testing
 
 Test devices:
 - Exynos4210 - Trats (TMU zone + cpu_cooling)
 - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling)
 - Exynos5250 - Arndale (TMU zone + cpu_cooling)
 - Exynos5420 - Arndale-octa (only TMU zones)
 
 Unfortunately, I don't posses Exynos5440 for testing. Its functionality
 has been preserved in the code, but not tested on the hardware. I would
 be grateful for help in testing.
 
 
 5. This work apply on the following tree:
 
 kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree
 SHA1: 1813d80874699145f04af6b05ebab0a6419001fb
 
 

This series contains changes under drivers/thermal that I can pick up,
but it also contains changes under arch/arm/boot/dts that depend on a
header file provided by the driver. The header is introduced in this
series.

How do you prefer to preceed in such sitation? Are you OK if I pick the
complete series, changes under drivers/thermal and the DTS changes?

Cheers,

Eduardo

 Lukasz Majewski (18):
   thermal: exynos: cosmetic: Correct comment format
   thermal: exynos: Provide thermal_exynos.h file to be included in
 device tree files
   arm: dts: trats: Enable TMU on the Exynos4210 trats device
   arm: dts: odroid: Add LDO10 regulator node necessary for TMU on Odroid
   arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 device
   arm: dts: Adding CPU cooling binding for Exynos SoCs
   thermal: exynos: Modify exynos thermal code to use device tree for cpu
 cooling configuration
   thermal: exynos: dts: Add default definition of the TMU sensor
 parameter
   dts: Documentation: Extending documentation entry for exynos-thermal
   thermal: dts: Default trip points definition for Exynos5420 SoCs
   thermal: exynos: dts: Define default thermal-zones for Exynos4
   thermal: dts: exynos: Trip points and sensor configuration data for
 Exynos5440
   dts: Documentation: Update exynos-thermal.txt example for Exynos5440
   thermal: exynos: dts: Provide device tree bindings identical to the
 one in exynos_tmu_data.c
   thermal: samsung: core: Exynos TMU rework to use device tree for
 configuration
   thermal: exynos: Remove exynos_thermal_common.[c|h] files
   thermal: exynos: Remove exynos_tmu_data.c file
   thermal: exynos: Remove not needed exynos_tmu_init_data declarations
 from exynos_tmu.h
 
  .../devicetree/bindings/thermal/exynos-thermal.txt |  17 +
  arch/arm/boot/dts/exynos3250.dtsi  |   2 +
  arch/arm/boot/dts/exynos4-cpu-thermal.dtsi |  52 +++
  arch/arm/boot/dts/exynos4.dtsi |   4 +
  arch/arm/boot/dts/exynos4210-trats.dts |  19 +
  arch/arm/boot/dts/exynos4210.dtsi  |  30 +-
  arch/arm/boot/dts/exynos4212.dtsi  |   5 +-
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  27 ++
  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi  |  24 ++
  arch/arm/boot/dts/exynos4412-trats2.dts|  15 +
  arch/arm/boot/dts/exynos4412.dtsi  |   5 +-
  arch/arm/boot/dts/exynos4x12.dtsi  |   1 +
  arch/arm/boot/dts/exynos5250.dtsi  |  29 +-
  arch/arm/boot/dts/exynos5420-trip-points.dtsi  |  35 ++
  arch/arm/boot/dts/exynos5420.dtsi  |  28 ++
  arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi  |  24 ++
  arch/arm/boot/dts/exynos5440-trip-points.dtsi  |  25 ++
  arch/arm/boot/dts/exynos5440.dtsi  |  18 +
  drivers/cpufreq/exynos-cpufreq.c   |  30 +-
  drivers/thermal/samsung/Makefile   |   2 -
  drivers/thermal/samsung/exynos_thermal_common.c| 427 
 -
  drivers/thermal/samsung/exynos_thermal_common.h| 106 -
  

Re: [PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Mon, Jan 19, 2015 at 12:20:59PM +0100, Lukasz Majewski wrote:
 This patch brings support for providing configuration via device tree.
 Previously this data has been hardcoded in the exynos_tmu_data.c file.
 Such approach was not scalable and very often required copying the whole
 data.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
 - Usage of of-thermal.c exported trip points table
 Changes for v3:
 - Adding exynos_of_get_soc_type() method to set SOC type from device's
   compatible string
 - samsung,tmu_ prefix for TMU specific properties has been added
 Changes for v4:
 - None
 Changes for v5:
 - Remove duplicated exynos_tmu_initialize() - reported by Abhilash Kesavan
  a.kesa...@samsung.com
 

several checkpatch.pl items to be reviewed in this patch:
CHECK: No space is necessary after a cast
#509: FILE: drivers/thermal/samsung/exynos_tmu.c:821:
+   pdata-gain = (u8) value;

CHECK: No space is necessary after a cast
#511: FILE: drivers/thermal/samsung/exynos_tmu.c:823:
+   pdata-reference_voltage = (u8) value;


Can you please make sure all of your patches pass:
checkpatch.pl --strict

?


 ---
  drivers/thermal/samsung/Makefile |   2 -
  drivers/thermal/samsung/exynos_tmu.c | 339 
 ++-
  drivers/thermal/samsung/exynos_tmu.h |  53 +-
  3 files changed, 220 insertions(+), 174 deletions(-)
 
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index c09d830..1e47d0d 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,5 +3,3 @@
  #
  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 ae30f6a..9d2d685 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -1,6 +1,10 @@
  /*
   * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
   *
 + *  Copyright (C) 2014 Samsung Electronics
 + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 + *  Lukasz Majewski l.majew...@samsung.com
 + *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com
   *  Amit Daniel Kachhap amit.kach...@linaro.org
 @@ -31,8 +35,8 @@
  #include linux/platform_device.h
  #include linux/regulator/consumer.h
  
 -#include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include ../thermal_core.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -115,6 +119,7 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
  
 +#define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of the TMU
   driver
 @@ -150,7 +155,8 @@ struct exynos_tmu_data {
   struct clk *clk, *clk_sec;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
 - struct thermal_sensor_conf *reg_conf;
 + struct thermal_zone_device *tzd;
 +
   int (*tmu_initialize)(struct platform_device *pdev);
   void (*tmu_control)(struct platform_device *pdev, bool on);
   int (*tmu_read)(struct exynos_tmu_data *data);
 @@ -159,6 +165,33 @@ struct exynos_tmu_data {
   void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
  };
  
 +static void exynos_report_trigger(struct exynos_tmu_data *p)
 +{
 + char data[10], *envp[] = { data, NULL };
 + struct thermal_zone_device *tz = p-tzd;
 + unsigned long temp;
 + unsigned int i;
 +
 + if (!p) {
 + pr_err(Wrong temperature configuration data\n);
 + return;
 + }
 +
 + thermal_zone_device_update(tz);
 +
 + mutex_lock(tz-lock);
 + /* Find the level for which trip happened */
 + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
 + tz-ops-get_trip_temp(tz, i, temp);
 + if (tz-last_temperature  temp)
 + break;
 + }
 +
 + snprintf(data, sizeof(data), %u, i);
 + kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
 + mutex_unlock(tz-lock);
 +}
 +
  /*
   * TMU treats temperature as a mapped temperature code.
   * The temperature is converted differently depending on the calibration 
 type.
 @@ -234,14 +267,25 @@ static void sanitize_temp_error(struct exynos_tmu_data 
 *data, u32 trim_info)
  
  static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold, bool 
 falling)
  {
 - struct exynos_tmu_platform_data *pdata = data-pdata;
 + struct thermal_zone_device *tz = data-tzd;
 + const struct thermal_trip * const trips =
 + of_thermal_get_trip_points(tz);
 + unsigned long temp;
   int i;
  
 - for 

Re: [PATCH v5 18/18] thermal: exynos: Remove not needed exynos_tmu_init_data declarations from exynos_tmu.h

[Eduardo Valentin]

On Mon, Jan 19, 2015 at 12:21:02PM +0100, Lukasz Majewski wrote:
 After switching to device tree based configuration those declarations are
 not needed anymore.
 
 Reported-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v5:
 - New patch
 ---
  drivers/thermal/samsung/exynos_tmu.h | 8 
  1 file changed, 8 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.h 
 b/drivers/thermal/samsung/exynos_tmu.h
 index d876d4c..9f9b1b8 100644
 --- a/drivers/thermal/samsung/exynos_tmu.h
 +++ b/drivers/thermal/samsung/exynos_tmu.h
 @@ -71,12 +71,4 @@ struct exynos_tmu_platform_data {
   u32 cal_mode;
  };
  
 -extern struct exynos_tmu_init_data const exynos3250_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos4412_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos5250_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos5260_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos5420_default_tmu_data;
 -extern struct exynos_tmu_init_data const exynos5440_default_tmu_data;

Please merge this patch to the one that removes these symbols from
kernel.

 -
  #endif /* _EXYNOS_TMU_H */
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration

[Eduardo Valentin]

On Mon, Jan 19, 2015 at 12:20:51PM +0100, Lukasz Majewski wrote:
 Up till now exynos_tmu_data.c was used for storing CPU cooling configuration
 data. Now the Exynos thermal core code uses device tree to get this data.
 For this purpose generic thermal code for configuring CPU cooling was
 used.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 Changes for v3:
 - Rewrite code responsible for registering CPU cooling device to not depend
   on explicit /cpus/cpu@0 path since now Exynos SoCs use new cpu node
   names (e.g. cpu@A00). New approach iterates over cpus node children.
 - Patch title changed to thermal: exynos
 Changes for v4:
 - None
 Changes for v5:
 - None
 
 ---
  drivers/cpufreq/exynos-cpufreq.c|  30 +-
  drivers/thermal/samsung/exynos_thermal_common.c | 122 
 ++--
  drivers/thermal/samsung/exynos_tmu.c|   7 --
  drivers/thermal/samsung/exynos_tmu.h|   5 -
  drivers/thermal/samsung/exynos_tmu_data.c   |  42 +---
  5 files changed, 101 insertions(+), 105 deletions(-)
 
 diff --git a/drivers/cpufreq/exynos-cpufreq.c 
 b/drivers/cpufreq/exynos-cpufreq.c
 index f99a0b0..32bc64d 100644
 --- a/drivers/cpufreq/exynos-cpufreq.c
 +++ b/drivers/cpufreq/exynos-cpufreq.c
 @@ -18,10 +18,13 @@
  #include linux/cpufreq.h
  #include linux/platform_device.h
  #include linux/of.h
 +#include linux/cpu_cooling.h
 +#include linux/cpu.h
  
  #include exynos-cpufreq.h
  
  static struct exynos_dvfs_info *exynos_info;
 +static struct thermal_cooling_device *cdev;
  static struct regulator *arm_regulator;
  static unsigned int locking_frequency;
  
 @@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
  
  static int exynos_cpufreq_probe(struct platform_device *pdev)
  {
 + struct device_node *cpus, *np;
   int ret = -EINVAL;
  
   exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
 @@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct platform_device 
 *pdev)
   /* Done here as we want to capture boot frequency */
   locking_frequency = clk_get_rate(exynos_info-cpu_clk) / 1000;
  
 - if (!cpufreq_register_driver(exynos_driver))
 - return 0;
 + if (cpufreq_register_driver(exynos_driver))
 + goto err;
  
 + cpus = of_find_node_by_path(/cpus);
 + if (!cpus) {
 + pr_err(failed to find cpus node\n);
 + return -ENOENT;
 + }
 +
 + for (np = of_get_next_child(cpus, NULL); np;
 +  of_node_put(np), np = of_get_next_child(cpus, np)) {
 + 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));
 + break;
 + }
 + }
 + of_node_put(np);
 + of_node_put(cpus);
 +
 + return 0;
 + err:
   dev_err(pdev-dev, failed to register cpufreq driver\n);
   regulator_put(arm_regulator);
  err_vdd_arm:

You need at least an ack from a cpufreq maintainer to get this patch in.
I would prefer if you split the cpufreq part from the thermal part. It
avoids merge conflicts in the upstreaming process.

 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 6dc3815..00aa688 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -133,47 +133,62 @@ static int exynos_get_crit_temp(struct 
 thermal_zone_device *thermal,
  static int exynos_bind(struct thermal_zone_device *thermal,
   struct thermal_cooling_device *cdev)
  {
 - 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;
 + struct device_node *child, *gchild, *np;
 + struct of_phandle_args cooling_spec;
 + unsigned long max, state = 0;
 + int ret = 0, i = 0;
  
 - tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
 - tab_size = data-cooling_data.freq_clip_count;
 -
 - if (tab_ptr == NULL || tab_size == 0)
 + /*
 +  * Below code is necessary to skip binding when cpufreq's
 +  * frequency table is not yet initialized.
 +  */
 + cdev-ops-get_max_state(cdev, state);
 + if (!state  !th_zone-cool_dev_size) {
 + th_zone-cool_dev_size = 1;
 + th_zone-cool_dev[0] = cdev;
 + th_zone-bind = false;
   return 0;
 + }
  
 - /* find the cooling device registered*/
 - for (i = 0; i  th_zone-cool_dev_size; i++)
 - if (cdev == th_zone-cool_dev[i])
 - 

Re: [PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Mon, Jan 19, 2015 at 12:20:59PM +0100, Lukasz Majewski wrote:
 This patch brings support for providing configuration via device tree.
 Previously this data has been hardcoded in the exynos_tmu_data.c file.
 Such approach was not scalable and very often required copying the whole
 data.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
 - Usage of of-thermal.c exported trip points table
 Changes for v3:
 - Adding exynos_of_get_soc_type() method to set SOC type from device's
   compatible string
 - samsung,tmu_ prefix for TMU specific properties has been added
 Changes for v4:
 - None
 Changes for v5:
 - Remove duplicated exynos_tmu_initialize() - reported by Abhilash Kesavan
  a.kesa...@samsung.com
 
 ---
  drivers/thermal/samsung/Makefile |   2 -
  drivers/thermal/samsung/exynos_tmu.c | 339 
 ++-
  drivers/thermal/samsung/exynos_tmu.h |  53 +-
  3 files changed, 220 insertions(+), 174 deletions(-)
 
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index c09d830..1e47d0d 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,5 +3,3 @@
  #
  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 ae30f6a..9d2d685 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -1,6 +1,10 @@
  /*
   * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
   *
 + *  Copyright (C) 2014 Samsung Electronics
 + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 + *  Lukasz Majewski l.majew...@samsung.com
 + *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com
   *  Amit Daniel Kachhap amit.kach...@linaro.org
 @@ -31,8 +35,8 @@
  #include linux/platform_device.h
  #include linux/regulator/consumer.h
  
 -#include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include ../thermal_core.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -115,6 +119,7 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
  
 +#define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of the TMU
   driver
 @@ -150,7 +155,8 @@ struct exynos_tmu_data {
   struct clk *clk, *clk_sec;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
 - struct thermal_sensor_conf *reg_conf;
 + struct thermal_zone_device *tzd;
 +
   int (*tmu_initialize)(struct platform_device *pdev);
   void (*tmu_control)(struct platform_device *pdev, bool on);
   int (*tmu_read)(struct exynos_tmu_data *data);
 @@ -159,6 +165,33 @@ struct exynos_tmu_data {
   void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
  };
  
 +static void exynos_report_trigger(struct exynos_tmu_data *p)
 +{
 + char data[10], *envp[] = { data, NULL };
 + struct thermal_zone_device *tz = p-tzd;
 + unsigned long temp;
 + unsigned int i;
 +
 + if (!p) {
 + pr_err(Wrong temperature configuration data\n);
 + return;
 + }
 +
 + thermal_zone_device_update(tz);
 +
 + mutex_lock(tz-lock);
 + /* Find the level for which trip happened */
 + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
 + tz-ops-get_trip_temp(tz, i, temp);
 + if (tz-last_temperature  temp)
 + break;
 + }
 +
 + snprintf(data, sizeof(data), %u, i);
 + kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
 + mutex_unlock(tz-lock);
 +}
 +
  /*
   * TMU treats temperature as a mapped temperature code.
   * The temperature is converted differently depending on the calibration 
 type.
 @@ -234,14 +267,25 @@ static void sanitize_temp_error(struct exynos_tmu_data 
 *data, u32 trim_info)
  
  static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold, bool 
 falling)
  {
 - struct exynos_tmu_platform_data *pdata = data-pdata;
 + struct thermal_zone_device *tz = data-tzd;
 + const struct thermal_trip * const trips =
 + of_thermal_get_trip_points(tz);
 + unsigned long temp;
   int i;
  
 - for (i = 0; i  pdata-non_hw_trigger_levels; i++) {
 - u8 temp = pdata-trigger_levels[i];
 + if (!trips) {
 + pr_err(%s: Cannot get trip points from of-thermal.c!\n,
 +__func__);
 + return 0;
 + }
  
 + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
 + if (trips[i].type == THERMAL_TRIP_CRITICAL)
 + continue;
 +
 + 

Re: [PATCH v3 06/16] arm: dts: Adding CPU cooling binding for Exynos SoCs

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:41:04PM +0100, Lukasz Majewski wrote:
 Presented patch aims to move data necessary for correct CPU cooling device
 configuration from exynos_tmu_data.c to device tree.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 Changes for v3:
 - Adjust CPU's DT nodes to work with newest ti-soc-thermal/next branch
 - Patch title has been changed from thermal: cpu_cooling: dts: ...
 ---
  arch/arm/boot/dts/exynos4210-trats.dts  | 15 +++
  arch/arm/boot/dts/exynos4210.dtsi   |  5 -
  arch/arm/boot/dts/exynos4212.dtsi   |  5 -
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 +++
  arch/arm/boot/dts/exynos4412-trats2.dts | 15 +++
  arch/arm/boot/dts/exynos4412.dtsi   |  5 -
  arch/arm/boot/dts/exynos5250.dtsi   | 20 +++-
  7 files changed, 76 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
 b/arch/arm/boot/dts/exynos4210-trats.dts
 index 61009f4..4cd8926 100644
 --- a/arch/arm/boot/dts/exynos4210-trats.dts
 +++ b/arch/arm/boot/dts/exynos4210-trats.dts
 @@ -428,6 +428,21 @@
   status = okay;
   };
  
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 + /* Corresponds to 800MHz at freq_table */
 + cooling-device = cpu0 2 2;
 + };
 + map1 {
 +/* Corresponds to 200MHz at freq_table */
 +cooling-device = cpu0 4 4;
 +};
 +};
 + };

The cpu_thermal zone above is incomplete. It is missing the following
mandatory properties (according to
Documentation/devicetree/bindings/thermal/thermal.txt):
- polling-delay: 
- polling-delay-passive:
- thermal-sensors:
- trips: 

 + };
 +
   camera {
   pinctrl-names = default;
   pinctrl-0 = ;
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index bcc9e63..2e66df8 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -35,10 +35,13 @@
   #address-cells = 1;
   #size-cells = 0;
  
 - cpu@900 {
 + cpu0: cpu@900 {
   device_type = cpu;
   compatible = arm,cortex-a9;
   reg = 0x900;
 + cooling-min-level = 4;
 + cooling-max-level = 2;
 + #cooling-cells = 2; /* min followed by max */
   };
  
   cpu@901 {
 diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
 b/arch/arm/boot/dts/exynos4212.dtsi
 index dd0a43e..5be03288 100644
 --- a/arch/arm/boot/dts/exynos4212.dtsi
 +++ b/arch/arm/boot/dts/exynos4212.dtsi
 @@ -26,10 +26,13 @@
   #address-cells = 1;
   #size-cells = 0;
  
 - cpu@A00 {
 + cpu0: cpu@A00 {
   device_type = cpu;
   compatible = arm,cortex-a9;
   reg = 0xA00;
 + cooling-min-level = 13;
 + cooling-max-level = 7;
 + #cooling-cells = 2; /* min followed by max */
   };
  
   cpu@A01 {
 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index c7517fc..4838a2a 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -401,6 +401,21 @@
   vtmu-supply = ldo10_reg;
   status = okay;
   };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 + /* Corresponds to 800MHz at freq_table */
 + cooling-device = cpu0 7 7;
 + };
 + map1 {
 +/* Corresponds to 200MHz at freq_table */
 +cooling-device = cpu0 13 13;
 +};
 +};
 + };
 + };
  };
  
  pinctrl_1 {
 diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
 b/arch/arm/boot/dts/exynos4412-trats2.dts
 index 29231b4..8c2c584 100644
 --- a/arch/arm/boot/dts/exynos4412-trats2.dts
 +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
 @@ -863,6 +863,21 @@
   pulldown-ohm = 10; /* 100K */
   io-channels = adc 2;  /* Battery temperature */
   };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 + 

Re: [PATCH v3 13/16] thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:41:11PM +0100, Lukasz Majewski wrote:
 Presented device tree bindings provide data already hardcoded in the
 exynos_tmu_data.c file.
 After this commit, it should be possible to reuse common thermal core
 framework in Exynos SoCs.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Add proper TMU entries for exynos3250.dtsi
 Changes for v3:
 - Remove type DT properties, which will be extracted from compatible
 - samsung,tmu_ prefix for TMU specific properties has been added
 
 ---
  arch/arm/boot/dts/exynos3250.dtsi |  2 ++
  arch/arm/boot/dts/exynos4.dtsi|  4 
  arch/arm/boot/dts/exynos4210.dtsi | 21 -
  arch/arm/boot/dts/exynos4x12.dtsi |  1 +
  arch/arm/boot/dts/exynos5250.dtsi |  5 +++--
  arch/arm/boot/dts/exynos5420.dtsi | 28 
  arch/arm/boot/dts/exynos5440.dtsi | 18 ++
  7 files changed, 76 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 2246549..8cc078c 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -18,6 +18,7 @@
   */
  
  #include skeleton.dtsi
 +#include exynos4-cpu-thermal.dtsi
  #include dt-bindings/clock/exynos3250.h
  
  / {
 @@ -188,6 +189,7 @@
   interrupts = 0 216 0;
   clocks = cmu CLK_TMU_APBIF;
   clock-names = tmu_apbif;
 + #include exynos4412-tmu-sensor-conf.dtsi
   status = disabled;
   };
  
 diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
 index b8168f1..f18d746 100644
 --- a/arch/arm/boot/dts/exynos4.dtsi
 +++ b/arch/arm/boot/dts/exynos4.dtsi
 @@ -645,4 +645,8 @@
   samsung,sysreg = sys_reg;
   status = disabled;
   };
 +
 + tmu: tmu@100C {
 + #include exynos4412-tmu-sensor-conf.dtsi
 + };
  };
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index 2e66df8..7f0e012 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -21,6 +21,7 @@
  
  #include exynos4.dtsi
  #include exynos4210-pinctrl.dtsi
 +#include exynos4-cpu-thermal.dtsi
  
  / {
   compatible = samsung,exynos4210, samsung,exynos4;
 @@ -146,16 +147,34 @@
   reg = 0x0386 0x1000;
   };
  
 - tmu@100C {
 + tmu: tmu@100C {
   compatible = samsung,exynos4210-tmu;
   interrupt-parent = combiner;
   reg = 0x100C 0x100;
   interrupts = 2 4;
   clocks = clock CLK_TMU_APBIF;
   clock-names = tmu_apbif;
 + samsung,tmu_gain = 15;
 + samsung,tmu_reference_voltage = 7;
   status = disabled;
   };
  
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + trips {
 +   cpu_alert0: cpu-alert-0 {
 +   temperature = 85000; /* millicelsius */
 +   };
 +   cpu_alert1: cpu-alert-1 {
 +   temperature = 10; /* millicelsius */
 +   };
 +   cpu_alert2: cpu-alert-2 {
 +   temperature = 11; /* millicelsius */
 +   };
 + };
 + };
 + };
 +
   g2d@1280 {
   compatible = samsung,s5pv210-g2d;
   reg = 0x1280 0x1000;
 diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
 b/arch/arm/boot/dts/exynos4x12.dtsi
 index 93b7040..3ee2031 100644
 --- a/arch/arm/boot/dts/exynos4x12.dtsi
 +++ b/arch/arm/boot/dts/exynos4x12.dtsi
 @@ -19,6 +19,7 @@
  
  #include exynos4.dtsi
  #include exynos4x12-pinctrl.dtsi
 +#include exynos4-cpu-thermal.dtsi
  
  / {
   aliases {
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index dd5c3a0..07fd73a 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -20,7 +20,7 @@
  #include dt-bindings/clock/exynos5250.h
  #include exynos5.dtsi
  #include exynos5250-pinctrl.dtsi
 -
 +#include exynos4-cpu-thermal.dtsi
  #include dt-bindings/clock/exynos-audss-clk.h
  
  / {
 @@ -236,12 +236,13 @@
   status = disabled;
   };
  
 - tmu@1006 {
 + tmu: tmu@1006 {
   compatible = samsung,exynos5250-tmu;
   reg = 0x1006 0x100;
   interrupts = 0 65 0;
   clocks = clock CLK_TMU;
   clock-names = tmu_apbif;
 + #include exynos4412-tmu-sensor-conf.dtsi
   };
  
   thermal-zones {
 diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
 b/arch/arm/boot/dts/exynos5420.dtsi
 index 517e50f..f5771e5 100644
 --- a/arch/arm/boot/dts/exynos5420.dtsi
 +++ 

Re: [PATCH v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
 This patch brings support for providing configuration via device tree.
 Previously this data has been hardcoded in the exynos_tmu_data.c file.
 Such approach was not scalable and very often required copying the whole
 data.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
 - Usage of of-thermal.c exported trip points table
 Changes for v3:
 - Adding exynos_of_get_soc_type() method to set SOC type from device's
   compatible string
 - samsung,tmu_ prefix for TMU specific properties has been added
 
 ---
  drivers/thermal/samsung/Makefile |   2 -
  drivers/thermal/samsung/exynos_tmu.c | 345 
 +++
  drivers/thermal/samsung/exynos_tmu.h |  53 +-
  3 files changed, 226 insertions(+), 174 deletions(-)
 
 diff --git a/drivers/thermal/samsung/Makefile 
 b/drivers/thermal/samsung/Makefile
 index c09d830..1e47d0d 100644
 --- a/drivers/thermal/samsung/Makefile
 +++ b/drivers/thermal/samsung/Makefile
 @@ -3,5 +3,3 @@
  #
  obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
  exynos_thermal-y := exynos_tmu.o
 -exynos_thermal-y += exynos_tmu_data.o

Can this makefile change be part of the patch that removes
exynos_tmu_data.c?

 -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o

Can this makefile change be part of the patch that removes
exynos_thermal_common.c?

 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index ae30f6a..633a9e2 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -1,6 +1,10 @@
  /*
   * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
   *
 + *  Copyright (C) 2014 Samsung Electronics
 + *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 + *  Lukasz Majewski l.majew...@samsung.com
 + *
   *  Copyright (C) 2011 Samsung Electronics
   *  Donggeun Kim dg77@samsung.com
   *  Amit Daniel Kachhap amit.kach...@linaro.org
 @@ -31,8 +35,8 @@
  #include linux/platform_device.h
  #include linux/regulator/consumer.h
  
 -#include exynos_thermal_common.h
  #include exynos_tmu.h
 +#include ../thermal_core.h
  
  /* Exynos generic registers */
  #define EXYNOS_TMU_REG_TRIMINFO  0x0
 @@ -115,6 +119,7 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
  
 +#define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of the TMU
   driver
 @@ -150,7 +155,8 @@ struct exynos_tmu_data {
   struct clk *clk, *clk_sec;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
 - struct thermal_sensor_conf *reg_conf;
 + struct thermal_zone_device *tzd;
 +
   int (*tmu_initialize)(struct platform_device *pdev);
   void (*tmu_control)(struct platform_device *pdev, bool on);
   int (*tmu_read)(struct exynos_tmu_data *data);
 @@ -159,6 +165,33 @@ struct exynos_tmu_data {
   void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
  };
  
 +static void exynos_report_trigger(struct exynos_tmu_data *p)
 +{
 + char data[10], *envp[] = { data, NULL };
 + struct thermal_zone_device *tz = p-tzd;
 + unsigned long temp;
 + unsigned int i;
 +
 + if (!p) {
 + pr_err(Wrong temperature configuration data\n);
 + return;
 + }
 +
 + thermal_zone_device_update(tz);
 +
 + mutex_lock(tz-lock);
 + /* Find the level for which trip happened */
 + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
 + tz-ops-get_trip_temp(tz, i, temp);
 + if (tz-last_temperature  temp)
 + break;
 + }
 +
 + snprintf(data, sizeof(data), %u, i);
 + kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
 + mutex_unlock(tz-lock);
 +}
 +
  /*
   * TMU treats temperature as a mapped temperature code.
   * The temperature is converted differently depending on the calibration 
 type.
 @@ -234,14 +267,25 @@ static void sanitize_temp_error(struct exynos_tmu_data 
 *data, u32 trim_info)
  
  static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold, bool 
 falling)
  {
 - struct exynos_tmu_platform_data *pdata = data-pdata;
 + struct thermal_zone_device *tz = data-tzd;
 + const struct thermal_trip * const trips =
 + of_thermal_get_trip_points(tz);
 + unsigned long temp;
   int i;
  
 - for (i = 0; i  pdata-non_hw_trigger_levels; i++) {
 - u8 temp = pdata-trigger_levels[i];
 + if (!trips) {
 + pr_err(%s: Cannot get trip points from of-thermal.c!\n,
 +__func__);
 + return 0;
 + }
 +
 + for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
 + if (trips[i].type == THERMAL_TRIP_CRITICAL)
 + 

Re: [PATCH v3 09/16] dts: Documentation: Extending documentation entry for exynos-thermal

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:41:07PM +0100, Lukasz Majewski wrote:
 Properties necessary for providing Exynos thermal configuration via device
 tree.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v3:
 - New patch
 
 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt  | 17 
 +
  1 file changed, 17 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index ae738f5..0f44932 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -39,6 +39,18 @@
  - 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.
 +Following properties are mandatory (depending on SoC):
 +- samsung,tmu_gain: Gain value for internal TMU operation.
 +- samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
 +- samsung,tmu_noise_cancel_mode: Mode for noise cancellation
 +- samsung,tmu_efuse_value: Default level of temperature - it is needed when
 +in factory fusing produced wrong value
 +- samsung,tmu_min_efuse_value: Minimum temperature fused value
 +- samsung,tmu_max_efuse_value: Maximum temperature fused value
 +- samsung,tmu_first_point_trim: First point trimming value
 +- samsung,tmu_second_point_trim: Second point trimming value
 +- samsung,tmu_default_temp_offset: Default temperature offset
 +- samsung,tmu_cal_type: Callibration type
  
  Example 1):
  
 @@ -51,6 +63,7 @@ Example 1):
   clock-names = tmu_apbif;
   status = disabled;
   vtmu-supply = tmu_regulator_node;
 + #include exynos4412-tmu-sensor-conf.dtsi
   };
  
  Example 2):
 @@ -61,6 +74,7 @@ Example 2):
   interrupts = 0 58 0;
   clocks = clock 21;
   clock-names = tmu_apbif;
 + #include exynos5440-tmu-sensor-conf.dtsi

Did I miss something or at this point the above file does not exist yet?

Please make sure each commit / patch is in a compilable/usable/working
state.

   };
  
  Example 3): (In case of Exynos5420 with misplaced TRIMINFO register)
 @@ -70,6 +84,7 @@ Example 3): (In case of Exynos5420 with misplaced TRIMINFO 
 register)
   interrupts = 0 184 0;
   clocks = clock 318, clock 318;
   clock-names = tmu_apbif, tmu_triminfo_apbif;
 + #include exynos4412-tmu-sensor-conf.dtsi
   };
  
   tmu_cpu3: tmu@1006c000 {
 @@ -78,6 +93,7 @@ Example 3): (In case of Exynos5420 with misplaced TRIMINFO 
 register)
   interrupts = 0 185 0;
   clocks = clock 318, clock 319;
   clock-names = tmu_apbif, tmu_triminfo_apbif;
 + #include exynos4412-tmu-sensor-conf.dtsi
   };
  
   tmu_gpu: tmu@100a {
 @@ -86,6 +102,7 @@ Example 3): (In case of Exynos5420 with misplaced 
 TRIMINFO register)
   interrupts = 0 215 0;
   clocks = clock 319, clock 318;
   clock-names = tmu_apbif, tmu_triminfo_apbif;
 + #include exynos4412-tmu-sensor-conf.dtsi
   };
  
  Note: For multi-instance tmu each instance should have an alias correctly
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v3 09/16] dts: Documentation: Extending documentation entry for exynos-thermal

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:52:25PM -0400, Eduardo Valentin wrote:
 On Wed, Jan 14, 2015 at 02:41:07PM +0100, Lukasz Majewski wrote:
  Properties necessary for providing Exynos thermal configuration via device
  tree.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  ---
  Changes for v3:
  - New patch
  
  ---
   .../devicetree/bindings/thermal/exynos-thermal.txt  | 17 
  +
   1 file changed, 17 insertions(+)
  
  diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
  b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  index ae738f5..0f44932 100644
  --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  @@ -39,6 +39,18 @@
   - 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.
  +Following properties are mandatory (depending on SoC):
  +- samsung,tmu_gain: Gain value for internal TMU operation.
  +- samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
  +- samsung,tmu_noise_cancel_mode: Mode for noise cancellation
  +- samsung,tmu_efuse_value: Default level of temperature - it is needed when
  +  in factory fusing produced wrong value
  +- samsung,tmu_min_efuse_value: Minimum temperature fused value
  +- samsung,tmu_max_efuse_value: Maximum temperature fused value
  +- samsung,tmu_first_point_trim: First point trimming value
  +- samsung,tmu_second_point_trim: Second point trimming value
  +- samsung,tmu_default_temp_offset: Default temperature offset
  +- samsung,tmu_cal_type: Callibration type
   
   Example 1):
   
  @@ -51,6 +63,7 @@ Example 1):
  clock-names = tmu_apbif;
  status = disabled;
  vtmu-supply = tmu_regulator_node;
  +   #include exynos4412-tmu-sensor-conf.dtsi
  };
   
   Example 2):
  @@ -61,6 +74,7 @@ Example 2):
  interrupts = 0 58 0;
  clocks = clock 21;
  clock-names = tmu_apbif;
  +   #include exynos5440-tmu-sensor-conf.dtsi
 
 Did I miss something or at this point the above file does not exist yet?
 
 Please make sure each commit / patch is in a compilable/usable/working
 state.

I know this is a Documentation file, but the comment above still
applies.

 
  };
   
   Example 3): (In case of Exynos5420 with misplaced TRIMINFO register)
  @@ -70,6 +84,7 @@ Example 3): (In case of Exynos5420 with misplaced 
  TRIMINFO register)
  interrupts = 0 184 0;
  clocks = clock 318, clock 318;
  clock-names = tmu_apbif, tmu_triminfo_apbif;
  +   #include exynos4412-tmu-sensor-conf.dtsi
  };
   
  tmu_cpu3: tmu@1006c000 {
  @@ -78,6 +93,7 @@ Example 3): (In case of Exynos5420 with misplaced 
  TRIMINFO register)
  interrupts = 0 185 0;
  clocks = clock 318, clock 319;
  clock-names = tmu_apbif, tmu_triminfo_apbif;
  +   #include exynos4412-tmu-sensor-conf.dtsi
  };
   
  tmu_gpu: tmu@100a {
  @@ -86,6 +102,7 @@ Example 3): (In case of Exynos5420 with misplaced 
  TRIMINFO register)
  interrupts = 0 215 0;
  clocks = clock 319, clock 318;
  clock-names = tmu_apbif, tmu_triminfo_apbif;
  +   #include exynos4412-tmu-sensor-conf.dtsi
  };
   
   Note: For multi-instance tmu each instance should have an alias correctly
  -- 
  2.0.0.rc2
  




signature.asc
Description: Digital signature

Re: [PATCH v3 05/16] thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 02:41:03PM +0100, Lukasz Majewski wrote:
 This commit enables TMU IP block on the Exynos4412 Odroid U3
 device.
 

The comment about the patch subject applies here too. I would use arm:
dts: ... instead of thermal: dts 

 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 Changes for v3:
 - None
 ---
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index 0adb57c..c7517fc 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -396,6 +396,11 @@
   ehci: ehci@1258 {
   status = okay;
   };
 +
 + tmu@100C {
 + vtmu-supply = ldo10_reg;
 + status = okay;
 + };
  };
  
  pinctrl_1 {
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Wed, Jan 14, 2015 at 04:01:06PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
   On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
Odroid U3 fan can work without being registered as OF cooling
device (with CONFIG_THERMAL_OF disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.

Therefore, the thermal_of_cooling_device_register() function
needs a stub to allow clean compilation.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   
   Acked-by: Eduardo Valentin edubez...@gmail.com
  
  Sorry, too fast,
  
  This is actually
  Nacked-by: Eduardo Valentin edubez...@gmail.com
  
  :-)
  
  I get this error:
  drivers/thermal/thermal_core.c:1210:1: error: redefinition of
  ‘thermal_of_cooling_device_register’
   thermal_of_cooling_device_register(struct device_node *np,
^
In file included from drivers/thermal/thermal_core.c:34:0:
include/linux/thermal.h:321:1: note: previous definition of
‘thermal_of_cooling_device_register’ was here
 thermal_of_cooling_device_register(struct device_node *np,
  ^
  
  
  We provide the function in thermal core even if CONFIG_THERMAL_OF is
  not set.
 
 Unfortunately the PWM fan subsystem can work perfectly fine without
 CONFIG_THERMAL.
 

Now I understand what you are trying to do.

 I think that it would be enough to make something like this in
 the ./include/linux/thermal.h:
 
 #ifdef CONFIG_THERMAL
Well, I think it should be the opposite here:

#ifndef CONFIG_THERMAL

that is, if no config thermal, then you provide the stub not the other
way around.

   static inline struct thermal_cooling_device *
   thermal_of_cooling_device_register(struct device_node
   *np, char *type, void *devdata,
  const struct
   thermal_cooling_device_ops *ops) {
   return NULL;
   }
 #else
   [ already present declaration of
   thermal_of_cooling_device_register() ]
 #endif /* CONFIG_THERMAL */


 
 
 
   
---
Changes for v2:
- None
---
 include/linux/thermal.h | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 2de3d9e..871123c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct
device *dev, int id, void *data, const struct
thermal_zone_of_device_ops *ops); void
thermal_zone_of_sensor_unregister(struct device *dev, struct
thermal_zone_device *tz); +struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+  char *type, void *devdata,
+  const struct
thermal_cooling_device_ops *); #else
 static inline struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int id, void
*data, @@ -342,6 +346,13 @@ void
thermal_zone_of_sensor_unregister(struct device *dev, {
 }
 
+static inline struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+  char *type, void *devdata,
+  const struct
thermal_cooling_device_ops *ops) +{
+   return NULL;
+}
 #endif
 struct thermal_zone_device *thermal_zone_device_register(const
char *, int, int, void *, struct thermal_zone_device_ops *,
@@ -357,9 +368,6 @@ void thermal_zone_device_update(struct
thermal_zone_device *); 
 struct thermal_cooling_device
*thermal_cooling_device_register(char *, void *, const struct
thermal_cooling_device_ops *); -struct thermal_cooling_device *
-thermal_of_cooling_device_register(struct device_node *np, char
*, void *,
-  const struct
thermal_cooling_device_ops *); void
thermal_cooling_device_unregister(struct thermal_cooling_device
*); struct thermal_zone_device
*thermal_zone_get_zone_by_name(const char *name); int
thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
long *temp); -- 2.0.0.rc2

  
  
 
 
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH v2 06/17] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality

[Eduardo Valentin]

On Mon, Jan 12, 2015 at 03:09:16PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
   Presented patch aims to move data necessary for correct CPU cooling
   device configuration from exynos_tmu_data.c to device tree.  
  
  I believe the patch title is misleading. Looks like you are changing
  something at cpu cooling, but in fact, you are changing DTS files. I
  would suggest you to use a prefix like 'arm: dts: '
 
 Now this patch name is:
 thermal: cpu_cooling: dts: ..
 
 All the code in this patch adds bindings for 'thermal-zone' to map
 cooling device to proper trip points.
 In fact this is solely related to cpu_cooling...
 
 From the above, I think that the already provided convention is more
 suitable and arm: dts: cpu_cooling: thermal seems a bit awkward for
 me.
 
 If you don't regard my justification as valid, then I will fix this.

Still, the naming is confusing. With that prefix you are saying this
patch is something generic about cpu cooling and thermal dts. And that
is not what this patch is about.

Saying arm: dts: add cpu cooling bindings for Exynos is a short and
direct subject. Besides, you have the plus to call the attention of the
ARM and device tree maintainers. It will be also in my radar.


The original subject also makes me think you are dealing with C code,
while the former says already upfront that you are talking about arm dts
bindings. 

Cheers,
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

Hi,

On Sat, Jan 03, 2015 at 08:53:45PM +0100, Lukasz Majewski wrote:

cut 
  

  Apologize for late answer.
 
 I will be able to address your comments no sooner than next Monday.
 Moreover I still believe that we will manage to add this code to your
 -next branch :-)

Good! Take your time.

Cheers,

Eduardo Valentin

 
  
  Cheers,
  
  Eduardo Valentin.
 
 Best regards,
 Lukasz Majewski




signature.asc
Description: Digital signature

Re: [PATCH v2 12/17] thermal: exynos: dts: Provide device tree bindings identical to one in exynos_tmu_data.c

[Eduardo Valentin]

Lukasz

On Wed, Dec 10, 2014 at 01:09:51PM +0100, Lukasz Majewski wrote:
 Presented device tree bindings provide data already hardcoded in the
 exynos_tmu_data.c file.
 After this commit, it should be possible to reuse common thermal core
 framework in Exynos SoCs.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Add proper TMU entries for exynos3250.dtsi
 ---
  arch/arm/boot/dts/exynos3250.dtsi |  4 
  arch/arm/boot/dts/exynos4.dtsi|  5 +
  arch/arm/boot/dts/exynos4210.dtsi | 23 ++-
  arch/arm/boot/dts/exynos4x12.dtsi |  3 +++
  arch/arm/boot/dts/exynos5250.dtsi |  7 +--
  arch/arm/boot/dts/exynos5420.dtsi | 33 +
  arch/arm/boot/dts/exynos5440.dtsi | 18 ++
  7 files changed, 90 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 693a327..6edfa76 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -18,7 +18,9 @@
   */
  
  #include skeleton.dtsi
 +#include exynos4-cpu-thermal.dtsi
  #include dt-bindings/clock/exynos3250.h
 +#include dt-bindings/thermal/thermal_exynos.h
  
  / {
   compatible = samsung,exynos3250;
 @@ -188,6 +190,8 @@
   interrupts = 0 216 0;
   clocks = cmu CLK_TMU_APBIF;
   clock-names = tmu_apbif;
 + type = SOC_ARCH_EXYNOS3250;

Why do we need a 'type' property here? Can't we reuse compatible?

 + #include exynos4412-tmu-sensor-conf.dtsi
   status = disabled;
   };
  
 diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
 index e0278ec..1735bb3 100644
 --- a/arch/arm/boot/dts/exynos4.dtsi
 +++ b/arch/arm/boot/dts/exynos4.dtsi
 @@ -21,6 +21,7 @@
  
  #include dt-bindings/clock/exynos4.h
  #include dt-bindings/clock/exynos-audss-clk.h
 +#include dt-bindings/thermal/thermal_exynos.h
  #include skeleton.dtsi
  
  / {
 @@ -645,4 +646,8 @@
   samsung,sysreg = sys_reg;
   status = disabled;
   };
 +
 + tmu: tmu@100C {
 + #include exynos4412-tmu-sensor-conf.dtsi
 + };
  };
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index 10e8915..1c52681 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -21,6 +21,8 @@
  
  #include exynos4.dtsi
  #include exynos4210-pinctrl.dtsi
 +#include exynos4-cpu-thermal.dtsi
 +#include dt-bindings/thermal/thermal_exynos.h
  
  / {
   compatible = samsung,exynos4210, samsung,exynos4;
 @@ -146,16 +148,35 @@
   reg = 0x0386 0x1000;
   };
  
 - tmu@100C {
 + tmu: tmu@100C {
   compatible = samsung,exynos4210-tmu;
   interrupt-parent = combiner;
   reg = 0x100C 0x100;
   interrupts = 2 4;
   clocks = clock CLK_TMU_APBIF;
   clock-names = tmu_apbif;
 + gain = 15;
 + reference_voltage = 7;
 + type = SOC_ARCH_EXYNOS4210;
   status = disabled;
   };
  
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + trips {
 +   cpu_alert0: cpu-alert-0 {
 +   temperature = 85000; /* millicelsius */
 +   };
 +   cpu_alert1: cpu-alert-1 {
 +   temperature = 10; /* millicelsius */
 +   };
 +   cpu_alert2: cpu-alert-2 {
 +   temperature = 11; /* millicelsius */
 +   };
 + };
 + };
 + };
 +
   g2d@1280 {
   compatible = samsung,s5pv210-g2d;
   reg = 0x1280 0x1000;
 diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
 b/arch/arm/boot/dts/exynos4x12.dtsi
 index 2e9f1f7..ee24d83 100644
 --- a/arch/arm/boot/dts/exynos4x12.dtsi
 +++ b/arch/arm/boot/dts/exynos4x12.dtsi
 @@ -19,6 +19,8 @@
  
  #include exynos4.dtsi
  #include exynos4x12-pinctrl.dtsi
 +#include exynos4-cpu-thermal.dtsi
 +#include dt-bindings/thermal/thermal_exynos.h
  
  / {
   aliases {
 @@ -279,6 +281,7 @@
   reg = 0x100C 0x100;
   clocks = clock 383;
   clock-names = tmu_apbif;
 + type = SOC_ARCH_EXYNOS4412;
   status = disabled;
   };
  };
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index a5bbc1a..2167394 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -20,8 +20,9 @@
  #include dt-bindings/clock/exynos5250.h
  #include exynos5.dtsi
  #include exynos5250-pinctrl.dtsi
 -
 +#include exynos4-cpu-thermal.dtsi
  #include 

Re: [PATCH v2 06/17] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality

[Eduardo Valentin]

On Wed, Dec 10, 2014 at 01:09:45PM +0100, Lukasz Majewski wrote:
 Presented patch aims to move data necessary for correct CPU cooling device
 configuration from exynos_tmu_data.c to device tree.

I believe the patch title is misleading. Looks like you are changing
something at cpu cooling, but in fact, you are changing DTS files. I
would suggest you to use a prefix like 'arm: dts: '

 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 ---
  arch/arm/boot/dts/exynos4210-trats.dts  | 15 
  arch/arm/boot/dts/exynos4210.dtsi   | 20 
  arch/arm/boot/dts/exynos4212.dtsi   | 20 
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 
  arch/arm/boot/dts/exynos4412-trats2.dts | 15 
  arch/arm/boot/dts/exynos4412.dtsi   | 32 
 +
  arch/arm/boot/dts/exynos5250.dtsi   | 20 +++-
  7 files changed, 136 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
 b/arch/arm/boot/dts/exynos4210-trats.dts
 index b59019c..d9dd9a7 100644
 --- a/arch/arm/boot/dts/exynos4210-trats.dts
 +++ b/arch/arm/boot/dts/exynos4210-trats.dts
 @@ -428,6 +428,21 @@
   status = okay;
   };
  
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 + /* Corresponds to 800MHz at freq_table */
 + cooling-device = cpu0 2 2;
 + };
 + map1 {
 +/* Corresponds to 200MHz at freq_table */
 +cooling-device = cpu0 4 4;
 +};
 +};
 + };
 + };
 +
   camera {
   pinctrl-names = default;
   pinctrl-0 = ;
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index 807bb5b..10e8915 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -41,6 +41,26 @@
   #clock-cells = 1;
   };
  
 + cpus {
 + #address-cells = 1;
 + #size-cells = 0;
 +
 + cpu0: cpu@0 {
 + device_type = cpu;
 + compatible = arm,cortex-a9;
 + reg = 0x900;
 + cooling-min-level = 4;
 + cooling-max-level = 2;
 + #cooling-cells = 2; /* min followed by max */
 + };
 +
 + cpu@1 {
 + device_type = cpu;
 + compatible = arm,cortex-a9;
 + reg = 0x901;
 + };
 + };
 +
   sysram@0202 {
   compatible = mmio-sram;
   reg = 0x0202 0x2;
 diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
 b/arch/arm/boot/dts/exynos4212.dtsi
 index 3c00e6e..6405954 100644
 --- a/arch/arm/boot/dts/exynos4212.dtsi
 +++ b/arch/arm/boot/dts/exynos4212.dtsi
 @@ -22,6 +22,26 @@
  / {
   compatible = samsung,exynos4212, samsung,exynos4;
  
 + cpus {
 + #address-cells = 1;
 + #size-cells = 0;
 +
 + cpu0: cpu@0 {
 + device_type = cpu;
 + compatible = arm,cortex-a9;
 + reg = 0xA00;
 + cooling-min-level = 13;
 + cooling-max-level = 7;
 + #cooling-cells = 2; /* min followed by max */
 + };
 +
 + cpu@1 {
 + device_type = cpu;
 + compatible = arm,cortex-a9;
 + reg = 0xA01;
 + };
 + };
 +
   combiner: interrupt-controller@1044 {
   samsung,combiner-nr = 18;
   };
 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index eb1c08c..15d45f0 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -375,6 +375,21 @@
   vtmu-supply = ldo10_reg;
   status = okay;
   };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 + /* Corresponds to 800MHz at freq_table */
 + cooling-device = cpu0 7 7;
 + };
 + map1 {
 +/* Corresponds to 200MHz at freq_table */
 +cooling-device = cpu0 13 13;
 +};
 +};
 + };
 + };
  };
  
  pinctrl_1 {
 diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
 

Re: [PATCH v2 08/17] thermal: exynos: dts: Add default definition of the TMU sensor parameter

[Eduardo Valentin]

Lukasz,

On Wed, Dec 10, 2014 at 01:09:47PM +0100, Lukasz Majewski wrote:
 Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure the
 on chip temperature. For this reason it is possible to group TMU configuration
 parameters in one dts file.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 ---
  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 
 +++
  1 file changed, 24 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
 
 diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi 
 b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
 new file mode 100644
 index 000..ee6d8bb
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
 @@ -0,0 +1,24 @@
 +/*
 + * Device tree sources for Exynos4412 TMU sensor configuration
 + *
 + * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + */
 +
 +#include dt-bindings/thermal/thermal_exynos.h
 +
 +#thermal-sensor-cells = 0;
 +gain = 8;
 +reference_voltage = 16;
 +noise_cancel_mode = 4;
 +efuse_value = 55;
 +min_efuse_value = 40;
 +max_efuse_value = 100;
 +first_point_trim = 25;
 +second_point_trim = 85;
 +default_temp_offset = 50;
 +cal_type = TYPE_ONE_POINT_TRIMMING;

Are the above properties specific to exynos? For specific DT entries,
they need to be marked with a prefix. Please read the 'Device Specific
Data' section of Device tree Documentation [1].

[1] - http://devicetree.org/Device_Tree_Usage
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

 work moving data out of your driver. Impressed.

I sent out a couple of comments, most are minor. Major part is on
duplication of of-thermal parser.

  create mode 100644 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
  create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5420-trip-points.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi

good stuff here too. Only concern is regarding 'type' property (possible
to reuse compatible) and exynos specific data.

  delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
  delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
  delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
  create mode 100644 include/dt-bindings/thermal/thermal_exynos.h
 
 -- 
 2.0.0.rc2
 

Apologize for late answer.

Cheers,

Eduardo Valentin.


signature.asc
Description: Digital signature

Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
 On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
  Odroid U3 fan can work without being registered as OF cooling device
  (with CONFIG_THERMAL_OF disabled).
  In this situation it can be controlled via PWM entry at
  /sys/class/hwmon/hwmon0/pwm1.
  
  Therefore, the thermal_of_cooling_device_register() function needs a stub
  to allow clean compilation.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 
 Acked-by: Eduardo Valentin edubez...@gmail.com

Sorry, too fast,

This is actually
Nacked-by: Eduardo Valentin edubez...@gmail.com

:-)

I get this error:
drivers/thermal/thermal_core.c:1210:1: error: redefinition of
‘thermal_of_cooling_device_register’
 thermal_of_cooling_device_register(struct device_node *np,
  ^
  In file included from drivers/thermal/thermal_core.c:34:0:
  include/linux/thermal.h:321:1: note: previous definition of
  ‘thermal_of_cooling_device_register’ was here
   thermal_of_cooling_device_register(struct device_node *np,
^


We provide the function in thermal core even if CONFIG_THERMAL_OF is not
set.
 
  ---
  Changes for v2:
  - None
  ---
   include/linux/thermal.h | 14 +++---
   1 file changed, 11 insertions(+), 3 deletions(-)
  
  diff --git a/include/linux/thermal.h b/include/linux/thermal.h
  index 2de3d9e..871123c 100644
  --- a/include/linux/thermal.h
  +++ b/include/linux/thermal.h
  @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct device *dev, 
  int id, void *data,
  const struct thermal_zone_of_device_ops *ops);
   void thermal_zone_of_sensor_unregister(struct device *dev,
 struct thermal_zone_device *tz);
  +struct thermal_cooling_device *
  +thermal_of_cooling_device_register(struct device_node *np,
  +  char *type, void *devdata,
  +  const struct thermal_cooling_device_ops *);
   #else
   static inline struct thermal_zone_device *
   thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
  @@ -342,6 +346,13 @@ void thermal_zone_of_sensor_unregister(struct device 
  *dev,
   {
   }
   
  +static inline struct thermal_cooling_device *
  +thermal_of_cooling_device_register(struct device_node *np,
  +  char *type, void *devdata,
  +  const struct thermal_cooling_device_ops *ops)
  +{
  +   return NULL;
  +}
   #endif
   struct thermal_zone_device *thermal_zone_device_register(const char *, 
  int, int,
  void *, struct thermal_zone_device_ops *,
  @@ -357,9 +368,6 @@ void thermal_zone_device_update(struct 
  thermal_zone_device *);
   
   struct thermal_cooling_device *thermal_cooling_device_register(char *, 
  void *,
  const struct thermal_cooling_device_ops *);
  -struct thermal_cooling_device *
  -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
  -  const struct thermal_cooling_device_ops *);
   void thermal_cooling_device_unregister(struct thermal_cooling_device *);
   struct thermal_zone_device *thermal_zone_get_zone_by_name(const char 
  *name);
   int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
  *temp);
  -- 
  2.0.0.rc2
  




signature.asc
Description: Digital signature

Re: [PATCH v2 08/17] thermal: exynos: dts: Add default definition of the TMU sensor parameter

[Eduardo Valentin]

On Fri, Jan 02, 2015 at 02:11:41PM -0400, Eduardo Valentin wrote:
 Lukasz,
 
 On Wed, Dec 10, 2014 at 01:09:47PM +0100, Lukasz Majewski wrote:
  Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure 
  the
  on chip temperature. For this reason it is possible to group TMU 
  configuration
  parameters in one dts file.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  ---
  Changes for v2:
  - None
  ---
   arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 
  +++
   1 file changed, 24 insertions(+)
   create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
  
  diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi 
  b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
  new file mode 100644
  index 000..ee6d8bb
  --- /dev/null
  +++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
  @@ -0,0 +1,24 @@
  +/*
  + * Device tree sources for Exynos4412 TMU sensor configuration
  + *
  + * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + *
  + */
  +
  +#include dt-bindings/thermal/thermal_exynos.h
  +
  +#thermal-sensor-cells = 0;
  +gain = 8;
  +reference_voltage = 16;
  +noise_cancel_mode = 4;
  +efuse_value = 55;
  +min_efuse_value = 40;
  +max_efuse_value = 100;
  +first_point_trim = 25;
  +second_point_trim = 85;
  +default_temp_offset = 50;
  +cal_type = TYPE_ONE_POINT_TRIMMING;
 
 Are the above properties specific to exynos? For specific DT entries,
 they need to be marked with a prefix. Please read the 'Device Specific
 Data' section of Device tree Documentation [1].
 
 [1] - http://devicetree.org/Device_Tree_Usage


BTW, you have to update:
Documentation/devicetree/bindings/thermal/exynos-thermal.txt


  -- 
  2.0.0.rc2
  




signature.asc
Description: Digital signature

Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
 Odroid U3 fan can work without being registered as OF cooling device
 (with CONFIG_THERMAL_OF disabled).
 In this situation it can be controlled via PWM entry at
 /sys/class/hwmon/hwmon0/pwm1.
 
 Therefore, the thermal_of_cooling_device_register() function needs a stub
 to allow clean compilation.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com

Acked-by: Eduardo Valentin edubez...@gmail.com

 ---
 Changes for v2:
 - None
 ---
  include/linux/thermal.h | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)
 
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 2de3d9e..871123c 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct device *dev, int 
 id, void *data,
   const struct thermal_zone_of_device_ops *ops);
  void thermal_zone_of_sensor_unregister(struct device *dev,
  struct thermal_zone_device *tz);
 +struct thermal_cooling_device *
 +thermal_of_cooling_device_register(struct device_node *np,
 +char *type, void *devdata,
 +const struct thermal_cooling_device_ops *);
  #else
  static inline struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
 @@ -342,6 +346,13 @@ void thermal_zone_of_sensor_unregister(struct device 
 *dev,
  {
  }
  
 +static inline struct thermal_cooling_device *
 +thermal_of_cooling_device_register(struct device_node *np,
 +char *type, void *devdata,
 +const struct thermal_cooling_device_ops *ops)
 +{
 + return NULL;
 +}
  #endif
  struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
 int,
   void *, struct thermal_zone_device_ops *,
 @@ -357,9 +368,6 @@ void thermal_zone_device_update(struct 
 thermal_zone_device *);
  
  struct thermal_cooling_device *thermal_cooling_device_register(char *, void 
 *,
   const struct thermal_cooling_device_ops *);
 -struct thermal_cooling_device *
 -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
 -const struct thermal_cooling_device_ops *);
  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
  struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
  int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
 *temp);
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 2/8] thermal: Provide stub for thermal_cdev_update() function

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:42PM +0100, Lukasz Majewski wrote:
 Odroid U3 fan can work without being registered as OF cooling device
 (with CONFIG_THERMAL_OF disabled).
 In this situation it can be controlled via PWM entry at
 /sys/class/hwmon/hwmon0/pwm1.
 
 Therefore, the thermal_cdev_update() function needs a stub
 to allow clean compilation.

I am not sure I understand what you are attempting to do here. What is
the relation that you see between CONFIG_OF_THERMAL and
thermal_cdev_update? 

 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - New patch
 ---
  include/linux/thermal.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 871123c..b3515b5 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -332,6 +332,7 @@ struct thermal_cooling_device *
  thermal_of_cooling_device_register(struct device_node *np,
  char *type, void *devdata,
  const struct thermal_cooling_device_ops *);
 +void thermal_cdev_update(struct thermal_cooling_device *);
  #else
  static inline struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
 @@ -353,6 +354,10 @@ thermal_of_cooling_device_register(struct device_node 
 *np,
  {
   return NULL;
  }
 +
 +static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
 +{
 +}
  #endif
  struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
 int,
   void *, struct thermal_zone_device_ops *,
 @@ -375,7 +380,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
 unsigned long *temp);
  int get_tz_trend(struct thermal_zone_device *, int);
  struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
   struct thermal_cooling_device *, int);
 -void thermal_cdev_update(struct thermal_cooling_device *);
  void thermal_notify_framework(struct thermal_zone_device *, int);
  
  #ifdef CONFIG_NET
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 3/8] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:43PM +0100, Lukasz Majewski wrote:
 Several new properties to allow PWM fan working as a cooling device have been
 combined into this single commit.
 

Patch prefix should look something like 'dt-bindings: ...', or better
'Documentation: devicetree: ...', or 'Documentation: bindings: ...'

 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Rename cooling-pwm-values to cooling-levels
 - Remove default-pulse-width property and stick to default hwmon policy
 ---
  .../devicetree/bindings/hwmon/pwm-fan.txt  | 23 
 ++
  1 file changed, 23 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
 b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 index 610757c..001446a 100644
 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
 @@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
  Required properties:
  - compatible : pwm-fan
  - pwms   : the PWM that is used to control the PWM fan
 +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
 + which correspond to thermal cooling states
 +
 +Thorough description of the following bindings:
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + thermal-zone {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 0 1;
 + };
 + };
 + };
 +
 +for PWM FAN used as cooling device can be found at:
 +./Documentation/devicetree/bindings/thermal/thermal.txt
  
  Example:
   pwm-fan {
   compatible = pwm-fan;
   status = okay;
   pwms = pwm 0 1 0;
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + cooling-levels = 0 102 170 255;
   };
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 5/8] hwmon: thermal: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

Patch subject should use a prefix like:
'arm: dts:'

On Mon, Dec 22, 2014 at 05:27:45PM +0100, Lukasz Majewski wrote:
 With those bindings it is possible to use pwm-fan device available in
 Odroid U3 as a cooling device.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - Rename cooling-pwm-values property to cooling-levels
 ---
  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 
 ++-
  1 file changed, 32 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
 b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 index 60bd1e4..380035d 100644
 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
 +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
 @@ -32,11 +32,42 @@
   };
   };
  
 - pwm-fan {
 + fan0: pwm-fan {
   compatible = pwm-fan;
   pwms = pwm 0 1 0;
 + cooling-min-state = 0;
 + cooling-max-state = 3;
 + #cooling-cells = 2;
 + cooling-levels = 0 102 170 255;
   status = okay;
   };
 +
 + thermal-zones {
 + cpu_thermal: cpu-thermal {
 + cooling-maps {
 + map0 {
 +  trip = cpu_alert1;
 +  cooling-device = cpu0 7 7;
 + };
 + map1 {
 +  trip = cpu_alert2;
 +  cooling-device = cpu0 13 13;
 + };
 + map2 {
 +  trip = cpu_alert0;
 +  cooling-device = fan0 0 1;
 + };
 + map3 {
 +  trip = cpu_alert1;
 +  cooling-device = fan0 1 2;
 + };
 + map4 {
 +  trip = cpu_alert2;
 +  cooling-device = fan0 2 3;
 + };
 + };
 + };
 + };
  };
  
  pwm {
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH v2 07/17] thermal: cpu_cooling: Modify exynos thermal code to use device tree for cpu cooling configuration

[Eduardo Valentin]

On Wed, Dec 10, 2014 at 01:09:46PM +0100, Lukasz Majewski wrote:
 Up till now exynos_tmu_data.c was used for storing CPU cooling configuration
 data. Now the Exynos thermal core code uses device tree to get this data.
 For this purpose generic thermal code for configuring CPU cooling was
 used.

Title prefix also does not help here, I would use 'thermal: exynos: '

 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v2:
 - None
 ---
  drivers/cpufreq/exynos-cpufreq.c|  23 -
  drivers/thermal/samsung/exynos_thermal_common.c | 122 
 ++--
  drivers/thermal/samsung/exynos_tmu.c|   7 --
  drivers/thermal/samsung/exynos_tmu.h|   5 -
  drivers/thermal/samsung/exynos_tmu_data.c   |  42 +---
  5 files changed, 94 insertions(+), 105 deletions(-)
 
 diff --git a/drivers/cpufreq/exynos-cpufreq.c 
 b/drivers/cpufreq/exynos-cpufreq.c
 index 1e0ec57..fdedb8d 100644
 --- a/drivers/cpufreq/exynos-cpufreq.c
 +++ b/drivers/cpufreq/exynos-cpufreq.c
 @@ -18,10 +18,13 @@
  #include linux/cpufreq.h
  #include linux/platform_device.h
  #include linux/of.h
 +#include linux/cpu_cooling.h
 +#include linux/cpu.h
  
  #include exynos-cpufreq.h
  
  static struct exynos_dvfs_info *exynos_info;
 +static struct thermal_cooling_device *cdev;
  static struct regulator *arm_regulator;
  static unsigned int locking_frequency;
  
 @@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
  
  static int exynos_cpufreq_probe(struct platform_device *pdev)
  {
 + struct device_node *np;
   int ret = -EINVAL;
  
   exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
 @@ -198,9 +202,24 @@ static int exynos_cpufreq_probe(struct platform_device 
 *pdev)
   /* Done here as we want to capture boot frequency */
   locking_frequency = clk_get_rate(exynos_info-cpu_clk) / 1000;
  
 - if (!cpufreq_register_driver(exynos_driver))
 - return 0;
 + if (cpufreq_register_driver(exynos_driver))
 + goto err;
  
 + np = of_find_node_by_path(/cpus/cpu@0);
 + if (!np) {
 + pr_err(failed to find cpu0 node\n);
 + return -ENOENT;
 + }
 + 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;
 + err:
   dev_err(pdev-dev, failed to register cpufreq driver\n);
   regulator_put(arm_regulator);
  err_vdd_arm:
 diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
 b/drivers/thermal/samsung/exynos_thermal_common.c
 index 6dc3815..00aa688 100644
 --- a/drivers/thermal/samsung/exynos_thermal_common.c
 +++ b/drivers/thermal/samsung/exynos_thermal_common.c
 @@ -133,47 +133,62 @@ static int exynos_get_crit_temp(struct 
 thermal_zone_device *thermal,
  static int exynos_bind(struct thermal_zone_device *thermal,
   struct thermal_cooling_device *cdev)
  {
 - 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;
 + struct device_node *child, *gchild, *np;
 + struct of_phandle_args cooling_spec;
 + unsigned long max, state = 0;
 + int ret = 0, i = 0;
  
 - tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
 - tab_size = data-cooling_data.freq_clip_count;
 -
 - if (tab_ptr == NULL || tab_size == 0)
 + /*
 +  * Below code is necessary to skip binding when cpufreq's
 +  * frequency table is not yet initialized.
 +  */
 + cdev-ops-get_max_state(cdev, state);
 + if (!state  !th_zone-cool_dev_size) {
 + th_zone-cool_dev_size = 1;
 + th_zone-cool_dev[0] = cdev;
 + th_zone-bind = false;
   return 0;
 + }
  
 - /* find the cooling device registered*/
 - for (i = 0; i  th_zone-cool_dev_size; i++)
 - if (cdev == th_zone-cool_dev[i])
 - break;
 + np = of_find_node_by_path(/thermal-zones/cpu-thermal);
 + if (!np) {
 + pr_err(failed to find thmerla-zones/cpu-thermal node\n);
 + return -ENOENT;
 + }
  
 - /* No matching cooling device */
 - if (i == th_zone-cool_dev_size)
 - return 0;
 + child = of_get_child_by_name(np, cooling-maps);
  
 - /* Bind the thermal zone to the cpufreq cooling device */
 - for (i = 0; i  tab_size; i++) {
 - clip_data = (struct freq_clip_table *)(tab_ptr[i]);
 - level = cpufreq_cooling_get_level(0, clip_data-freq_clip_max);
 - if (level == THERMAL_CSTATE_INVALID)
 - return 0;
 - switch (GET_ZONE(i)) {
 - 

Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

On Wed, Dec 10, 2014 at 01:09:39PM +0100, Lukasz Majewski wrote:
 1. Introduction
 
 Following patches aim to clean up the current implementation of the thermal
 framework on Exynos devices.
 
 The main goal was to use a generic code for reading thermal configuration
 (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files
 were removed.
 

Very good! Thanks for cleaning the code.

Given the decision to be DT only, my only question now is if you need to
support non-DT booting systems. Do you (Exynos platforms in general) care
about booting without DT?

If not, then removing makes completely sense to me.


 Around 400 lines of code (LOC) were removed directly by this patch, which
 is around 20% of the Exynos thermal code base.
 

Great!

 This work should NOT bring any functional changes to Exynos thermal 
 subsystem.
 

OK.

 2. Patch-set structure
 
 Then the cpu_cooling functionality has been preserved to allow cooling
 devices by reducing operating frequency. Definition of trip points and
 cpufreq's cooling properties were moved to device tree.
 

uhh.. OK. but, by supporting of-thermal that means drivers should never
care about loading cpu cooling. That is done via cpufreq-dt. That is why
we had the cycle with cpufreq folks, remember?

(I will have a look in your patches)

 Then the rework of the way in which configuration data is provided to
 the Exynos thermal subsystem was performed. Now device tree is used for
 configuration.

This is very good. Do you care sending feedback if you need extra
configuration or does of-thermal cover your scenarios (a part from the
amendments you already did)?

I know people (tegra and rockchip) are interested in hw trip points,
which I believe should be of your interest too. Of course, that is maybe
an off-topic for this series.


 
 Patch series end with removing exynos5250/exynos3250 TMU compatibles.
 Both SoCs have thermal management unit (TMU) compatible with the one first 
 introduced at Exynos4412.

OK. I will have a look in DT changes you did. But in general, removing
support needs to be done carefully for backward compatibility :-(.

 
 3. Dead code removal
 
 Thermal support for some SoCs, previously available in the exynos_tmu_data.c 
 file, was removed since, as of (almost) 3.19-rc1, they didn't have TMU 
 bindings.
 
 Moreover, support for cpu_cooling devices was preserved only on those
 SoCs which had available and working cpufreq driver.


Have you tried your series with cpufreq-dt?

 
 4. Testing
 
 Test devices:
 - Exynos4210 - Trats (TMU zone + cpu_cooling)
 - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling)
 - Exynos5250 - Arndale (TMU zone + cpu_cooling)
 - Exynos5420 - Arndale-octa (only TMU zones)
 
 Unfortunately, I don't posses Exynos5440 for testing. Its functionality
 has been preserved in the code, but not tested on the hardware. I would
 be grateful for help in testing.
 
 5. This work apply on the following tree:
 
 kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree
 SHA1: c42c7a44c7a543dcb388c1ee1a798e6ed76ad8cf
 
 
 Lukasz Majewski (17):
   thermal: exynos: cosmetic: Correct comment format
   thermal: exynos: Provide thermal_exynos.h file to be included in
 device tree files
   thermal: dts: trats: Enable TMU on the Exynos4210 trats device
   thermal: dts: exynos: Add LD010 regulator node necessary for TMU on
 Odroid
   thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device
   thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu
 cooling functionality
   thermal: cpu_cooling: Modify exynos thermal code to use device tree
 for cpu cooling configuration
   thermal: exynos: dts: Add default definition of the TMU sensor
 parameter
   thermal: dts: Default trip points definition for Exynos5420 SoCs
   thermal: exynos: dts: Define default thermal-zones for Exynos4
   thermal: dts: exynos: Trip points and sensor configuration data for
 Exynos5440
   thermal: exynos: dts: Provide device tree bindings identical to one in
 exynos_tmu_data.c
   thermal: samsung: core: Exynos TMU rework to use device tree for
 configuration
   thermal: exynos: Remove exynos_thermal_common.[c|h] files
   thermal: exynos: Remove exynos_tmu_data.c file
   thermal: exynos: Make Exynos5250 TMU compatible with Exynos4412
   thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412
 
  arch/arm/boot/dts/exynos3250.dtsi |   6 +-
  arch/arm/boot/dts/exynos4-cpu-thermal.dtsi|  52 +++
  arch/arm/boot/dts/exynos4.dtsi|   5 +
  arch/arm/boot/dts/exynos4210-trats.dts|  19 +
  arch/arm/boot/dts/exynos4210.dtsi |  43 ++-
  arch/arm/boot/dts/exynos4212.dtsi |  20 +
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi   |  27 ++
  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi |  24 ++
  arch/arm/boot/dts/exynos4412-trats2.dts   |  15 +
  arch/arm/boot/dts/exynos4412.dtsi |  32 

Re: [PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

Hello Folks,

On Fri, Nov 28, 2014 at 11:18:24AM +0100, Lukasz Majewski wrote:
 On Fri, 28 Nov 2014 13:35:49 +0530
 Viresh Kumar viresh.ku...@linaro.org wrote:
 
  On 27 November 2014 at 19:42, Eduardo Valentin edubez...@gmail.com
  wrote:
   (I'm sorry VireshK, I am still using my normal practice) :-)
  
  That's fine :)
  
   diff --git a/drivers/thermal/cpu_cooling.c
   b/drivers/thermal/cpu_cooling.c index 1ab0018..bed3fa2 100644
   --- a/drivers/thermal/cpu_cooling.c
   +++ b/drivers/thermal/cpu_cooling.c
   @@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node
   *np, int ret = 0, i;
   struct cpufreq_policy policy;
  
   +   if (!cpufreq_frequency_get_table(0)) {
   +   pr_err(cpu_cooling: cpufreq layer not ready!
   Deferring.\n);
  
  Throwing an error here doesn't look to be the right thing. Ultimately
  we will register the cooling dev when probed again after some time.
  
  So, a pr_debug() suits more here.
  

Yeah, I agree here. 

  Also, this breaks existing exynos thermal drivers as they don't handle
  -EPROBE_DEFER well right now.
 
 Unfortunately Viresh is correct here. Current (before rework) Exynos
 TMU driver expects that cpu_cooling device will succeed.
 


Well, I wouldn't say unfortunately, but fortunately! :-)

Ok. But I believe it is a matter of propagating the error code. As I
included in this patch: 

diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..f84975e 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -373,7 +373,7 @@ int exynos_register_thermal(struct thermal_sensor_conf 
*sensor_conf)
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
dev_err(sensor_conf-dev,
Failed to register cpufreq cooling device\n);
-   ret = -EINVAL;
+   ret = 
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
goto err_unregister;
}
th_zone-cool_dev_size++;



  
  I reached here, because one of my patches had something similar to
  what you wrote. Just for this file though, haven't updated any other
  drivers though.
  
  Will be sending you my small patchset by end of day today, please see
  if they make any sense at all..

The version you sent (for exynos) is better because there is a check for
not print error messages in case of deferring.

However, I would prefer, at least to what comes to deferring, to update
the drivers altogether with the inclusion of the check in cpu cooling.
This way the change in behavior is atomic, in terms of commit changes.

Viresh, if you don't mind, I will merge your patch 04/26 into this one.

 
 Best regards,
 Łukasz Majewski

BR, Eduardo Valentin


signature.asc
Description: Digital signature

[PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.

Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.

Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/thermal/cpu_cooling.c  | 3 +++
 drivers/thermal/db8500_cpufreq_cooling.c   | 5 -
 drivers/thermal/imx_thermal.c  | 5 -
 drivers/thermal/samsung/exynos_thermal_common.c| 7 ---
 drivers/thermal/samsung/exynos_tmu.c   | 4 +++-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
 6 files changed, 10 insertions(+), 20 deletions(-)
---
Changes from V2:
- Removed logging message when returning EPROBE_DEFER. Majority
of the existing code simply do not log. Following the pattern
- Merges Viresh's patch in Exynos driver. Reasoning, the change
in the API behavior goes together with the needed changes in the API
users.

Changes from V1:
 - As per Viresh K. suggestion's, the check for cpufreq layer readiness is now
only a simple fetch for cpufreq table.

This patch depends on:
(0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
https://patchwork.kernel.org/patch/5390731/
https://patchwork.kernel.org/patch/5390741/
https://patchwork.kernel.org/patch/5390751/
https://patchwork.kernel.org/patch/5390761/
(1) - fix of thermal core:
https://patchwork.kernel.org/patch/5326991/


BR,

Eduardo Valentin

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..88d2775 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,9 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
 
+   if (!cpufreq_frequency_get_table(0))
+   return ERR_PTR(-EPROBE_DEFER);
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c 
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
  */
 
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/err.h
 #include linux/module.h
 #include linux/of.h
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct 
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
 
-   /* make sure cpufreq driver has been initialized */
-   if (!cpufreq_frequency_get_table(0))
-   return -EPROBE_DEFER;
-
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
 
 #include linux/clk.h
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/delay.h
 #include linux/device.h
 #include linux/init.h
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
 
-   if (!cpufreq_get_current_driver()) {
-   dev_dbg(pdev-dev, no cpufreq driver!);
-   return -EPROBE_DEFER;
-   }
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..d4eaa1b 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -371,9 +371,10 @@ int exynos_register_thermal(struct thermal_sensor_conf 
*sensor_conf)
th_zone-cool_dev[th_zone-cool_dev_size] =
cpufreq_cooling_register(mask_val);
if (IS_ERR

Re: [PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

Russel,

On Fri, Nov 28, 2014 at 05:10:24PM +, Russell King - ARM Linux wrote:
 On Fri, Nov 28, 2014 at 10:53:30AM -0400, Eduardo Valentin wrote:
  diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
  b/drivers/thermal/samsung/exynos_thermal_common.c
  index 3f5ad25..d4eaa1b 100644
  --- a/drivers/thermal/samsung/exynos_thermal_common.c
  +++ b/drivers/thermal/samsung/exynos_thermal_common.c
  @@ -371,9 +371,10 @@ int exynos_register_thermal(struct thermal_sensor_conf 
  *sensor_conf)
  th_zone-cool_dev[th_zone-cool_dev_size] =
  cpufreq_cooling_register(mask_val);
  if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
  -   dev_err(sensor_conf-dev,
  -   Failed to register cpufreq cooling device\n);
  -   ret = -EINVAL;
  +   ret = 
  PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
  +   if (ret != -EPROBE_DEFER)
  +   dev_err(sensor_conf-dev,
  +   Failed to register cpufreq cooling 
  device\n);
 
 Something which bugs me quite a lot is when there is an error code (which
 tells you why something didn't work) and you have an error message, and
 the error message doesn't bother printing the error code.
 
 You might as well just print Failed\n and leave it at that, or md5sum
 the error message and print the sum instead. :)
 

I like the md5sum better! :-)


 Knowing why something failed allows you to read the source, and find
 possible reasons for the failure (which could come down to one reason)
 and allows faster resolution of the problem.
 

Sure. I will resend with the error codes in the error messages. Makes
completely sense.

Thanks for taking the time and reviewing.


Eduardo Valentin

 -- 
 FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
 according to speedtest.net.


signature.asc
Description: Digital signature

Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

Hello Viresh,

On Thu, Nov 27, 2014 at 09:38:39AM +0530, Viresh Kumar wrote:
 Few nits..
 
 On 26 November 2014 at 23:20, Eduardo Valentin edubez...@gmail.com wrote:
 
  Signed-off-by: Eduardo Valentin edubez...@gmail.com
  ---
 
 The normal practice is to write the non-commitable part here ...
 

err... normal practice by whom? hehe...

My normal practice is to allow people to read the diff stat before my
extra comments :-)

   drivers/thermal/cpu_cooling.c  | 5 +
   drivers/thermal/db8500_cpufreq_cooling.c   | 5 -
   drivers/thermal/imx_thermal.c  | 5 -
   drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
   drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
   5 files changed, 6 insertions(+), 17 deletions(-)
  ---
 
 But this works as well :)
 

hehe ok.

  This is attempt to organize the cpu cooling vs. cpufreq boot sequencing.
  The main change in this patch, as in the commit log, is to have the check
  for the cpufreq layer in the cpu cooling device registration, instead of
  in thermal drivers. This way, drivers don't need to bother about it, they
  just need to propagate the error value.
 
  This change was tested on top of:
  (0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
  https://patchwork.kernel.org/patch/5384141/
  https://patchwork.kernel.org/patch/5384151/
  https://patchwork.kernel.org/patch/5384161/
  https://patchwork.kernel.org/patch/5384171/
  (1) - fix of thermal core:
  https://patchwork.kernel.org/patch/5326991/
 
  After Viresh's changes, cpufreq-dt is properly sequenced with cpu cooling
  registration. Non-of based drivers also should take advantage if these
  changes, as now they do not need to check for cpufreq layer. The check is
  where it belongs, in cpu cooling device registration.
 
  BR, Eduardo Valentin
 
 
  diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
  index 1ab0018..9e6945b 100644
  --- a/drivers/thermal/cpu_cooling.c
  +++ b/drivers/thermal/cpu_cooling.c
  @@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
  int ret = 0, i;
  struct cpufreq_policy policy;
 
  +   if (!cpufreq_get_current_driver() || 
  !cpufreq_frequency_get_table(0)) {
 
 Only !cpufreq_frequency_get_table(0) is enough here.
 

Yeah, I thought of it too. Just combined what people had in their
drivers here. But I agree that latter is enough.

 For rest:
 
 Acked-by: Viresh Kumar viresh.ku...@linaro.org

Ok.

though.. normal practice says  ack's are oftern used by the maintainer
of the affected code (quoting Documentation/SubmittingPatches) :-)
BR, Eduardo Valenti


signature.asc
Description: Digital signature

[PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.

Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.

Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/thermal/cpu_cooling.c  | 5 +
 drivers/thermal/db8500_cpufreq_cooling.c   | 5 -
 drivers/thermal/imx_thermal.c  | 5 -
 drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
 5 files changed, 6 insertions(+), 17 deletions(-)
---
(I'm sorry VireshK, I am still using my normal practice) :-)

Changes from V1:
 - As per Viresh K. suggestion's, the check for cpufreq layer readiness is now
   only a simple fetch for cpufreq table.

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..bed3fa2 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
 
+   if (!cpufreq_frequency_get_table(0)) {
+   pr_err(cpu_cooling: cpufreq layer not ready! Deferring.\n);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c 
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
  */
 
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/err.h
 #include linux/module.h
 #include linux/of.h
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct 
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
 
-   /* make sure cpufreq driver has been initialized */
-   if (!cpufreq_frequency_get_table(0))
-   return -EPROBE_DEFER;
-
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
 
 #include linux/clk.h
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/delay.h
 #include linux/device.h
 #include linux/init.h
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
 
-   if (!cpufreq_get_current_driver()) {
-   dev_dbg(pdev-dev, no cpufreq driver!);
-   return -EPROBE_DEFER;
-   }
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..f84975e 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -373,7 +373,7 @@ int exynos_register_thermal(struct thermal_sensor_conf 
*sensor_conf)
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
dev_err(sensor_conf-dev,
Failed to register cpufreq cooling device\n);
-   ret = -EINVAL;
+   ret = 
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
goto err_unregister;
}
th_zone-cool_dev_size++;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5fd0386..cf88585 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -28,7 +28,6 @@
 #include linux/kernel.h

[PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Eduardo Valentin]

In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.

Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.

Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
 drivers/thermal/cpu_cooling.c  | 5 +
 drivers/thermal/db8500_cpufreq_cooling.c   | 5 -
 drivers/thermal/imx_thermal.c  | 5 -
 drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
 5 files changed, 6 insertions(+), 17 deletions(-)
---

This is attempt to organize the cpu cooling vs. cpufreq boot sequencing.
The main change in this patch, as in the commit log, is to have the check
for the cpufreq layer in the cpu cooling device registration, instead of
in thermal drivers. This way, drivers don't need to bother about it, they
just need to propagate the error value.

This change was tested on top of:
(0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
https://patchwork.kernel.org/patch/5384141/
https://patchwork.kernel.org/patch/5384151/
https://patchwork.kernel.org/patch/5384161/
https://patchwork.kernel.org/patch/5384171/
(1) - fix of thermal core:
https://patchwork.kernel.org/patch/5326991/

After Viresh's changes, cpufreq-dt is properly sequenced with cpu cooling
registration. Non-of based drivers also should take advantage if these
changes, as now they do not need to check for cpufreq layer. The check is
where it belongs, in cpu cooling device registration.

BR, Eduardo Valentin


diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..9e6945b 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
 
+   if (!cpufreq_get_current_driver() || !cpufreq_frequency_get_table(0)) {
+   pr_err(cpu_cooling: cpufreq layer not ready! Deferring.\n);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c 
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
  */
 
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/err.h
 #include linux/module.h
 #include linux/of.h
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct 
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
 
-   /* make sure cpufreq driver has been initialized */
-   if (!cpufreq_frequency_get_table(0))
-   return -EPROBE_DEFER;
-
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
 
 #include linux/clk.h
 #include linux/cpu_cooling.h
-#include linux/cpufreq.h
 #include linux/delay.h
 #include linux/device.h
 #include linux/init.h
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
 
-   if (!cpufreq_get_current_driver()) {
-   dev_dbg(pdev-dev, no cpufreq driver!);
-   return -EPROBE_DEFER;
-   }
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..f84975e 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -373,7 +373,7 @@ int exynos_register_thermal

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

[Eduardo Valentin]

Hello Lukasz,

On Wed, Nov 12, 2014 at 10:42:41AM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  
  Hello Lukasz,
  
  On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote:
   Hi Eduardo,
   
On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
 This patch extends the of-thermal.c to provide information about
 number of available non critical (i.e. non HW) trip points in
 the system.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/of-thermal.c   | 12 
  drivers/thermal/thermal_core.h |  5 +
  2 files changed, 17 insertions(+)
 
 diff --git a/drivers/thermal/of-thermal.c
 b/drivers/thermal/of-thermal.c index 23c8d6c..cd74e64 100644
 --- a/drivers/thermal/of-thermal.c
 +++ b/drivers/thermal/of-thermal.c
 @@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct
 thermal_zone_device *tz, int trip) return 1;
  }
  
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device
 *tz) +{
 + struct __thermal_zone *data = tz-devdata;
 + int i;
 +
 + for (i = 0; i  data-ntrips; i++)
 + if (data-trips[i].type !=
 THERMAL_TRIP_CRITICAL)
 + continue;
 +
 + return --i;
 +}
 +



I am not against this addition. But looks like we start to spread
some specific APIs that may not be used to other drivers.
   
   Why do you think that this is a specific API? In the thermal OF we
   can define trip point as active, passive, hot and critical.
   
   With the first three we can handle them and properly react. For the
   last one SoC's PMU will power down the board.
   
   Do you know if any board (e.g. from TI) is NOT supposed to shut down
   when critical temperature is passed?
   
  
  So, my point is not really about the usage of trip points. It is just
  that the of-thermal  API will grow with in a wide way with specific
  functions to check some property on the trip point array. And not all
  drivers may be using these function, e.g. the above proposal.
  
   The real problem here is the accessibility to __thermal_trip and
   __thermal_bind arrays.
   
   Use case:
   In the Exynos driver we do need to initialize TMU registers with
   threshold temperatures.
   The temperature is read via tz-ops-get_trip_temp() [1] (from
   of-thermal.c).
   Unfortunately, the current API is not exporting the number of
   non-critical trip points to know how many times call [1].
   Of course we could by hand instantiate [1] n times, but this looks
   for me a bit clumsy.
  
  
  I understand your use case. My point was simply that this use case may
  be specific to your driver (or few drivers).
   
   Additionally, we now have implicit assumption about the order of
   defined temperatures for trip points, but I think this is not a big
   issue.
   
Maybe having a
single API to provide a read-only copy the list / array of trips
might be a better approach. I will think of a better way.
   
   Definitely. Exporting available trip points is crucial.
   
  
  Yeah, I think it is the best thing to do. Share a read-only array /
  copy of the needed data, and then drivers would check what ever
  property they need from the array. Just make sure you document that
  this is a read-only array (i.e. any possible change they do, won't
  affect the original array).
 
 So I assume that you don't mind that I will prepare such of-thermal.c
 modification?

No, please, feel free to send the proposal along with your patchset. To
me, it makes sense you do it, because you will also present a real use
case of this required change.

 
  

I also request you to document it accordingly.
   
   Ok, I will do that.
  
  Cool!
  
  
  
   


  static int of_thermal_get_trend(struct thermal_zone_device *tz,
 int trip, enum thermal_trend *trend)
  {
 diff --git a/drivers/thermal/thermal_core.h
 b/drivers/thermal/thermal_core.h index ed8ff05..334a7be 100644
 --- a/drivers/thermal/thermal_core.h
 +++ b/drivers/thermal/thermal_core.h
 @@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
  void of_thermal_destroy_zones(void);
  int of_thermal_get_ntrips(struct thermal_zone_device *);
  int of_thermal_is_trip_en(struct thermal_zone_device *, int);
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device
 *); #else
  static inline int of_parse_thermal_zones(void) { return 0; }
  static inline void of_thermal_destroy_zones(void) { }
 @@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct
 thermal_zone_device *, int) {
   return 0;
  }
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device
 *)
here, it is supposed to be static inline.

 +{
 + return 0;
 +}
  #endif
  
  #endif /* __THERMAL_CORE_H__ */
 -- 
 2.0.0.rc2
 
   
   
   
   -- 
   Best 

Re: [PATCH 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp

[Eduardo Valentin]

Lukasz,


On Fri, Nov 07, 2014 at 12:20:35PM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  Hello,
  
  On Thu, Oct 09, 2014 at 06:38:40PM +0200, Lukasz Majewski wrote:
   Before this change it was only possible to set get_temp() and
   get_trend() methods to be used in the common code handling passing
   parameters via device tree to cpu-thermal CPU thermal zone device.
   
   Now it is possible to also set emulated value of temperature for
   debug purposes.
   
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
drivers/thermal/of-thermal.c | 25 ++---
include/linux/thermal.h  |  6 --
2 files changed, 26 insertions(+), 5 deletions(-)
   
   diff --git a/drivers/thermal/of-thermal.c
   b/drivers/thermal/of-thermal.c index cd74e64..f206375 100644
   --- a/drivers/thermal/of-thermal.c
   +++ b/drivers/thermal/of-thermal.c
   @@ -98,10 +98,22 @@ struct __thermal_zone {
 void *sensor_data;
 int (*get_temp)(void *, long *);
 int (*get_trend)(void *, long *);
   + int (*set_emul_temp)(void *, unsigned long);
};

/***   DT thermal zone device callbacks   ***/

   +static int of_thermal_set_emul_temp(struct thermal_zone_device *tz,
   + unsigned long temp)
   +{
   + struct __thermal_zone *data = tz-devdata;
   +
   + if (!data-set_emul_temp)
   + return -EINVAL;
   +
   + return data-set_emul_temp(data-sensor_data, temp);
   +}
   +
static int of_thermal_get_temp(struct thermal_zone_device *tz,
unsigned long *temp)
{
   @@ -352,7 +364,8 @@ static struct thermal_zone_device *
thermal_zone_of_add_sensor(struct device_node *zone,
struct device_node *sensor, void *data,
int (*get_temp)(void *, long *),
   -int (*get_trend)(void *, long *))
   +int (*get_trend)(void *, long *),
   +int (*set_emul_temp)(void *, unsigned
   long))
  
  Thanks for improving the API. However, looking at what is above, it
  starts to be pretty ugly. And for sure, this is not the last callback
  to be added.
 
 Presumably there would be some more callbacks.
 
  I believe it is time to add a .ops in the of-thermal.
  While in here, do you mind adding the .ops in a separated patch, then
  add the .set_emul_temp in the .ops field?
 
 I will add an option to pass .ops with thermal_zone_of_add_sensor().
 
 I'm only concerned a bit about testing other users of of-thermal. 
 I have only beaglebone black (BBB) for testing, which on-soc bandgap
 thermal sensor is very inaccurate and hence not supported even at BBB
 github linux kernel repository (v3.14).
 
 Because of above I would need your support for testing.
 

I did the .ops part that is required for your patch:
https://patchwork.kernel.org/patch/5329801/

As you already reviewed it. Do you mind refreshing your series on top of
it?

Cheers,


  
{
 struct thermal_zone_device *tzd;
 struct __thermal_zone *tz;
   @@ -366,10 +379,12 @@ thermal_zone_of_add_sensor(struct device_node
   *zone, mutex_lock(tzd-lock);
 tz-get_temp = get_temp;
 tz-get_trend = get_trend;
   + tz-set_emul_temp = set_emul_temp;
 tz-sensor_data = data;

 tzd-ops-get_temp = of_thermal_get_temp;
 tzd-ops-get_trend = of_thermal_get_trend;
   + tzd-ops-set_emul_temp = of_thermal_set_emul_temp;
 mutex_unlock(tzd-lock);

 return tzd;
   @@ -411,7 +426,8 @@ thermal_zone_of_add_sensor(struct device_node
   *zone, struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
 void *data, int (*get_temp)(void
   *, long *),
   - int (*get_trend)(void *, long *))
   + int (*get_trend)(void *, long *),
   + int (*set_emul_temp)(void *,
   unsigned long)) {
 struct device_node *np, *child, *sensor_np;

   @@ -453,7 +469,8 @@ thermal_zone_of_sensor_register(struct device
   *dev, int sensor_id, return thermal_zone_of_add_sensor(child,
   sensor_np, data,
   get_temp,
   -
   get_trend);
   +
   get_trend,
   +
   set_emul_temp); }
 }
 of_node_put(np);
   @@ -494,9 +511,11 @@ void thermal_zone_of_sensor_unregister(struct
   device *dev, mutex_lock(tzd-lock);
 tzd-ops-get_temp = NULL;
 tzd-ops-get_trend = NULL;
   + tzd-ops-set_emul_temp = NULL;

 tz-get_temp = NULL;
 tz-get_trend = NULL;
   + tz-set_emul_temp = NULL;
 tz-sensor_data = NULL;
 mutex_unlock(tzd-lock);
}
   diff --git a/include/linux/thermal.h b/include/linux/thermal.h
   index 0305cde..36010e9 100644
   --- a/include/linux/thermal.h
   +++ b/include/linux/thermal.h
   @@ -290,14 +290,16 @@ struct thermal_genl_event {
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id,
   

Re: [PATCH v2 00/33] thermal: exynos: convert the driver to use per-SoC type operations

[Eduardo Valentin]

Hello Bartlomiej,


On Thu, Nov 13, 2014 at 04:00:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series replaces the hardware registers abstractions in
 the Exynos thermal driver by the usage of per-SoC type operations.

Good! I think the driver is a bit confusing because it has two ways of
checking features: soc based and feature flag based. Thus, removing one
is a good step.

 Such solution provides simpler, easier to understand code and

Well, that is arguable. IMO, the feature based solution is naturally
easier to understand as while reading the code, you think about the
feature not about chip / IP/ SoC versions. Besides, having soc based
approach spreads many if's in your code base.

Anyways, so far no one working in the Exynos code base has nacked your
proposal. Apart from that, the issue I had with it, as I mentioned, was
the fact that it currently has two ways of representing / checking
features. That is for sure the major issue.

 allows removal of ~250 LOCs (~11% of the whole source code) from
 the driver.  Some other driver improvements are now also possible
 thanks to these changes but are scheduled at later time (like
 consolidating code for clearing IRQs using INTCLEAR register).
 

I am not sure I get your point here. I understand you are basing new
changes in the code on top of this series, but I don't see how this
refactoring could enable other feature implementions.


 The patchset should not cause any functionality changes.  This
 means that unless there are some bugs in the patches itself there
 should be no behavior changes for the driver (this also includes
 lack of changes in the way hardware is accessed by the driver).
 
 All testing was done on (Exynos4412 SoC based) ODROID U3 board
 (some additional patches are needed to make the Exynos thermal
 driver work on this hardware).

Is it possible to spread testing here? I would like to have coverage for
all supported chip versions. The reasoning is because the driver
supports more than Exynos4412, and the amount of changes are
considerably big.

One thing I can do is to start testing in linux-next on this code. Thus,
I can merge it in my -next branch (which includes my -linus and -fixes
branches). But so far, it would not be queued.

My proposal is that these changes will be sent only for the 3.19 merge
window though. For 3.18 -rc's I believe it is too late. However,
to get it into 3.19, I request you to provide the testing in all
supported chips, as I mentioned. Do you think it is doable before Linus
opens 3.19 merge window?


 
 Depends on:
 - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo
 

Thanks for attending my request.

 Changes since v1 (https://lkml.org/lkml/2014/9/18/305):
 - rebased on top of the current linux-soc-thermal kernel
 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (33):
   thermal: exynos: remove needless triminfo_data abstraction
   thermal: exynos: remove needless tmu_status abstraction
   thermal: exynos: remove needless threshold_temp abstraction
   thermal: exynos: remove needless triminfo_ctrl abstraction
   thermal: exynos: remove needless test_mux_addr_shift abstraction
   thermal: exynos: remove needless therm_trip_[mode,mask]_shift
 abstractions
   thermal: exynos: remove needless therm_trip_en_shift abstraction
   thermal: exynos: remove needless emul_temp_shift abstraction
   thermal: exynos: remove needless emul_time_shift abstraction
   thermal: exynos: replace tmu_irqstatus check by Exynos5440 one
   thermal: exynos: replace tmu_pmin check by Exynos5440 one
   thermal: exynos: simplify HW_TRIP level setting
   thermal: exynos: replace threshold_falling check by Exynos SoC type
 one
   thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag
   thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag
   thermal: exynos: add sanitize_temp_error() helper
   thermal: exynos: add get_th_reg() helper
   thermal: exynos: add -tmu_initialize method
   thermal: exynos: add get_con_reg() helper
   thermal: exynos: add -tmu_control method
   thermal: exynos: add -tmu_read method
   thermal: exynos: add get_emul_con_reg() helper
   thermal: exynos: add -tmu_set_emulation method
   thermal: exynos: add -tmu_clear_irqs method
   thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag
   thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag
   thermal: exynos: remove TMU_SUPPORT_EMULATION flag
   thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag
   thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag
   thermal: exynos: remove test_mux pdata field
   thermal: exynos: remove SoC type ifdefs
   thermal: exynos: remove __EXYNOS5420_TMU_DATA macro
   thermal: exynos: remove exynos_tmu_data.h include
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 692 
 
  drivers/thermal/samsung/exynos_tmu.h| 123 

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

[Eduardo Valentin]

Hello Lukasz,

On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote:
 Hi Eduardo,
 
  On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
   This patch extends the of-thermal.c to provide information about
   number of available non critical (i.e. non HW) trip points in the
   system.
   
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
drivers/thermal/of-thermal.c   | 12 
drivers/thermal/thermal_core.h |  5 +
2 files changed, 17 insertions(+)
   
   diff --git a/drivers/thermal/of-thermal.c
   b/drivers/thermal/of-thermal.c index 23c8d6c..cd74e64 100644
   --- a/drivers/thermal/of-thermal.c
   +++ b/drivers/thermal/of-thermal.c
   @@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct
   thermal_zone_device *tz, int trip) return 1;
}

   +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
   +{
   + struct __thermal_zone *data = tz-devdata;
   + int i;
   +
   + for (i = 0; i  data-ntrips; i++)
   + if (data-trips[i].type != THERMAL_TRIP_CRITICAL)
   + continue;
   +
   + return --i;
   +}
   +
  
  
  
  I am not against this addition. But looks like we start to spread some
  specific APIs that may not be used to other drivers.
 
 Why do you think that this is a specific API? In the thermal OF we can
 define trip point as active, passive, hot and critical.
 
 With the first three we can handle them and properly react. For the last
 one SoC's PMU will power down the board.
 
 Do you know if any board (e.g. from TI) is NOT supposed to shut down
 when critical temperature is passed?
 

So, my point is not really about the usage of trip points. It is just
that the of-thermal  API will grow with in a wide way with specific
functions to check some property on the trip point array. And not all
drivers may be using these function, e.g. the above proposal.

 The real problem here is the accessibility to __thermal_trip and
 __thermal_bind arrays.
 
 Use case:
 In the Exynos driver we do need to initialize TMU registers with
 threshold temperatures.
 The temperature is read via tz-ops-get_trip_temp() [1] (from
 of-thermal.c).
 Unfortunately, the current API is not exporting the number of
 non-critical trip points to know how many times call [1].
 Of course we could by hand instantiate [1] n times, but this looks for
 me a bit clumsy.


I understand your use case. My point was simply that this use case may
be specific to your driver (or few drivers).
 
 Additionally, we now have implicit assumption about the order of defined
 temperatures for trip points, but I think this is not a big issue.
 
  Maybe having a
  single API to provide a read-only copy the list / array of trips might
  be a better approach. I will think of a better way.
 
 Definitely. Exporting available trip points is crucial.
 

Yeah, I think it is the best thing to do. Share a read-only array / copy
of the needed data, and then drivers would check what ever property they
need from the array. Just make sure you document that this is a
read-only array (i.e. any possible change they do, won't affect the
original array).

  
  I also request you to document it accordingly.
 
 Ok, I will do that.

Cool!



 
  
  
static int of_thermal_get_trend(struct thermal_zone_device *tz,
   int trip, enum thermal_trend *trend)
{
   diff --git a/drivers/thermal/thermal_core.h
   b/drivers/thermal/thermal_core.h index ed8ff05..334a7be 100644
   --- a/drivers/thermal/thermal_core.h
   +++ b/drivers/thermal/thermal_core.h
   @@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
void of_thermal_destroy_zones(void);
int of_thermal_get_ntrips(struct thermal_zone_device *);
int of_thermal_is_trip_en(struct thermal_zone_device *, int);
   +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
#else
static inline int of_parse_thermal_zones(void) { return 0; }
static inline void of_thermal_destroy_zones(void) { }
   @@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct
   thermal_zone_device *, int) {
 return 0;
}
   +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
  here, it is supposed to be static inline.
  
   +{
   + return 0;
   +}
#endif

#endif /* __THERMAL_CORE_H__ */
   -- 
   2.0.0.rc2
   
 
 
 
 -- 
 Best regards,
 
 Lukasz Majewski
 
 Samsung RD Institute Poland (SRPOL) | Linux Platform Group


signature.asc
Description: Digital signature

Re: [PATCH] thermal: exynos: use correct offset for TMU_CONTROL register on Exynos5260

[Eduardo Valentin]

Hi Bartlomiej,

On Mon, Oct 20, 2014 at 02:41:07PM +0200, Bartlomiej Zolnierkiewicz wrote:
 
 Hi,
 
 Eduardo, could you please merge this patch?
 

I queued this in my -fixes branch. It should appear also in linux-next.

Can you please refresh your patch series
https://lkml.org/lkml/2014/9/18/305

based on my tree? Looks like something may be missing, as could not get
all patches applied cleanly.

Thanks

 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 On Thursday, September 11, 2014 03:00:49 PM Bartlomiej Zolnierkiewicz wrote:
  In exynos5260_tmu_registers tmu_ctrl entry is erroneously
  assigned twice.  The second assignment (to EXYNOS_TMU_REG_CONTROL1
  define which represents 0x24 value) overrides the first one
  (to EXYNOS_TMU_REG_CONTROL define which represents 0x20 value)
  which results in the wrong (according to the Exynos5260 SoC
  documentation that I have) offset being used for TMU_CONTROL
  register.  Fix it by removing the wrong assignment and then
  remove no longer used EXYNOS_TMU_REG_CONTROL1 define.
  
  Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
  Cc: Amit Daniel Kachhap amit.dan...@samsung.com
  Cc: Lukasz Majewski l.majew...@samsung.com
  Cc: Eduardo Valentin edubez...@gmail.com
  Cc: Zhang Rui rui.zh...@intel.com
  Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  Acked-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu_data.c |1 -
   drivers/thermal/samsung/exynos_tmu_data.h |1 -
   2 files changed, 2 deletions(-)
  
  Index: b/drivers/thermal/samsung/exynos_tmu_data.c
  ===
  --- a/drivers/thermal/samsung/exynos_tmu_data.c 2014-09-11 
  14:41:12.567347442 +0200
  +++ b/drivers/thermal/samsung/exynos_tmu_data.c 2014-09-11 
  14:43:00.211350284 +0200
  @@ -273,7 +273,6 @@ struct exynos_tmu_init_data const exynos
   static const struct exynos_tmu_registers exynos5260_tmu_registers = {
  .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
  .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
  -   .tmu_ctrl = EXYNOS_TMU_REG_CONTROL1,
  .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
  .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
  .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
  Index: b/drivers/thermal/samsung/exynos_tmu_data.h
  ===
  --- a/drivers/thermal/samsung/exynos_tmu_data.h 2014-09-11 
  14:41:12.243347433 +0200
  +++ b/drivers/thermal/samsung/exynos_tmu_data.h 2014-09-11 
  14:43:36.167351233 +0200
  @@ -83,7 +83,6 @@
   #define EXYNOS_MAX_TRIGGER_PER_REG 4
   
   /* Exynos5260 specific */
  -#define EXYNOS_TMU_REG_CONTROL10x24
   #define EXYNOS5260_TMU_REG_INTEN   0xC0
   #define EXYNOS5260_TMU_REG_INTSTAT 0xC4
   #define EXYNOS5260_TMU_REG_INTCLEAR0xC8


signature.asc
Description: Digital signature

Re: [PATCH] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

[Eduardo Valentin]

Hello Yadwinder,

On Thu, Nov 06, 2014 at 04:26:27PM +0530, Yadwinder Singh Brar wrote:
 Hello Eduardo Valentin,
 
 On Thursday, November 06, 2014 2:17 AM, Eduardo Valentin wrote:
  Hello Yadwinder,
  
  On Wed, Nov 05, 2014 at 05:46:25PM +0530, Yadwinder Singh Brar wrote:
   Existing code updates cupfreq policy only while executing
   cpufreq_apply_cooling() function (i.e. when notify_device !=
  NOTIFY_INVALID).
  
  Correct. The case you mention is when we receive a notification from
  cpufreq. But also, updates the cpufreq policy when the cooling device
  changes state, a call from thermal framework.
 
 I mentioned thermal framework case only, existing code updates
 cupfreq policy only when (notify_device != NOTIFY_INVALID),
 which happens only when notification comes from cpufreq_update_policy
 while changing cooling device's state(i.e. cpufreq_apply_cooling()).
 In case of other notifications notify_device is always NOTIFY_INVALID.

I see your point.

 
  
   It doesn't apply constraints when cpufreq policy update happens from
   any other place but it should update the cpufreq policy with thermal
   constraints every time when there is a cpufreq policy update, to keep
   state of cpufreq_cooling_device and max_feq of cpufreq policy in
  sync.
  
  I am not sure I follow you here. Can you please elaborate on 'any other
  places'? Could you please mention (also in the commit log) what are the
  case the current code does not cover? For instance, the
  cpufreq_apply_cooling gets called on notification coming from thermal
  subsystem, and for changes in cpufreq subsystem,
  cpufreq_thermal_notifier is called.
  
 
 Other places mean possible places from where cpufreq_update_policy()
 can be called at runtime, an instance in present kernel is cpufreq_resume().
 But since cpufreq_update_policy() is an exposed API, I think
 for robustness, generic cpu cooling should be able to take care of any
 possible case(in future as well).
 

OK. I understand now. Can you please improve your commit message by
adding the descriptions you mentioned here?

  
   This patch modifies code to maintain a global cpufreq_dev_list and
  get
   corresponding cpufreq_cooling_device for policy's cpu from
   cpufreq_dev_list when there is any policy update.
  
  OK. Please give real examples of when the current code fails to catch
  the event.
  
 
 While resuming cpufreq updates cpufreq_policy for boot cpu and it
 restores default policy-usr_policy irrespective of cooling device's
 cpufreq_state since notification gets missed because (notify_device ==
 NOTIFY_INVALID).
 Another thing, Rather I would say an issue, I observed is that
 Userspace is able to change max_freq irrespective of cooling
 device's state, as notification gets missed.


Include also the examples above you gave.

Have you verified if with this patch the issue with userland goes away?
   
  
  BR,
  
  Eduardo Valentin
  
  
   Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
   ---
drivers/thermal/cpu_cooling.c |   37 ---
  --
1 files changed, 20 insertions(+), 17 deletions(-)
  
   diff --git a/drivers/thermal/cpu_cooling.c
   b/drivers/thermal/cpu_cooling.c index 1ab0018..5546278 100644
   --- a/drivers/thermal/cpu_cooling.c
   +++ b/drivers/thermal/cpu_cooling.c
   @@ -50,15 +50,14 @@ struct cpufreq_cooling_device {
 unsigned int cpufreq_state;
 unsigned int cpufreq_val;
 struct cpumask allowed_cpus;
   + struct list_head node;
};
static DEFINE_IDR(cpufreq_idr);
static DEFINE_MUTEX(cooling_cpufreq_lock);
  
static unsigned int cpufreq_dev_count;
  
   -/* notify_table passes value to the CPUFREQ_ADJUST callback
  function.
   */ -#define NOTIFY_INVALID NULL -static struct cpufreq_cooling_device
   *notify_device;
   +static LIST_HEAD(cpufreq_dev_list);
  
/**
 * get_idr - function to get a unique id.
   @@ -287,15 +286,12 @@ static int cpufreq_apply_cooling(struct
   cpufreq_cooling_device *cpufreq_device,
  
 cpufreq_device-cpufreq_state = cooling_state;
 cpufreq_device-cpufreq_val = clip_freq;
   - notify_device = cpufreq_device;
  
 for_each_cpu(cpuid, mask) {
 if (is_cpufreq_valid(cpuid))
 cpufreq_update_policy(cpuid);
 }
  
   - notify_device = NOTIFY_INVALID;
   -
 return 0;
}
  
   @@ -316,21 +312,27 @@ static int cpufreq_thermal_notifier(struct
   notifier_block *nb,  {
 struct cpufreq_policy *policy = data;
 unsigned long max_freq = 0;
   + struct cpufreq_cooling_device *cpufreq_dev;
  
   - if (event != CPUFREQ_ADJUST || notify_device == NOTIFY_INVALID)
   + if (event != CPUFREQ_ADJUST)
 return 0;
  
   - if (cpumask_test_cpu(policy-cpu, notify_device-allowed_cpus))
   - max_freq = notify_device-cpufreq_val;
   - else
   - return 0;
   + mutex_lock(cooling_cpufreq_lock);
   + list_for_each_entry(cpufreq_dev, cpufreq_dev_list, node) {
   + if (!cpumask_test_cpu(policy

Re: [PATCH 01/21] thermal: of: Extend of-thermal.c to provide number of trip points

[Eduardo Valentin]

Hello Lukasz,

On Thu, Oct 09, 2014 at 06:38:37PM +0200, Lukasz Majewski wrote:
 This patch extends the of-thermal.c to provide information about number of
 available trip points.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/of-thermal.c   | 6 ++
  drivers/thermal/thermal_core.h | 5 +
  2 files changed, 11 insertions(+)
 
 diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
 index f8eb625..b2390d9 100644
 --- a/drivers/thermal/of-thermal.c
 +++ b/drivers/thermal/of-thermal.c
 @@ -113,6 +113,12 @@ static int of_thermal_get_temp(struct 
 thermal_zone_device *tz,
   return data-get_temp(data-sensor_data, temp);
  }
  
 +int of_thermal_get_ntrips(struct thermal_zone_device *tz)
 +{
 + struct __thermal_zone *data = tz-devdata;
 + return data-ntrips;
 +}

I am not against this addition. I just request you to document it
accordingly.

 +
  static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
   enum thermal_trend *trend)
  {
 diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
 index 3db339f..587ca5c 100644
 --- a/drivers/thermal/thermal_core.h
 +++ b/drivers/thermal/thermal_core.h
 @@ -81,9 +81,14 @@ static inline void thermal_gov_user_space_unregister(void) 
 {}
  #ifdef CONFIG_THERMAL_OF
  int of_parse_thermal_zones(void);
  void of_thermal_destroy_zones(void);
 +int of_thermal_get_ntrips(struct thermal_zone_device *);
  #else
  static inline int of_parse_thermal_zones(void) { return 0; }
  static inline void of_thermal_destroy_zones(void) { }
 +static inline int of_thermal_get_ntrips(struct thermal_zone_device *)
 +{
 + return 0;
 +}
  #endif
  
  #endif /* __THERMAL_CORE_H__ */
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH 02/21] thermal: of: Extend of-thermal.c to provide check if trip point is enabled

[Eduardo Valentin]

Hello Lukasz,

On Thu, Oct 09, 2014 at 06:38:38PM +0200, Lukasz Majewski wrote:
 This patch extends the of-thermal.c to provide check if trip point is
 enabled.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/of-thermal.c   | 9 +
  drivers/thermal/thermal_core.h | 5 +
  2 files changed, 14 insertions(+)
 
 diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
 index b2390d9..23c8d6c 100644
 --- a/drivers/thermal/of-thermal.c
 +++ b/drivers/thermal/of-thermal.c
 @@ -119,6 +119,15 @@ int of_thermal_get_ntrips(struct thermal_zone_device *tz)
   return data-ntrips;
  }
  
 +int of_thermal_is_trip_en(struct thermal_zone_device *tz, int trip)
 +{
 + struct __thermal_zone *data = tz-devdata;
 +
 + if (trip = data-ntrips || trip  0)
 + return 0;
 + return 1;

might be worth using 'true' and 'false', just for the sake of code
readability.

 +}
 +


I am not against this addition. I just request you to document it
accordingly.


  static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
   enum thermal_trend *trend)
  {
 diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
 index 587ca5c..ed8ff05 100644
 --- a/drivers/thermal/thermal_core.h
 +++ b/drivers/thermal/thermal_core.h
 @@ -82,6 +82,7 @@ static inline void thermal_gov_user_space_unregister(void) 
 {}
  int of_parse_thermal_zones(void);
  void of_thermal_destroy_zones(void);
  int of_thermal_get_ntrips(struct thermal_zone_device *);
 +int of_thermal_is_trip_en(struct thermal_zone_device *, int);
  #else
  static inline int of_parse_thermal_zones(void) { return 0; }
  static inline void of_thermal_destroy_zones(void) { }
 @@ -89,6 +90,10 @@ static inline int of_thermal_get_ntrips(struct 
 thermal_zone_device *)
  {
   return 0;
  }
 +int of_thermal_is_trip_en(struct thermal_zone_device *, int)
this is supposed to be static inline.

 +{
 + return 0;
 +}
  #endif
  
  #endif /* __THERMAL_CORE_H__ */
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

[Eduardo Valentin]

On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
 This patch extends the of-thermal.c to provide information about number of
 available non critical (i.e. non HW) trip points in the system.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/of-thermal.c   | 12 
  drivers/thermal/thermal_core.h |  5 +
  2 files changed, 17 insertions(+)
 
 diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
 index 23c8d6c..cd74e64 100644
 --- a/drivers/thermal/of-thermal.c
 +++ b/drivers/thermal/of-thermal.c
 @@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct thermal_zone_device 
 *tz, int trip)
   return 1;
  }
  
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
 +{
 + struct __thermal_zone *data = tz-devdata;
 + int i;
 +
 + for (i = 0; i  data-ntrips; i++)
 + if (data-trips[i].type != THERMAL_TRIP_CRITICAL)
 + continue;
 +
 + return --i;
 +}
 +



I am not against this addition. But looks like we start to spread some
specific APIs that may not be used to other drivers. Maybe having a
single API to provide a read-only copy the list / array of trips might
be a better approach. I will think of a better way.

I also request you to document it accordingly.


  static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
   enum thermal_trend *trend)
  {
 diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
 index ed8ff05..334a7be 100644
 --- a/drivers/thermal/thermal_core.h
 +++ b/drivers/thermal/thermal_core.h
 @@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
  void of_thermal_destroy_zones(void);
  int of_thermal_get_ntrips(struct thermal_zone_device *);
  int of_thermal_is_trip_en(struct thermal_zone_device *, int);
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
  #else
  static inline int of_parse_thermal_zones(void) { return 0; }
  static inline void of_thermal_destroy_zones(void) { }
 @@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct thermal_zone_device *, 
 int)
  {
   return 0;
  }
 +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
here, it is supposed to be static inline.

 +{
 + return 0;
 +}
  #endif
  
  #endif /* __THERMAL_CORE_H__ */
 -- 
 2.0.0.rc2
 


signature.asc
Description: Digital signature

Re: [PATCH 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp

[Eduardo Valentin]

Hello,

On Thu, Oct 09, 2014 at 06:38:40PM +0200, Lukasz Majewski wrote:
 Before this change it was only possible to set get_temp() and get_trend()
 methods to be used in the common code handling passing parameters via
 device tree to cpu-thermal CPU thermal zone device.
 
 Now it is possible to also set emulated value of temperature for debug
 purposes.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/of-thermal.c | 25 ++---
  include/linux/thermal.h  |  6 --
  2 files changed, 26 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
 index cd74e64..f206375 100644
 --- a/drivers/thermal/of-thermal.c
 +++ b/drivers/thermal/of-thermal.c
 @@ -98,10 +98,22 @@ struct __thermal_zone {
   void *sensor_data;
   int (*get_temp)(void *, long *);
   int (*get_trend)(void *, long *);
 + int (*set_emul_temp)(void *, unsigned long);
  };
  
  /***   DT thermal zone device callbacks   ***/
  
 +static int of_thermal_set_emul_temp(struct thermal_zone_device *tz,
 + unsigned long temp)
 +{
 + struct __thermal_zone *data = tz-devdata;
 +
 + if (!data-set_emul_temp)
 + return -EINVAL;
 +
 + return data-set_emul_temp(data-sensor_data, temp);
 +}
 +
  static int of_thermal_get_temp(struct thermal_zone_device *tz,
  unsigned long *temp)
  {
 @@ -352,7 +364,8 @@ static struct thermal_zone_device *
  thermal_zone_of_add_sensor(struct device_node *zone,
  struct device_node *sensor, void *data,
  int (*get_temp)(void *, long *),
 -int (*get_trend)(void *, long *))
 +int (*get_trend)(void *, long *),
 +int (*set_emul_temp)(void *, unsigned long))

Thanks for improving the API. However, looking at what is above, it
starts to be pretty ugly. And for sure, this is not the last callback to
be added. I believe it is time to add a .ops in the of-thermal. While in
here, do you mind adding the .ops in a separated patch, then add the
.set_emul_temp in the .ops field?

  {
   struct thermal_zone_device *tzd;
   struct __thermal_zone *tz;
 @@ -366,10 +379,12 @@ thermal_zone_of_add_sensor(struct device_node *zone,
   mutex_lock(tzd-lock);
   tz-get_temp = get_temp;
   tz-get_trend = get_trend;
 + tz-set_emul_temp = set_emul_temp;
   tz-sensor_data = data;
  
   tzd-ops-get_temp = of_thermal_get_temp;
   tzd-ops-get_trend = of_thermal_get_trend;
 + tzd-ops-set_emul_temp = of_thermal_set_emul_temp;
   mutex_unlock(tzd-lock);
  
   return tzd;
 @@ -411,7 +426,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
  struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
   void *data, int (*get_temp)(void *, long *),
 - int (*get_trend)(void *, long *))
 + int (*get_trend)(void *, long *),
 + int (*set_emul_temp)(void *, unsigned long))
  {
   struct device_node *np, *child, *sensor_np;
  
 @@ -453,7 +469,8 @@ thermal_zone_of_sensor_register(struct device *dev, int 
 sensor_id,
   return thermal_zone_of_add_sensor(child, sensor_np,
 data,
 get_temp,
 -   get_trend);
 +   get_trend,
 +   set_emul_temp);
   }
   }
   of_node_put(np);
 @@ -494,9 +511,11 @@ void thermal_zone_of_sensor_unregister(struct device 
 *dev,
   mutex_lock(tzd-lock);
   tzd-ops-get_temp = NULL;
   tzd-ops-get_trend = NULL;
 + tzd-ops-set_emul_temp = NULL;
  
   tz-get_temp = NULL;
   tz-get_trend = NULL;
 + tz-set_emul_temp = NULL;
   tz-sensor_data = NULL;
   mutex_unlock(tzd-lock);
  }
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 0305cde..36010e9 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -290,14 +290,16 @@ struct thermal_genl_event {
  struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int id,
   void *data, int (*get_temp)(void *, long *),
 - int (*get_trend)(void *, long *));
 + int (*get_trend)(void *, long *),
 + int (*set_emul_temp)(void *, unsigned long));
  void thermal_zone_of_sensor_unregister(struct device *dev,
  struct thermal_zone_device *tz);
  #else
  static inline struct thermal_zone_device *
  thermal_zone_of_sensor_register(struct device *dev, int id,

Re: [PATCH] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

[Eduardo Valentin]

Hello Yadwinder,

On Wed, Nov 05, 2014 at 05:46:25PM +0530, Yadwinder Singh Brar wrote:
 Existing code updates cupfreq policy only while executing
 cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID).

Correct. The case you mention is when we receive a notification from
cpufreq. But also, updates the cpufreq policy when the cooling device
changes state, a call from thermal framework.

 It doesn't apply constraints when cpufreq policy update happens from any other
 place but it should update the cpufreq policy with thermal constraints every
 time when there is a cpufreq policy update, to keep state of
 cpufreq_cooling_device and max_feq of cpufreq policy in sync.

I am not sure I follow you here. Can you please elaborate on 'any other
places'? Could you please mention (also in the commit log) what are the
case the current code does not cover? For instance, the
cpufreq_apply_cooling gets called on notification coming from thermal
subsystem, and for changes in cpufreq subsystem,
cpufreq_thermal_notifier is called. 

 
 This patch modifies code to maintain a global cpufreq_dev_list and get
 corresponding cpufreq_cooling_device for policy's cpu from cpufreq_dev_list
 when there is any policy update.

OK. Please give real examples of when the current code fails to catch
the event.


BR,

Eduardo Valentin

 
 Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
 ---
  drivers/thermal/cpu_cooling.c |   37 -
  1 files changed, 20 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
 index 1ab0018..5546278 100644
 --- a/drivers/thermal/cpu_cooling.c
 +++ b/drivers/thermal/cpu_cooling.c
 @@ -50,15 +50,14 @@ struct cpufreq_cooling_device {
   unsigned int cpufreq_state;
   unsigned int cpufreq_val;
   struct cpumask allowed_cpus;
 + struct list_head node;
  };
  static DEFINE_IDR(cpufreq_idr);
  static DEFINE_MUTEX(cooling_cpufreq_lock);
  
  static unsigned int cpufreq_dev_count;
  
 -/* notify_table passes value to the CPUFREQ_ADJUST callback function. */
 -#define NOTIFY_INVALID NULL
 -static struct cpufreq_cooling_device *notify_device;
 +static LIST_HEAD(cpufreq_dev_list);
  
  /**
   * get_idr - function to get a unique id.
 @@ -287,15 +286,12 @@ static int cpufreq_apply_cooling(struct 
 cpufreq_cooling_device *cpufreq_device,
  
   cpufreq_device-cpufreq_state = cooling_state;
   cpufreq_device-cpufreq_val = clip_freq;
 - notify_device = cpufreq_device;
  
   for_each_cpu(cpuid, mask) {
   if (is_cpufreq_valid(cpuid))
   cpufreq_update_policy(cpuid);
   }
  
 - notify_device = NOTIFY_INVALID;
 -
   return 0;
  }
  
 @@ -316,21 +312,27 @@ static int cpufreq_thermal_notifier(struct 
 notifier_block *nb,
  {
   struct cpufreq_policy *policy = data;
   unsigned long max_freq = 0;
 + struct cpufreq_cooling_device *cpufreq_dev;
  
 - if (event != CPUFREQ_ADJUST || notify_device == NOTIFY_INVALID)
 + if (event != CPUFREQ_ADJUST)
   return 0;
  
 - if (cpumask_test_cpu(policy-cpu, notify_device-allowed_cpus))
 - max_freq = notify_device-cpufreq_val;
 - else
 - return 0;
 + mutex_lock(cooling_cpufreq_lock);
 + list_for_each_entry(cpufreq_dev, cpufreq_dev_list, node) {
 + if (!cpumask_test_cpu(policy-cpu,
 + cpufreq_dev-allowed_cpus))
 + continue;
  
 - /* Never exceed user_policy.max */
 - if (max_freq  policy-user_policy.max)
 - max_freq = policy-user_policy.max;
 + max_freq = cpufreq_dev-cpufreq_val;
  
 - if (policy-max != max_freq)
 - cpufreq_verify_within_limits(policy, 0, max_freq);
 + /* Never exceed user_policy.max */
 + if (max_freq  policy-user_policy.max)
 + max_freq = policy-user_policy.max;
 +
 + if (policy-max != max_freq)
 + cpufreq_verify_within_limits(policy, 0, max_freq);
 + }
 + mutex_unlock(cooling_cpufreq_lock);

So, the problem is when we have several cpu cooling devices and you want
to search for the real max among the existing cpu cooling devices?

  
   return 0;
  }
 @@ -486,7 +488,7 @@ __cpufreq_cooling_register(struct device_node *np,
   cpufreq_register_notifier(thermal_cpufreq_notifier_block,
 CPUFREQ_POLICY_NOTIFIER);
   cpufreq_dev_count++;
 -
 + list_add(cpufreq_dev-node, cpufreq_dev_list);
   mutex_unlock(cooling_cpufreq_lock);
  
   return cool_dev;
 @@ -549,6 +551,7 @@ void cpufreq_cooling_unregister(struct 
 thermal_cooling_device *cdev)
  
   cpufreq_dev = cdev-devdata;
   mutex_lock(cooling_cpufreq_lock);
 + list_del(cpufreq_dev-node);
   cpufreq_dev_count--;
  
   /* Unregister the notifier for the last cpufreq cooling device

Re: [PATCH 00/33] thermal: exynos: convert the driver to use per-SoC type operations

[Eduardo Valentin]

Bartlomiej,

On Thu, Sep 18, 2014 at 05:27:17PM +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series replaces the hardware registers abstractions in
 the Exynos thermal driver by the usage of per-SoC type operations.
 Such solution provides simpler, easier to understand code and
 allows removal of ~250 LOCs (~11% of the whole source code) from
 the driver.  Some other driver improvements are now also possible
 thanks to these changes but are scheduled at later time (like
 consolidating code for clearing IRQs using INTCLEAR register).
 
 The patchset should not cause any functionality changes.  This
 means that unless there are some bugs in the patches itself there
 should be no behavior changes for the driver (this also includes
 lack of changes in the way hardware is accessed by the driver).
 
 All testing was done on (Exynos4412 SoC based) ODROID U3 board
 (some additional patches are needed to make the Exynos thermal
 driver work on this hardware).
 
 Depends on:
 - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo
 - [PATCH] thermal: exynos: use correct offset for TMU_CONTROL
   register on Exynos5260
   
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36529.html)
 

Could you please refresh this series?

I checked until patch 09, but patch 10 fails to apply:
patching file drivers/thermal/samsung/exynos_tmu.c
Hunk #1 succeeded at 414 (offset 15 lines).
patching file drivers/thermal/samsung/exynos_tmu.h
Hunk #1 succeeded at 92 with fuzz 2 (offset -4 lines).
Hunk #2 succeeded at 117 (offset -8 lines).
patching file drivers/thermal/samsung/exynos_tmu_data.c
Hunk #1 FAILED at 422.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/thermal/samsung/exynos_tmu_data.c.rej

I also have in my local tree the dependency patch you mention above.

Cheers,

 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (33):
   thermal: exynos: remove needless triminfo_data abstraction
   thermal: exynos: remove needless tmu_status abstraction
   thermal: exynos: remove needless threshold_temp abstraction
   thermal: exynos: remove needless triminfo_ctrl abstraction
   thermal: exynos: remove needless test_mux_addr_shift abstraction
   thermal: exynos: remove needless therm_trip_[mode,mask]_shift
 abstractions
   thermal: exynos: remove needless therm_trip_en_shift abstraction
   thermal: exynos: remove needless emul_temp_shift abstraction
   thermal: exynos: remove needless emul_time_shift abstraction
   thermal: exynos: replace tmu_irqstatus check by Exynos5440 one
   thermal: exynos: replace tmu_pmin check by Exynos5440 one
   thermal: exynos: simplify HW_TRIP level setting
   thermal: exynos: replace threshold_falling check by Exynos SoC type
 one
   thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag
   thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag
   thermal: exynos: add sanitize_temp_error() helper
   thermal: exynos: add get_th_reg() helper
   thermal: exynos: add -tmu_initialize method
   thermal: exynos: add get_con_reg() helper
   thermal: exynos: add -tmu_control method
   thermal: exynos: add -tmu_read method
   thermal: exynos: add get_emul_con_reg() helper
   thermal: exynos: add -tmu_set_emulation method
   thermal: exynos: add -tmu_clear_irqs method
   thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag
   thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag
   thermal: exynos: remove TMU_SUPPORT_EMULATION flag
   thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag
   thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag
   thermal: exynos: remove test_mux pdata field
   thermal: exynos: remove SoC type ifdefs
   thermal: exynos: remove __EXYNOS5420_TMU_DATA macro
   thermal: exynos: remove exynos_tmu_data.h include
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 706 
 +---
  drivers/thermal/samsung/exynos_tmu.h| 131 +
  drivers/thermal/samsung/exynos_tmu_data.c   | 260 +
  drivers/thermal/samsung/exynos_tmu_data.h   | 174 --
  5 files changed, 509 insertions(+), 763 deletions(-)
  delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.h
 
 -- 
 1.8.2.3
 


signature.asc
Description: Digital signature

Re: [PATCHv6 0/2] thermal: exynos: Add support for TRIMINFO feature of Exynos3250

[Eduardo Valentin]

Hi,

On Wed, Sep 03, 2014 at 12:09:01PM +0900, Chanwoo Choi wrote:
 This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250.
 But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only 
 one
 TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which
 has more than one TRIMINF_CTRL.
 
 Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove
 duplicate code when reading triminfo register of Exynos5440.
 
 Changes from v5:
 - Rebase this patchset on next branch of linux-soc-thermal.git
 

Pulled into my next branch. Thanks.

 Changes from v4:
 - Remove un-necessary triminfo_ctrl_{shift, mask} field
 - Includes Bartlomiej's patch[1] that Exynos5260 / Exynos5420 should not use
 TRIM_RELOAD flag
 [2] https://lkml.org/lkml/2014/8/20/481
 
 Changes from v3:
 - Add reviewed message of Amit Daniel Kachhap amit.dan...@samsung.com
 - Split RELOAD patch as two patch
 - Fix 'TRIMINFO_RELOAD_SHIFT' value
 - This series includes separate patch[1]
 [1] https://lkml.org/lkml/2014/8/20/5
 - Drop ACTIME bit setting because TRM includes not enough information of 
 ACTIME bit.
 
 Changes from v2:
 - Fix build break because of missing 'or' operation.
 
 Changes from v1:
 - Add missing 'TMU_SUPPORT_TRIM_RELOAD' features
 
 Chanwoo Choi (2):
   thermal: exynos: Add support for many TRIMINFO_CTRL registers
   thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
 
  drivers/thermal/samsung/exynos_thermal_common.h |  1 +
  drivers/thermal/samsung/exynos_tmu.c| 15 ---
  drivers/thermal/samsung/exynos_tmu.h|  7 +--
  drivers/thermal/samsung/exynos_tmu_data.c   | 11 +--
  drivers/thermal/samsung/exynos_tmu_data.h   |  8 ++--
  5 files changed, 33 insertions(+), 9 deletions(-)
 
 -- 
 1.8.0
 
 --
 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/8] thermal: exynos: various cleanups

[Eduardo Valentin]

On Mon, Sep 01, 2014 at 07:05:27AM -0400, edubez...@gmail.com wrote:
 Amit
 
 On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap
 amit.dan...@samsung.com wrote:
  On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin edubez...@gmail.com 
  wrote:
  Amit,
 
  On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote:
  Hi,
 
  This patch series contains various cleanups for EXYNOS thermal
  driver.  Overall it decreases driver's LOC by 9%.  It is based
  on next-20140731 kernel.  It should not cause any functionality
  changes.
 
 
  Did you have the time to test this series?
 
  Hi Eduardo/Bartlomiej,
 
  For the whole series tested on exynos5250 based arndale board.
  Tested-by: Amit Daniel Kachhap amit.dan...@samsung.com
 
 
 Thanks! I will pull the series on my tree.


Pulled into my next branch. Thanks.

 
 
  Sorry for the delay as I was busy in some internal work.
 
  Thanks,
  Amit D
 
  Changes since v2 (https://lkml.org/lkml/2014/6/17/436):
  - synced patches against next-20140731
  - dropped patch thermal: exynos: remove dead code for
TYPE_TWO_POINT_TRIMMING calibration (newly added Exynos3250
SoC support uses TYPE_TWO_POINT_TRIMMING calibration)
  - updated patch description for patch #2
  - dropped Reviewed-by from Amit from patch #8 (due to changed
scope of the patch)
 
  Changes since v1 (https://lkml.org/lkml/2014/5/5/194):
  - synced patches against next-20140617
  - merged patch thermal: exynos: remove unused defines into
thermal: exynos: remove unused struct exynos_tmu_registers
entries one (per request from Eduardo)
  - improved patch descriptions for patches #1-5
  - fixed documentation for pdata-gain and pdata-reference_voltage
  - added Reviewed-by from Amit to patches #6, #7 and #10
  - added missing Acked-by from Kyungmin Park
 
  Best regards,
  --
  Bartlomiej Zolnierkiewicz
  Samsung RD Institute Poland
  Samsung Electronics
 
 
  Bartlomiej Zolnierkiewicz (8):
thermal: exynos: remove unused struct exynos_tmu_registers entries
thermal: exynos: remove dead code for HW_MODE calibration
thermal: exynos: remove redundant pdata checks from
  exynos_tmu_initialize()
thermal: exynos: remove redundant threshold_code checks from
  exynos_tmu_initialize()
thermal: exynos: simplify temp_to_code() and code_to_temp()
thermal: exynos: cache non_hw_trigger_levels in pdata
thermal: exynos: remove redundant pdata checks from
  exynos_tmu_control()
thermal: exynos: remove identical values from exynos*_tmu_registers
  structures
 
   drivers/thermal/samsung/exynos_thermal_common.h |   1 -
   drivers/thermal/samsung/exynos_tmu.c| 126 
  +---
   drivers/thermal/samsung/exynos_tmu.h|  74 +-
   drivers/thermal/samsung/exynos_tmu_data.c   |  56 ++-
   drivers/thermal/samsung/exynos_tmu_data.h   |  31 +-
   5 files changed, 35 insertions(+), 253 deletions(-)
 
  --
  1.8.2.3
 
  --
  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
  --
  To unsubscribe from this list: send the line unsubscribe 
  linux-samsung-soc in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
 
 -- 
 Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440

[Eduardo Valentin]

Chanwoo,

On Fri, Aug 29, 2014 at 08:50:41AM +0900, Chanwoo Choi wrote:
 Dear Eduardo,
 
 On 08/28/2014 11:53 PM, Eduardo Valentin wrote:
  On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote:
  Dear Eduardo,
 
  This patch is wrong. It is my mistake.
 
  Please ignore only this patch because
  the offset calculation of 'case 0' is different from 'case 2'.
  
  
  Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be
  a common agreement. 

 
 Yes, patches 1 - 3 are correct.
 

OK. I pulled patch 01 into my next branch.

Can you please update patches 02 and 03 based on my next brach? They are
conflicting with the massive cleanups done by Bartlomiej (Thanks
Bartlomiej). So, please, resend patches 02 and 03 only, refreshed onto
my next branch.

Cheers.

 Best Regards,
 Chanwoo Choi
 
  
 
  Best Regards,
  Chanwoo Choi
 
  On 08/26/2014 10:31 AM, Chanwoo Choi wrote:
  This patch remove simply duplicate code when reading triminfo register of 
  Exynos5440.
 
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  Acked-by: Kyungmin Park kyungmin.p...@samsung.com
  Cc: Zhang Rui rui.zh...@intel.com
  Cc: Eduardo Valentin edubez...@gmail.com
  Cc: Amit Daniel Kachhap amit.dan...@samsung.com
  Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)
 
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index 64c702a..5888467 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct 
  platform_device *pdev)
 */
switch (data-id) {
case 0:
  + case 2:
trim_info = readl(data-base +
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
break;
case 1:
trim_info = readl(data-base + reg-triminfo_data);
break;
  - case 2:
  - trim_info = readl(data-base -
  - EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
/* On exynos5420 the triminfo register is in the shared space */
 
 
  
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/8] thermal: exynos: various cleanups

[Eduardo Valentin]

Amit,

On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series contains various cleanups for EXYNOS thermal
 driver.  Overall it decreases driver's LOC by 9%.  It is based
 on next-20140731 kernel.  It should not cause any functionality
 changes.
 

Did you have the time to test this series?

 Changes since v2 (https://lkml.org/lkml/2014/6/17/436):
 - synced patches against next-20140731
 - dropped patch thermal: exynos: remove dead code for
   TYPE_TWO_POINT_TRIMMING calibration (newly added Exynos3250
   SoC support uses TYPE_TWO_POINT_TRIMMING calibration)
 - updated patch description for patch #2
 - dropped Reviewed-by from Amit from patch #8 (due to changed
   scope of the patch)
 
 Changes since v1 (https://lkml.org/lkml/2014/5/5/194):
 - synced patches against next-20140617
 - merged patch thermal: exynos: remove unused defines into
   thermal: exynos: remove unused struct exynos_tmu_registers
   entries one (per request from Eduardo)
 - improved patch descriptions for patches #1-5
 - fixed documentation for pdata-gain and pdata-reference_voltage
 - added Reviewed-by from Amit to patches #6, #7 and #10
 - added missing Acked-by from Kyungmin Park
 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (8):
   thermal: exynos: remove unused struct exynos_tmu_registers entries
   thermal: exynos: remove dead code for HW_MODE calibration
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_initialize()
   thermal: exynos: remove redundant threshold_code checks from
 exynos_tmu_initialize()
   thermal: exynos: simplify temp_to_code() and code_to_temp()
   thermal: exynos: cache non_hw_trigger_levels in pdata
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_control()
   thermal: exynos: remove identical values from exynos*_tmu_registers
 structures
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 126 
 +---
  drivers/thermal/samsung/exynos_tmu.h|  74 +-
  drivers/thermal/samsung/exynos_tmu_data.c   |  56 ++-
  drivers/thermal/samsung/exynos_tmu_data.h   |  31 +-
  5 files changed, 35 insertions(+), 253 deletions(-)
 
 -- 
 1.8.2.3
 
 --
 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440

[Eduardo Valentin]

On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote:
 Dear Eduardo,
 
 This patch is wrong. It is my mistake.
 
 Please ignore only this patch because
 the offset calculation of 'case 0' is different from 'case 2'.


Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be
a common agreement. 

 
 Best Regards,
 Chanwoo Choi
 
 On 08/26/2014 10:31 AM, Chanwoo Choi wrote:
  This patch remove simply duplicate code when reading triminfo register of 
  Exynos5440.
  
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  Acked-by: Kyungmin Park kyungmin.p...@samsung.com
  Cc: Zhang Rui rui.zh...@intel.com
  Cc: Eduardo Valentin edubez...@gmail.com
  Cc: Amit Daniel Kachhap amit.dan...@samsung.com
  Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)
  
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index 64c702a..5888467 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct 
  platform_device *pdev)
   */
  switch (data-id) {
  case 0:
  +   case 2:
  trim_info = readl(data-base +
  EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
  break;
  case 1:
  trim_info = readl(data-base + reg-triminfo_data);
  break;
  -   case 2:
  -   trim_info = readl(data-base -
  -   EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
  }
  } else {
  /* On exynos5420 the triminfo register is in the shared space */
  
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thermal: samsung: Exynos5260 and Exynos5420 should not use TRIM_RELOAD flag

[Eduardo Valentin]

Hello Bartlomiej,

On Wed, Aug 20, 2014 at 02:04:18PM +0200, Bartlomiej Zolnierkiewicz wrote:
 Currently these SoCs claim TRIM_RELOAD support but don't have
 triminfo_ctrl register address defined in their struct
 exynos_tmu_registers entries.  This causes incorrect write of
 value 1 to data-base + 0x00 address (which happens to be
 TRIMINFO register).  Fix it by removing TMU_SUPPORT_TRIM_RELOAD
 flag for Exynos5260 and Exynos5420

Do the Exynos5260 and Exynos5420 hardwares support TRIM_RELOAD?

Based on the above description, you state that they lack the definition
in their struct exynos_tmu_register. But that does not mean necessarily
that they do not support it right?

If they support the TRIM_RELOAD feature, then please add the proper
triminfo_ctrl entry in their exynos_tmu_registers.

But If they do not support TRIM_RELOAD, please, keep the changes below,
but improve the commit message, simply stating that these SoC do not
support TRIM_RELOAD.

 
 Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Cc: Chanwoo Choi cw00.c...@samsung.com
 Cc: Amit Daniel Kachhap amit.dan...@samsung.com
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu_data.c | 16 +++-
  1 file changed, 7 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index aa8e0de..8c0ada2 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -359,9 +359,8 @@ static const struct exynos_tmu_registers 
 exynos5260_tmu_registers = {
  #define EXYNOS5260_TMU_DATA \
   __EXYNOS5260_TMU_DATA \
   .type = SOC_ARCH_EXYNOS5260, \
 - .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
 - TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
 - TMU_SUPPORT_EMUL_TIME)
 + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
 + TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME)
  
  struct exynos_tmu_init_data const exynos5260_default_tmu_data = {
   .tmu_data = {
 @@ -451,16 +450,15 @@ static const struct exynos_tmu_registers 
 exynos5420_tmu_registers = {
  #define EXYNOS5420_TMU_DATA \
   __EXYNOS5420_TMU_DATA \
   .type = SOC_ARCH_EXYNOS5250, \
 - .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
 - TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
 - TMU_SUPPORT_EMUL_TIME)
 + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
 + TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME)
  
  #define EXYNOS5420_TMU_DATA_SHARED \
   __EXYNOS5420_TMU_DATA \
   .type = SOC_ARCH_EXYNOS5420_TRIMINFO, \
 - .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
 - TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
 - TMU_SUPPORT_EMUL_TIME | TMU_SUPPORT_ADDRESS_MULTIPLE)
 + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
 + TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME | \
 + TMU_SUPPORT_ADDRESS_MULTIPLE)
  
  struct exynos_tmu_init_data const exynos5420_default_tmu_data = {
   .tmu_data = {
 -- 
 1.8.2.3
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eduardo Valentin]

On Mon, Jul 28, 2014 at 08:30:53PM +0530, amit daniel kachhap wrote:
 Hi Eduardo,

Hello Amit,

 
 Please reject this entire series as this is not re-based recently.
 Actually two point trimming which this series seeks to remove is used
 by exynos3250 and is in Rui's tree
 (https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=nextid=1fe56dc16a3dab400206443f70ae158c8f595c42).
 

Yeah, that was my original concern when I first looked this series.
However, as I saw a couple of your acks I thought you would be in sync
with Bartlomiej. 

I agree with Bartlomiej that we need to keep the kernel code in very
good shape, but if we are removing features for the sake of reducing
LOCs and we end up dropping support to known chips, I definitely won't
agree. 

Can you guys please reach a common agreement on these cleanups?

Bartlomiej, best thing to do is to sync your work on top of Rui's tree.

For now I am dropping this series from my -next branch. :-(

 Thanks,
 Amit D
 
 
 On Mon, Jul 28, 2014 at 8:07 PM, Eduardo Valentin edubez...@gmail.com wrote:
  On Tue, Jun 17, 2014 at 07:27:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
  Hi,
 
  This patch series contains various cleanups for EXYNOS thermal
  driver.  Overall it decreases driver's LOC by 12%.  It is based
  on next-20140617 kernel.  It should not cause any functionality
  changes.
 
  Changes since v1:
  - synced patches against next-20140617
  - merged patch thermal: exynos: remove unused defines into
thermal: exynos: remove unused struct exynos_tmu_registers
entries one (per request from Eduardo)
  - improved patch descriptions for patches #1-5
  - fixed documentation for pdata-gain and pdata-reference_voltage
  - added Reviewed-by from Amit to patches #6, #7 and #10
  - added missing Acked-by from Kyungmin Park
 
  Pulled the series.
 
  Thanks.
 
 
  Best regards,
  --
  Bartlomiej Zolnierkiewicz
  Samsung RD Institute Poland
  Samsung Electronics
 
 
  Bartlomiej Zolnierkiewicz (9):
thermal: exynos: remove unused struct exynos_tmu_registers entries
thermal: exynos: remove dead code for HW_MODE calibration
thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
  calibration
thermal: exynos: remove redundant pdata checks from
  exynos_tmu_initialize()
thermal: exynos: remove redundant threshold_code checks from
  exynos_tmu_initialize()
thermal: exynos: simplify temp_to_code() and code_to_temp()
thermal: exynos: cache non_hw_trigger_levels in pdata
thermal: exynos: remove redundant pdata checks from
  exynos_tmu_control()
thermal: exynos: remove identical values from exynos*_tmu_registers
  structures
 
   drivers/thermal/samsung/exynos_thermal_common.h |   1 -
   drivers/thermal/samsung/exynos_tmu.c| 181 
  
   drivers/thermal/samsung/exynos_tmu.h|  90 +---
   drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
   drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
   5 files changed, 41 insertions(+), 328 deletions(-)
 
  --
  1.8.2.3
 
  --
  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
  --
  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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Eduardo Valentin]

On Tue, Jul 29, 2014 at 11:17:10AM +0900, Chanwoo Choi wrote:
 This patch add TMU (Thermal Management Unit) dt node to monitor the high
 temperature for Exynos3250.
 
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Eduardo Valentin edubez...@gmail.com

 ---
 This patch has a dependency on following patch [1] which supporting the TMU
 of Exynos3250:
  [1] 
 https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=nextid=1fe56dc16a3dab400206443f70ae158c8f595c42
 
 Changes from v1:
 - Remove duplicate 'interrupt-parent' property.
 
  arch/arm/boot/dts/exynos3250.dtsi | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 77a06df..41a260a 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -168,6 +168,15 @@
   status = disabled;
   };
  
 + tmu: tmu@100C {
 + compatible = samsung,exynos3250-tmu;
 + reg = 0x100C 0x100;
 + interrupts = 0 216 0;
 + clocks = cmu CLK_TMU_APBIF;
 + clock-names = tmu_apbif;
 + status = disabled;
 + };
 +
   gic: interrupt-controller@10481000 {
   compatible = arm,cortex-a15-gic;
   #interrupt-cells = 3;
 -- 
 1.8.0
 
 --
 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/
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC

[Eduardo Valentin]

On Tue, Jul 22, 2014 at 11:41:56AM +0530, amit daniel kachhap wrote:
 On Mon, Jul 21, 2014 at 11:34 AM, Zhang Rui rui.zh...@intel.com wrote:
  On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
  This patch adds the registers, bit fields and compatible strings
  required to support for the 1 TMU channels on Exynos3250.
 
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  [Add MUX address setting bits by Jonghwa Lee]
  Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
  Acked-by: Kyungmin Park kyungmin.p...@samsung.com
  Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
 
  Eduardo and Amit,
 
  do you have any comments on this?
 The changes looks fine to me. I already reviewed these patches earlier.


Bartlomiej, can you please rebase your work on top of this one?

 
 thanks,
 Amit
 
  thanks,
  rui
 
  ---
   .../devicetree/bindings/thermal/exynos-thermal.txt |  1 +
   drivers/thermal/samsung/exynos_tmu.c   |  7 +-
   drivers/thermal/samsung/exynos_tmu.h   |  3 +-
   drivers/thermal/samsung/exynos_tmu_data.c  | 89 
  ++
   drivers/thermal/samsung/exynos_tmu_data.h  |  7 ++
   5 files changed, 105 insertions(+), 2 deletions(-)
 
  diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
  b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  index c949092..ae738f5 100644
  --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  @@ -3,6 +3,7 @@
   ** Required properties:
 
   - compatible : One of the following:
  +samsung,exynos3250-tmu
   samsung,exynos4412-tmu
   samsung,exynos4210-tmu
   samsung,exynos5250-tmu
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index d7ca9f4..a2a08ea 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -505,6 +505,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
 
   static const struct of_device_id exynos_tmu_match[] = {
{
  + .compatible = samsung,exynos3250-tmu,
  + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
  + },
  + {
.compatible = samsung,exynos4210-tmu,
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
  @@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device 
  *pdev)
goto err_clk_sec;
}
 
  - if (pdata-type == SOC_ARCH_EXYNOS4210 ||
  + if (pdata-type == SOC_ARCH_EXYNOS3250 ||
  + pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5260 ||
  diff --git a/drivers/thermal/samsung/exynos_tmu.h 
  b/drivers/thermal/samsung/exynos_tmu.h
  index edd08cf..1b4a644 100644
  --- a/drivers/thermal/samsung/exynos_tmu.h
  +++ b/drivers/thermal/samsung/exynos_tmu.h
  @@ -40,7 +40,8 @@ enum calibration_mode {
   };
 
   enum soc_type {
  - SOC_ARCH_EXYNOS4210 = 1,
  + SOC_ARCH_EXYNOS3250 = 1,
  + SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
  diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
  b/drivers/thermal/samsung/exynos_tmu_data.c
  index c1d81dc..aa8e0de 100644
  --- a/drivers/thermal/samsung/exynos_tmu_data.c
  +++ b/drivers/thermal/samsung/exynos_tmu_data.c
  @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const 
  exynos4210_default_tmu_data = {
   };
   #endif
 
  +#if defined(CONFIG_SOC_EXYNOS3250)
  +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
  + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
  + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
  + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
  + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
  + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
  + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
  + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
  + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
  + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
  + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
  + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
  + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
  + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
  + .tmu_status = EXYNOS_TMU_REG_STATUS,
  + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
  + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
  + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
  + .tmu_inten = EXYNOS_TMU_REG_INTEN,
  + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
  + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
  + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
  + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
  + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
  +   

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

[Eduardo Valentin]

On Tue, Jun 17, 2014 at 07:27:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series contains various cleanups for EXYNOS thermal
 driver.  Overall it decreases driver's LOC by 12%.  It is based
 on next-20140617 kernel.  It should not cause any functionality
 changes.
 
 Changes since v1:
 - synced patches against next-20140617
 - merged patch thermal: exynos: remove unused defines into
   thermal: exynos: remove unused struct exynos_tmu_registers
   entries one (per request from Eduardo)
 - improved patch descriptions for patches #1-5
 - fixed documentation for pdata-gain and pdata-reference_voltage
 - added Reviewed-by from Amit to patches #6, #7 and #10
 - added missing Acked-by from Kyungmin Park

Pulled the series.

Thanks.

 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (9):
   thermal: exynos: remove unused struct exynos_tmu_registers entries
   thermal: exynos: remove dead code for HW_MODE calibration
   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
 calibration
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_initialize()
   thermal: exynos: remove redundant threshold_code checks from
 exynos_tmu_initialize()
   thermal: exynos: simplify temp_to_code() and code_to_temp()
   thermal: exynos: cache non_hw_trigger_levels in pdata
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_control()
   thermal: exynos: remove identical values from exynos*_tmu_registers
 structures
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 181 
 
  drivers/thermal/samsung/exynos_tmu.h|  90 +---
  drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
  drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
  5 files changed, 41 insertions(+), 328 deletions(-)
 
 -- 
 1.8.2.3
 
 --
 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] thermal: exynos: remove unused defines

[Eduardo Valentin]

On Mon, May 05, 2014 at 01:15:31PM +0200, Bartlomiej Zolnierkiewicz wrote:
 There should be no functional changes caused by this patch.

This patch can be merged to patch 01.


 
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu_data.h | 27 +--
  1 file changed, 1 insertion(+), 26 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
 b/drivers/thermal/samsung/exynos_tmu_data.h
 index 06c4345..d4eeddb 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.h
 +++ b/drivers/thermal/samsung/exynos_tmu_data.h
 @@ -42,20 +42,8 @@
  /* 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
 @@ -69,8 +57,6 @@
  #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_THERM_TRIP_EN_SHIFT   12
 @@ -82,8 +68,6 @@
  #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 EXYNOS_EMUL_TIME 0x57F0
  #define EXYNOS_EMUL_TIME_MASK0x
 @@ -107,13 +91,11 @@
  #define EXYNOS5440_TMU_S0_7_TH0  0x110
  #define EXYNOS5440_TMU_S0_7_TH1  0x130
  #define EXYNOS5440_TMU_S0_7_TH2  0x150
 -#define EXYNOS5440_TMU_S0_7_EVTEN0x1F0
  #define 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
 @@ -124,13 +106,6 @@
  #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
  
 -- 
 1.8.2.3
 
 --
 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html