Re: [PATCH RESEND] thermal: add generic cpufreq cooling implementation
Hello Rui and Amit, On Mon, Sep 10, 2012 at 9:25 AM, Zhang Rui wrote: > Refreshed to remove the notifier mechanism as we do not have a real user of > it. > if there is no problem, I'll apply the whole patch set to thermal next tree. > > From: Amit Daniel Kachhap > Date: Thu, 16 Aug 2012 17:11:40 +0530 > > This patchset introduces a new generic cooling device based on cpufreq > that can be used on non-ACPI platforms. As a proof of concept, we have > drivers for the following platforms using this mechanism now: > > * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. > * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git > imx6q_thermal) > > There is a small change in cpufreq cooling registration APIs, so a minor > change is needed for Freescale platforms. > > Brief Description: > > 1) The generic cooling devices code is placed inside driver/thermal/* >as placing inside acpi folder will need un-necessary enabling of acpi >code. This code is architecture independent. > > 2) This patchset adds generic cpu cooling low level implementation >through frequency clipping. In future, other cpu related cooling >devices may be added here. An ACPI version of this already exists >(drivers/acpi/processor_thermal.c) .But this will be useful for >platforms like ARM using the generic thermal interface along with the >generic cpu cooling devices. The cooling device registration API's >return cooling device pointers which can be easily binded with the >thermal zone trip points. The important APIs exposed are, > >a) struct thermal_cooling_device *cpufreq_cooling_register( > struct cpumask *clip_cpus) >b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) > > 3) Samsung exynos platform thermal implementation is done using the >generic cpu cooling APIs and the new trip type. The temperature sensor >driver present in the hwmon folder(registered as hwmon driver) is moved >to thermal folder and registered as a thermal driver. > > A simple data/control flow diagrams is shown below, > > Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor > | | > \|/| > Cpufreq cooling device <--- > > TODO: > *Will send the DT enablement patches later after the driver is merged. > > This patch: > > Add support for generic cpu thermal cooling low level implementations > using frequency scaling up/down based on the registration parameters. > Different cpu related cooling devices can be registered by the user and > the binding of these cooling devices to the corresponding trip points can > be easily done as the registration APIs return the cooling device pointer. > The user of these APIs are responsible for passing clipping frequency . > The drivers can also register to recieve notification about any cooling > action called. > > Cc: Guenter Roeck > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Cc: Kyungmin Park > Cc: Kukjin Kim > Signed-off-by: Zhang Rui > Signed-off-by: Andrew Morton > Signed-off-by: Amit Daniel Kachhap can you please include my Reviewed-by? Also on your patch series I have reviewed. Reviewed-by: Eduardo Valentin > --- > Documentation/thermal/cpu-cooling-api.txt | 33 ++ > drivers/thermal/Kconfig | 11 + > drivers/thermal/Makefile |1 + > drivers/thermal/cpu_cooling.c | 450 > + > include/linux/cpu_cooling.h | 58 > 5 files changed, 553 insertions(+), 0 deletions(-) > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > create mode 100644 drivers/thermal/cpu_cooling.c > create mode 100644 include/linux/cpu_cooling.h > > diff --git a/Documentation/thermal/cpu-cooling-api.txt > b/Documentation/thermal/cpu-cooling-api.txt > new file mode 100644 > index 000..6fe9cdb > --- /dev/null > +++ b/Documentation/thermal/cpu-cooling-api.txt > @@ -0,0 +1,33 @@ > +CPU cooling APIs How To > +=== > + > +Written by Amit Daniel Kachhap > + > +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 frequenc
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
Hello Rui, On Mon, Aug 20, 2012 at 5:16 AM, Zhang Rui 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/proce
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
Hello, On Fri, Aug 17, 2012 at 10:58 AM, Amit Kachhap wrote: > On 17 August 2012 12:54, Zhang Rui 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 >>> Cc: Guenter Roeck >>> Cc: SangWook Ju >>> Cc: Durgadoss >>> Cc: Len Brown >>> Cc: Jean Delvare >>> Cc: Kyungmin Park >>> Cc: Kukjin Kim >>> Signed-off-by: Andrew Morton >>> Signed-off-by: Amit Daniel Kachhap >>> --- >>> 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 >>> + >>> +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. >>> + >>> + cl
Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
Amit, Thanks again for keeping this up. On Thu, Aug 16, 2012 at 2:41 PM, 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) FYI, the OMAP code is under drivers/staging/omap-thermal/. The file omap-thermal-common.c is the one which is using your generic cooling device. But it needs to be updated accordingly to the API change you mention. > > 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 > Cc: Guenter Roeck > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Cc: Kyungmin Park > Cc: Kukjin Kim > Signed-off-by: Andrew Morton > Signed-off-by: Amit Daniel Kachhap Reviewed-by: Eduardo Valentin > --- > 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 > + > +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 constrain
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
Amit, On Thu, Jul 12, 2012 at 4:41 PM, 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. > * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git > omap4460_thermal) FYI, I have rewriten the OMAP BG driver and currently trying to push it to staging area. It should now support more omap versions. I will readapt the cpu cooling based on this patch. I am keeping the reworked driver here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/bandgap_staging > * 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 OMAP and 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 codes 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 freq_clip_table *tab_ptr, unsigned int tab_size) >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 > Cc: Donggeun Kim > Cc: Guenter Roeck > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Signed-off-by: Andrew Morton > --- > Documentation/thermal/cpu-cooling-api.txt | 60 > drivers/thermal/Kconfig | 11 + > drivers/thermal/Makefile |3 +- > drivers/thermal/cpu_cooling.c | 483 > + > include/linux/cpu_cooling.h | 99 ++ > 5 files changed, 655 insertions(+), 1 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..557adb8 > --- /dev/null > +++ b/Documentation/thermal/cpu-cooling-api.txt > @@ -0,0 +1,60 @@ > +CPU cooling APIs How To > +=== > + > +Written by Amit Daniel Kachhap > + > +Updated: 12 May 2012 > + > +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) > + > +0. Introduction > + > +The generic cpu cooling(freq clipping, cpuhotplug etc) 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 freq_clip_table *tab_ptr, unsigned int tab_size) > + > +This interface function registers the cpufreq cooling device with the > name > +"thermal-cpufreq-%
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
Hey Rob and Amit, On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee wrote: > Hey Amit, > > I was just re-organizing the imx thermal driver that uses this cpu > cooling interface and noticed a couple of small issues here. If While rewriting the OMAP BG driver on top of this series I noticed similar issues. Apart from those pointed by Rob, I have another minor fix. > these suggestions are agreed upon and if it's too late for these > issues be changed with this patchset, I can submit them separately > unless you'd prefer to. > > On Sat, May 12, 2012 at 4:40 AM, Amit Daniel Kachhap > wrote: >> This patch adds 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. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 60 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile | 3 +- >> drivers/thermal/cpu_cooling.c | 483 >> + >> include/linux/cpu_cooling.h | 99 ++ >> 5 files changed, 655 insertions(+), 1 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..557adb8 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,60 @@ >> +CPU cooling APIs How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 12 May 2012 >> + >> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug etc) 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 freq_clip_table *tab_ptr, unsigned int tab_size) >> + >> + This interface function registers the cpufreq cooling device with the >> name >> + "thermal-cpufreq-%x". This api can support multiple instances of cpufreq >> + cooling devices. >> + >> + tab_ptr: The table containing the maximum value of frequency to be >> clipped >> + for each cooling state. >> + .freq_clip_max: Value of frequency to be clipped for each allowed >> + cpus. >> + .temp_level: Temperature level at which the frequency clamping will >> + happen. >> + .mask_val: cpumask of the allowed cpu's >> + tab_size: the total number of cpufreq cooling states. >> + >> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) >> + >> + This interface function unregisters the "thermal-cpufreq-%x" cooling >> device. >> + >> + cdev: Cooling device pointer which has to be unregistered. >> + >> + >> +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 >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index 514a691..d9c529f 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 > > Perhaps the name CPU_COOLING or CPUFREQ_COOLING would more accurately > describe this functionality? I like the latter since now this > mechanism only supports cooling by using cpufreq. > >> + bool "generic cpu cooling support" > > If we use CPUFREQ_COOLING, then perhaps this could say: > > bool "cp
