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

2012-09-20 Thread jonghwa3 . lee
Hi, Amit,
On 2012년 08월 16일 20:41, Amit Daniel Kachhap wrote:

  diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
  new file mode 100644
  index 000..66cbd52
  --- /dev/null
  +++ b/drivers/thermal/cpu_cooling.c
  @@ -0,0 +1,586 @@

  +/**
  + * cpufreq_cooling_register - function to create cpufreq cooling device.
  + * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
  + */
  +struct thermal_cooling_device *cpufreq_cooling_register(
  +   struct cpumask *clip_cpus)
  +{
  +   struct thermal_cooling_device *cool_dev;
  +   struct cpufreq_cooling_device *cpufreq_dev = NULL;
  +   unsigned int cpufreq_dev_count = 0, min = 0, max = 0;
  +   char dev_name[THERMAL_NAME_LENGTH];
  +   int ret = 0, id = 0, i;
  +   struct cpufreq_policy policy;
  +   ret = get_idr(cpufreq_idr,cpufreq_dev-id);
  +   if (ret) {
  +   kfree(cpufreq_dev);
  +   return ERR_PTR(-EINVAL);
  +   }
  +
  +   sprintf(dev_name, thermal-cpufreq-%d, cpufreq_dev-id);
  +
  +   cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
  +cpufreq_cooling_ops);
  +   if (!cool_dev) {
  +   release_idr(cpufreq_idr, cpufreq_dev-id);
  +   kfree(cpufreq_dev);
  +   return ERR_PTR(-EINVAL);
  +   }
  +   cpufreq_dev-id = id;


Why is this needed? Should every cpufreq_dev instance's id be same for
zero? It looks odd. And it also has problem which can be occurred when
it release id during unregistering cpufreq_dev. I think it should keep
the idr value taken before.


  1.7.1

 --
 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: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

2012-08-20 Thread Valentin, Eduardo
Hello Rui,

On Mon, Aug 20, 2012 at 5:16 AM, Zhang Rui rui.zh...@intel.com wrote:
 On 五, 2012-08-17 at 11:56 +0300, Valentin, Eduardo wrote:
 Hello,

  +
  +
  +1.2 CPU cooling action notifier register/unregister interface
  +1.2.1 int cputherm_register_notifier(struct notifier_block *nb,
  + unsigned int list)
  +
  +This interface registers a driver with cpu cooling layer. The 
  driver will
  +be notified when any cpu cooling action is called.
  +
  +nb: notifier function to register
  +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
  +
  +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb,
  + unsigned int list)
  +
  +This interface registers a driver with cpu cooling layer. The 
  driver will
  +be notified when any cpu cooling action is called.
  +
  +nb: notifier function to register
  +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
 
  what are these two APIs used for?
  I did not see they are used in your patch set, do I miss something?
  No currently they are not used by my patches. I added them on request
  from Eduardo and others

 Yeah, this was a suggestion as we didn't really know how the FW part
 would evolve by that time.

 The reasoning is to allow any interested user (in kernel) to be
 notified when max frequency changes.

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

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

Agreed. The context is actually much wider than the CPU cooling. In
fact, cooling co-processors is actually where things gets a bit
complicated. The idea behind this type of handshaking is to allow the
affected subsystem to change their actual setup when max performance
is not allowed anymore.


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

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


Yeah. Ideally, the framework needs to be aware of cooling device state
change. Today, as we have pretty much a broadcast/unidirectional type
of messaging, the framework/policy always assumes the cooling devices
will be in sync with what it is dictated by the policy.

  Ideally it would be possible to nack the cooling
 transition. But that is yet a wider discussion. So far we don't have
 users for this.

 yep.
 I thought about this before, but I'd prefer to do this when there is a
 real user. Or else, we are kind of over-designing here.
 how about removing this piece of code for now?


Agreed. I second you that this problem is a much wider issue and needs
improvement in the FW itself and how the cooling devices are designed.


 thanks,
 rui

 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index 7dd8c34..996003b 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -19,6 +19,17 @@ config THERMAL_HWMON
depends on HWMON=y || HWMON=THERMAL
default y
 
  +config CPU_THERMAL
  + bool generic cpu cooling support
  + depends on THERMAL  CPU_FREQ
  + help
  +   This implements the generic cpu cooling mechanism through 
  frequency
  +   reduction, cpu hotplug and any other ways of reducing 
  temperature. An
  +   ACPI version of this already 
  exists(drivers/acpi/processor_thermal.c).
  +   This will be useful for platforms using the generic thermal 
  interface
  +   and not the ACPI interface.
  +   If you want this support, you should say Y here.
  +
   config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on THERMAL
  diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
  index fd9369a..aae59ad 100644
  --- a/drivers/thermal/Makefile
  +++ b/drivers/thermal/Makefile
  @@ -3,5 +3,6 @@
   #
 
   obj-$(CONFIG_THERMAL)+= thermal_sys.o
  +obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
   obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
   obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
  diff --git a/drivers/thermal/cpu_cooling.c 
  b/drivers/thermal/cpu_cooling.c
  new file mode 100644
  index 000..c42e557
  --- /dev/null
  +++ b/drivers/thermal/cpu_cooling.c
  @@ -0,0 +1,512 @@
  +/*
  + *  linux/drivers/thermal/cpu_cooling.c
  + *
  + *  Copyright (C) 2012   Samsung Electronics Co., 
  Ltd(http://www.samsung.com)
  + *  Copyright (C) 2012  Amit Daniel amit.kach...@linaro.org
  + *
  + * 
  

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

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

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

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

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

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

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

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

thanks,
rui

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

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

2012-08-17 Thread Zhang Rui
On 四, 2012-08-16 at 17:11 +0530, Amit Daniel Kachhap wrote:
 This patchset introduces a new generic cooling device based on cpufreq
 that can be used on non-ACPI platforms.  As a proof of concept, we have
 drivers for the following platforms using this mechanism now:
 
  * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
  * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git 
 imx6q_thermal)
 
 There is a small change in cpufreq cooling registration APIs, so a minor
 change is needed for Freescale platforms.
 
 Brief Description:
 
 1) The generic cooling devices code is placed inside driver/thermal/*
as placing inside acpi folder will need un-necessary enabling of acpi
code.  This code is architecture independent.
 
 2) This patchset adds generic cpu cooling low level implementation
through frequency clipping.  In future, other cpu related cooling
devices may be added here.  An ACPI version of this already exists
(drivers/acpi/processor_thermal.c) .But this will be useful for
platforms like ARM using the generic thermal interface along with the
generic cpu cooling devices.  The cooling device registration API's
return cooling device pointers which can be easily binded with the
thermal zone trip points.  The important APIs exposed are,
 
a) struct thermal_cooling_device *cpufreq_cooling_register(
 struct cpumask *clip_cpus)
b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 
 3) Samsung exynos platform thermal implementation is done using the
generic cpu cooling APIs and the new trip type.  The temperature sensor
driver present in the hwmon folder(registered as hwmon driver) is moved
to thermal folder and registered as a thermal driver.
 
 A simple data/control flow diagrams is shown below,
 
 Core Linux thermal -  Exynos thermal interface - Temperature Sensor
   | |
  \|/|
   Cpufreq cooling device ---
 
 TODO:
 *Will send the DT enablement patches later after the driver is merged.
 
 This patch:
 
 Add support for generic cpu thermal cooling low level implementations
 using frequency scaling up/down based on the registration parameters.
 Different cpu related cooling devices can be registered by the user and
 the binding of these cooling devices to the corresponding trip points can
 be easily done as the registration APIs return the cooling device pointer.
 The user of these APIs are responsible for passing clipping frequency .
 The drivers can also register to recieve notification about any cooling
 action called.
 
 [a...@linux-foundation.org: fix comment layout]
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 Cc: Guenter Roeck guenter.ro...@ericsson.com
 Cc: SangWook Ju sw...@samsung.com
 Cc: Durgadoss durgados...@intel.com
 Cc: Len Brown l...@kernel.org
 Cc: Jean Delvare kh...@linux-fr.org
 Cc: Kyungmin Park kmp...@infradead.org
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  Documentation/thermal/cpu-cooling-api.txt |   52 +++
  drivers/thermal/Kconfig   |   11 +
  drivers/thermal/Makefile  |1 +
  drivers/thermal/cpu_cooling.c |  512 
 +
  include/linux/cpu_cooling.h   |   79 +
  5 files changed, 655 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
  create mode 100644 drivers/thermal/cpu_cooling.c
  create mode 100644 include/linux/cpu_cooling.h
 
 diff --git a/Documentation/thermal/cpu-cooling-api.txt 
 b/Documentation/thermal/cpu-cooling-api.txt
 new file mode 100644
 index 000..a1f2a6b
 --- /dev/null
 +++ b/Documentation/thermal/cpu-cooling-api.txt
 @@ -0,0 +1,52 @@
 +CPU cooling APIs How To
 +===
 +
 +Written by Amit Daniel Kachhap amit.kach...@linaro.org
 +
 +Updated: 12 May 2012
 +
 +Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
 +
 +0. Introduction
 +
 +The generic cpu cooling(freq clipping) provides registration/unregistration 
 APIs
 +to the caller. The binding of the cooling devices to the trip point is left 
 for
 +the user. The registration APIs returns the cooling device pointer.
 +
 +1. cpu cooling APIs
 +
 +1.1 cpufreq registration/unregistration APIs
 +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
 + struct cpumask *clip_cpus)
 +
 +This interface function registers the cpufreq cooling device with the 
 name
 +thermal-cpufreq-%x. This api can support multiple instances of cpufreq
 +cooling devices.
 +
 +   clip_cpus: cpumask of cpus where the frequency constraints will happen.
 +
 +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 +
 +This interface function unregisters the thermal-cpufreq-%x cooling 

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

2012-08-17 Thread Amit Kachhap
On 17 August 2012 12:54, Zhang Rui rui.zh...@intel.com wrote:
 On 四, 2012-08-16 at 17:11 +0530, Amit Daniel Kachhap wrote:
 This patchset introduces a new generic cooling device based on cpufreq
 that can be used on non-ACPI platforms.  As a proof of concept, we have
 drivers for the following platforms using this mechanism now:

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

 There is a small change in cpufreq cooling registration APIs, so a minor
 change is needed for Freescale platforms.

 Brief Description:

 1) The generic cooling devices code is placed inside driver/thermal/*
as placing inside acpi folder will need un-necessary enabling of acpi
code.  This code is architecture independent.

 2) This patchset adds generic cpu cooling low level implementation
through frequency clipping.  In future, other cpu related cooling
devices may be added here.  An ACPI version of this already exists
(drivers/acpi/processor_thermal.c) .But this will be useful for
platforms like ARM using the generic thermal interface along with the
generic cpu cooling devices.  The cooling device registration API's
return cooling device pointers which can be easily binded with the
thermal zone trip points.  The important APIs exposed are,

a) struct thermal_cooling_device *cpufreq_cooling_register(
 struct cpumask *clip_cpus)
b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

 3) Samsung exynos platform thermal implementation is done using the
generic cpu cooling APIs and the new trip type.  The temperature sensor
driver present in the hwmon folder(registered as hwmon driver) is moved
to thermal folder and registered as a thermal driver.

 A simple data/control flow diagrams is shown below,

 Core Linux thermal -  Exynos thermal interface - Temperature 
 Sensor
   | |
  \|/|
   Cpufreq cooling device ---

 TODO:
 *Will send the DT enablement patches later after the driver is merged.

 This patch:

 Add support for generic cpu thermal cooling low level implementations
 using frequency scaling up/down based on the registration parameters.
 Different cpu related cooling devices can be registered by the user and
 the binding of these cooling devices to the corresponding trip points can
 be easily done as the registration APIs return the cooling device pointer.
 The user of these APIs are responsible for passing clipping frequency .
 The drivers can also register to recieve notification about any cooling
 action called.

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

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

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

2012-08-17 Thread Valentin, Eduardo
Hello,

On Fri, Aug 17, 2012 at 10:58 AM, Amit Kachhap amit.kach...@linaro.org wrote:
 On 17 August 2012 12:54, Zhang Rui rui.zh...@intel.com wrote:
 On 四, 2012-08-16 at 17:11 +0530, Amit Daniel Kachhap wrote:
 This patchset introduces a new generic cooling device based on cpufreq
 that can be used on non-ACPI platforms.  As a proof of concept, we have
 drivers for the following platforms using this mechanism now:

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

 There is a small change in cpufreq cooling registration APIs, so a minor
 change is needed for Freescale platforms.

 Brief Description:

 1) The generic cooling devices code is placed inside driver/thermal/*
as placing inside acpi folder will need un-necessary enabling of acpi
code.  This code is architecture independent.

 2) This patchset adds generic cpu cooling low level implementation
through frequency clipping.  In future, other cpu related cooling
devices may be added here.  An ACPI version of this already exists
(drivers/acpi/processor_thermal.c) .But this will be useful for
platforms like ARM using the generic thermal interface along with the
generic cpu cooling devices.  The cooling device registration API's
return cooling device pointers which can be easily binded with the
thermal zone trip points.  The important APIs exposed are,

a) struct thermal_cooling_device *cpufreq_cooling_register(
 struct cpumask *clip_cpus)
b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

 3) Samsung exynos platform thermal implementation is done using the
generic cpu cooling APIs and the new trip type.  The temperature sensor
driver present in the hwmon folder(registered as hwmon driver) is moved
to thermal folder and registered as a thermal driver.

 A simple data/control flow diagrams is shown below,

 Core Linux thermal -  Exynos thermal interface - Temperature 
 Sensor
   | |
  \|/|
   Cpufreq cooling device ---

 TODO:
 *Will send the DT enablement patches later after the driver is merged.

 This patch:

 Add support for generic cpu thermal cooling low level implementations
 using frequency scaling up/down based on the registration parameters.
 Different cpu related cooling devices can be registered by the user and
 the binding of these cooling devices to the corresponding trip points can
 be easily done as the registration APIs return the cooling device pointer.
 The user of these APIs are responsible for passing clipping frequency .
 The drivers can also register to recieve notification about any cooling
 action called.

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

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