Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
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
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/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
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
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 > >>> + * > >>> + * > >>> ~~ > >>> + * 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
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: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
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. >> + >> + 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 funct
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
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. > + > + 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 > device. > + > +cdev: Cooling device pointer which has to be unregistered. > + > + > +1.2 CPU cooli
