Re: [PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.
On 26 October 2012 12:39, hongbo.zhang hongbo.zh...@linaro.org wrote:
From: hongbo.zhang hongbo.zh...@linaro.com
Problem of using this list is that the cpufreq_get_max_state callback will be
called when register cooling device by thermal_cooling_device_register, but
this list isn't ready at this moment. What's more, there is no need to
maintain
such a list, we can get cpufreq_cooling_device instance by the private
thermal_cooling_device.devdata.
Hi,
Removing this list seems fine as most of frequency checks are moved
inside generic thermal layer.
Some minor review comments below,
Reviewed-by: Amit Daniel Kachhap amit.kach...@linaro.org
Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com
---
drivers/thermal/cpu_cooling.c | 91
+--
1 file changed, 19 insertions(+), 72 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 415b041..2ffd12c 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
};
static LIST_HEAD(cooling_cpufreq_list);
static DEFINE_IDR(cpufreq_idr);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
-static struct mutex cooling_cpufreq_lock;
+static unsigned int cpufreq_dev_count;
/* notify_table passes value to the CPUFREQ_ADJUST callback function. */
#define NOTIFY_INVALID NULL
@@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct
notifier_block *nb,
static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- int ret = -EINVAL, i = 0;
- struct cpufreq_cooling_device *cpufreq_device;
- struct cpumask *maskPtr;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
check cdev is not null.
+ struct cpumask *maskPtr = cpufreq_device-allowed_cpus;
unsigned int cpu;
struct cpufreq_frequency_table *table;
unsigned long count = 0;
+ int i = 0;
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev)
- break;
- }
- if (cpufreq_device == NULL)
- goto return_get_max_state;
-
- maskPtr = cpufreq_device-allowed_cpus;
cpu = cpumask_any(maskPtr);
table = cpufreq_frequency_get_table(cpu);
if (!table) {
*state = 0;
- ret = 0;
- goto return_get_max_state;
+ return 0;
}
for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
if (count 0) {
*state = --count;
- ret = 0;
+ return 0;
}
-return_get_max_state:
- mutex_unlock(cooling_cpufreq_lock);
- return ret;
+ return -EINVAL;
}
/**
@@ -288,20 +277,10 @@ return_get_max_state:
static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev) {
- *state = cpufreq_device-cpufreq_state;
- ret = 0;
- break;
- }
- }
- mutex_unlock(cooling_cpufreq_lock);
-
- return ret;
+ *state = cpufreq_device-cpufreq_state;
+ return 0;
}
/**
@@ -312,22 +291,9 @@ static int cpufreq_get_cur_state(struct
thermal_cooling_device *cdev,
static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
unsigned long state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
check cdev is not null
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev) {
- ret = 0;
- break;
- }
- }
- if (!ret)
- ret = cpufreq_apply_cooling(cpufreq_device, state);
-
- mutex_unlock(cooling_cpufreq_lock);
-
- return ret;
+ return cpufreq_apply_cooling(cpufreq_device, state);
}
/* Bind cpufreq callbacks to thermal cooling device ops */
@@ -351,7 +317,7 @@ struct thermal_cooling_device *cpufreq_cooling_register(
{
struct thermal_cooling_device
Re: [PATCH V2 2/6] Thermal: make sure cpufreq cooling register after cpufreq driver
On 24 October 2012 17:28, hongbo.zhang hongbo.zh...@linaro.org wrote: From: hongbo.zhang hongbo.zh...@linaro.com The cpufreq works as a cooling device, so the cooling layer should check if the cpufreq driver is initialized or not. Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com --- drivers/thermal/cpu_cooling.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index b6b4c2a..7519a0b 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -354,6 +354,10 @@ struct thermal_cooling_device *cpufreq_cooling_register( int ret = 0, i; struct cpufreq_policy policy; + /* make sure cpufreq driver has been initialized */ + if (!cpufreq_frequency_get_table(cpumask_any(clip_cpus))) + return ERR_PTR(-EPROBE_DEFER); + Hi Hongbo, I am not against this change but this might cause unnecessary delay in probe thread. I also thought about it but have not put this restriction. Actually you can put a check in platform_bind for this condition and defer the binding till the time actual throttling starts. So basically only after throttling cpufreq_table is needed. (See my implementation exynos_thermal.c). Thanks, Amit Daniel list_for_each_entry(cpufreq_dev, cooling_cpufreq_list, node) cpufreq_dev_count++; -- 1.7.11.3 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 3/6] Thermal: fix bug of counting cpu frequencies.
On 24 October 2012 19:04, Viresh Kumar viresh.ku...@linaro.org wrote: On 24 October 2012 17:28, hongbo.zhang hongbo.zh...@linaro.org wrote: From: hongbo.zhang hongbo.zh...@linaro.com In the while loop for counting cpu frequencies, if table[i].frequency equals CPUFREQ_ENTRY_INVALID, index i won't be increased, so this leads to an endless loop, what's more the index i cannot be referred as cpu frequencies number if there is CPUFREQ_ENTRY_INVALID case. Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com Good one. Reviewed-by: Viresh Kumar viresh.ku...@linaro.org Changes looks fine. Adding thermal maintainer(Rui Zhang) in the mail list. Reviewed-by: Amit Daniel Kachhap amit.kach...@linaro.org Thanks, Amit Daniel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 3:39 PM, Hongbo Zhang hongbo.zh...@linaro.org wrote: On 12 May 2012 17:40, Amit Daniel Kachhap amit.kach...@linaro.org 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 amit.kach...@linaro.org --- 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 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, 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 + 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 or M here. No M value for bool item, should be N ? Yes I will include this change. + config SPEAR_THERMAL bool SPEAr thermal sensor driver depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) +=
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Tue, Jul 10, 2012 at 12:31 PM, Hongbo Zhang hongbo.zh...@linaro.org wrote: On 12 May 2012 17:40, Amit Daniel Kachhap amit.kach...@linaro.org 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 amit.kach...@linaro.org --- 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 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, 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 + 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 or M here. + config SPEAR_THERMAL bool SPEAr thermal sensor driver depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o -obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
Re: [PATCH v3 2/6] thermal: Add generic cpufreq cooling implementation
On 9 May 2012 01:46, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 8 May 2012 21:48:14 +0530
Amit Daniel Kachhap amit.kach...@linaro.org 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. Even the driver can effect
the cooling action by modifying the default data such as freq_clip_max if
needed.
...
+struct cpufreq_cooling_device {
+ int id;
+ struct thermal_cooling_device *cool_dev;
+ struct freq_clip_table *tab_ptr;
+ unsigned int tab_size;
+ unsigned int cpufreq_state;
+ const struct cpumask *allowed_cpus;
+ struct list_head node;
+};
It would be nice to document the fields. Especially id, tab_size,
cpufreq_state and node. For `node' we should describe the locking for
the list, and describe which list_head anchors this list.
Thanks Andrew for the detailed review. I will add more documentation
and post the next version shortly.
+static LIST_HEAD(cooling_cpufreq_list);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
+static DEFINE_IDR(cpufreq_idr);
+static DEFINE_PER_CPU(unsigned int, max_policy_freq);
+static struct freq_clip_table *notify_table;
+static int notify_state;
+static BLOCKING_NOTIFIER_HEAD(cputherm_state_notifier_list);
+
+static int get_idr(struct idr *idr, struct mutex *lock, int *id)
+{
+ int err;
+again:
+ if (unlikely(idr_pre_get(idr, GFP_KERNEL) == 0))
+ return -ENOMEM;
+
+ if (lock)
+ mutex_lock(lock);
The test for NULL `lock' is unneeded. In fact the `lock' argument
could be removed altogether - just use cooling_cpufreq_lock directly.
Agreed
+ err = idr_get_new(idr, NULL, id);
+ if (lock)
+ mutex_unlock(lock);
+ if (unlikely(err == -EAGAIN))
+ goto again;
+ else if (unlikely(err))
+ return err;
+
+ *id = *id MAX_ID_MASK;
+ return 0;
+}
+
+static void release_idr(struct idr *idr, struct mutex *lock, int id)
+{
+ if (lock)
+ mutex_lock(lock);
Ditto.
+ idr_remove(idr, id);
+ if (lock)
+ mutex_unlock(lock);
+}
+
...
+
+/*Below codes defines functions to be used for cpufreq as cooling device*/
+static bool is_cpufreq_valid(int cpu)
+{
+ struct cpufreq_policy policy;
+ return !cpufreq_get_policy(policy, cpu) ? true : false;
Can use
Ok
return !cpufreq_get_policy(policy, cpu);
+}
+
+static int cpufreq_apply_cooling(struct cpufreq_cooling_device
*cpufreq_device,
+ unsigned long cooling_state)
+{
+ unsigned int event, cpuid;
+ struct freq_clip_table *th_table;
+
+ if (cooling_state cpufreq_device-tab_size)
+ return -EINVAL;
+
+ cpufreq_device-cpufreq_state = cooling_state;
+
+ /*cpufreq thermal notifier uses this cpufreq device pointer*/
This code looks like it was written by two people.
/* One who does this */
/*And one who does this*/
The first one was right. Please go through all the comments in all the
patches and get the layout consistent?
Sure will add more details.
+ notify_state = cooling_state;
+
+ if (notify_state 0) {
+ th_table = (cpufreq_device-tab_ptr[cooling_state - 1]);
+ memcpy(notify_table, th_table, sizeof(struct freq_clip_table));
+ event = CPUFREQ_COOLING_TYPE;
+ blocking_notifier_call_chain(cputherm_state_notifier_list,
+ event, notify_table);
+ }
+
+ for_each_cpu(cpuid, cpufreq_device-allowed_cpus) {
+ if (is_cpufreq_valid(cpuid))
+ cpufreq_update_policy(cpuid);
+ }
+
+ notify_state = -1;
+
+ return 0;
+}
+
+static int cpufreq_thermal_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct cpufreq_policy *policy = data;
+ unsigned long max_freq = 0;
+
+ if ((event != CPUFREQ_ADJUST) || (notify_state == -1))
Please document `notify_state', at its definition site. This reader
doesn't know what notify_state == -1 *means*.
+ return 0;
+
+ if (notify_state 0) {
+ max_freq = notify_table-freq_clip_max;
+
+ if (per_cpu(max_policy_freq, policy-cpu) == 0)
+ per_cpu(max_policy_freq, policy-cpu) = policy-max;
+ } else {
+ if (per_cpu(max_policy_freq, policy-cpu) != 0) {
+
Re: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 9 May 2012 01:36, Zhang, Rui rui.zh...@intel.com wrote:
Hi, Amit,
Sorry for the late response as I'm in a travel recently.
I think the generic cpufreq cooling patches are good.
But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that
1. from thermal zone point of view, when the temperature is higher than a
trip point, either ACTIVE or PASSIVE, what we should do is to set device
cooling state to cur_state+1, right?
The only difference is that if we should take passive cooling actions or
active cooling actions based on the policy.
So my question would be if it is possible to combine these two kind of trip
points together. Maybe something like this:
In thermal_zone_device_update(),
...
case THERMAL_TRIP_PASSIVE:
if (passive cooling not allowed)
continue;
if (tc1)
thermal_zone_device_passive();
else
thermal_set_cooling_state();
break;
case THERMAL_TRIP_ACTIVE:
if (active cooling not allowed)
continue;
thermal_set_cooling_state();
break;
...
and thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices, node) {
if (instance-trip != count)
continue;
cdev = instance-cdev;
if (temp = trip_temp)
cdev-ops-set_cur_state(cdev, 1);
else
cdev-ops-set_cur_state(cdev, 0);
}
}
2. use only one cooling_device instance for a thermal_zone, and introduce
cdev-trips which shows the trip points this cooling device is bind to.
And we may use multiple cooling devices states for one active trip point.
Then, thermal_set_cooling_state() would be look like
list_for_each_entry(instance, tz-cooling_devices, node) {
cdev = instance-cdev;
/* check whether this cooling device is bind to the trip point */
if (!(cdev-trips 1count))
continue;
cdev-ops-get_max_state(cdev, max_state);
cdev-ops-get_cur_state(cdev, cur_state);
if (temp = trip_temp) {
if (cur_state++ = max_state))
cdev-ops-set_cur_state(cdev, cur_state);
} else if ((temp trip_temp) (cur_state-- = 0))
cdev-ops-set_cur_state(cdev, cur_state);
}
}
Hi Rui,
The above implementation also cools instance based cooling devices
like passive trip type. I need some changes on top of your
implementation such as,
thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices,
node) {
cdev = instance-cdev;
if (!cdev-trips 1count)
continue;
inst_id = 0;
for_each_bit_set(i, cdev-trips, count)
inst_id++;
cdev-ops-get_max_state(cdev, max_state);
if ((temp = trip_temp) (inst_id = max_state))
cdev-ops-set_cur_state(cdev, inst_id);
else if ((temp trip_temp) (--inst_id = 0))
cdev-ops-set_cur_state(cdev, inst_id);
}
}
I agree with you that the instance based trip types violates the
concept like reading the cur_state and do cur_state++/cur_state--
depending upon threshold increase or decrease because it needs the
state_id/inst_id.
I am actually thinking of dropping this new trip type and use the
existing THERMAL_TRIP_ACTIVE because there is so much logic in
calculating the state_id. The only flip side of using TRIP_ACTIVE is
that I need to create so many cooling devices.
Thanks,
Amit D
With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be
registered as two PASSIVE trip points in the generic thermal layer, right?
Actually, this is one thing in my TODO list. And I'd glad to make it high
priority if this solves the problem you have.
Thanks,
rui
-Original Message-
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
Sent: Tuesday, May 08, 2012 9:18 AM
To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui;
amit.kach...@linaro.org; linaro-dev@lists.linaro.org;
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-samsung-...@vger.kernel.org; patc...@linaro.org
Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for
exynos platform
Importance: High
Hi Andrew,
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:
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git
omap4460_thermal)
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
imx6q_thermal)
These patches have been reviewed by Rui Zhang
(https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting
them merged, perhaps
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 16 April 2012 07:37, Zhang Rui rui.zh...@intel.com wrote:
On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
Hi Rui,
Thanks for looking into the patches.
On 10 April 2012 06:28, Zhang Rui rui.zh...@intel.com wrote:
Hi, Amit,
On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
Hi Len/Rui,
Any comment or feedback from your side about the status of this patch?
Is it merge-able or major re-work is needed? I have fixed most of the
comments in this patchset and currently working on some of the minor
comments received and will submit them shortly.
Sorry for the late response.
First of all, it makes sense to me to introduce the generic cpufrq
cooling implementation.
ok thanks
But I still have some questions.
I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
current passive handling in the generic thermal layer well, right?
e.g. there is no tc1/tc2 on exynos4.
If yes, is it possible that we can enhance the passive cooling to
support the generic processor cooling?
say, introduce another way to throttle the processor in
thermal_zone_device_passive when tc1 and tc2 are not available?
I agree that this new trip type code can be moved into passive trip
type when tc1 and tc2 are 0. but this is special type of cooling
devices behaviour where only instances of the same cooling device is
binded to a trip point. The order of mapping is the only
differentiating criteria and there are some checks used to implement
this like
1) The trip points should be in ascending order.(This is missing in my
original patch, so I added below)
2) The set_cur_state has to be called for the exact temp range so
get_cur_state(state) and set_cur_state(state ++/state--) logic is not
possible.
3) set_cur_state is called as set_cur_state(cdev_instance).
Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
Sorry for late reply as I was off for vacation.
Yes we need 2 trip points of type THERMAL_TRIP_STATE_INSTANCE as we
need different cooling for these 2 zones. Anyways Do you feel that
these whole/partial patch series(cpufreq cooling api's, new trip type
etc) is ack-able or some modification is needed?
I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?
thanks,
rui
There is a chance that people might confuse that these checks are
applicable for passive trip types also which is not the case here.
@@ -1187,6 +1228,21 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
tz-ops-get_trip_type(tz, count, trip_type);
if (trip_type == THERMAL_TRIP_PASSIVE)
passive = 1;
+ /*
+ * For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
+ * be in ascending order.
+ */
+ if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
+ tz-ops-get_trip_temp(tz, count, trip_temp);
+ if (first_trip_temp == 0)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp) {
+ pr_warn(Zone trip points should be in
ascending order\n);
+ goto unregister;
+ }
+ }
}
if (!passive)
Anyway there is other alternative where this new trip type is not
needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
I had thought to make this generic and just to manage with 1 cooling
device.
What is your view?
Thanks,
Amit Daniel
thanks,
rui
Regards,
Amit Daniel
On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon
folder
as suggested by Mark Brown and Guenter Roeck
*Added notifier support to notify the registered drivers of any cpu
cooling
action. The driver can modify the default cooling behaviour(eg set
different
max clip frequency).
*The percentage based frequency replaced with absolute clipped
frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
*Many review comments from R, Durgadoss durgados...@intel.com and
eduardo.valen...@ti.com implemented.
*Removed cooling stats through debugfs patch
*The V1 based can be found here,
https://lkml.org/lkml
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Rui,
Thanks for looking into the patches.
On 10 April 2012 06:28, Zhang Rui rui.zh...@intel.com wrote:
Hi, Amit,
On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
Hi Len/Rui,
Any comment or feedback from your side about the status of this patch?
Is it merge-able or major re-work is needed? I have fixed most of the
comments in this patchset and currently working on some of the minor
comments received and will submit them shortly.
Sorry for the late response.
First of all, it makes sense to me to introduce the generic cpufrq
cooling implementation.
ok thanks
But I still have some questions.
I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
current passive handling in the generic thermal layer well, right?
e.g. there is no tc1/tc2 on exynos4.
If yes, is it possible that we can enhance the passive cooling to
support the generic processor cooling?
say, introduce another way to throttle the processor in
thermal_zone_device_passive when tc1 and tc2 are not available?
I agree that this new trip type code can be moved into passive trip
type when tc1 and tc2 are 0. but this is special type of cooling
devices behaviour where only instances of the same cooling device is
binded to a trip point. The order of mapping is the only
differentiating criteria and there are some checks used to implement
this like
1) The trip points should be in ascending order.(This is missing in my
original patch, so I added below)
2) The set_cur_state has to be called for the exact temp range so
get_cur_state(state) and set_cur_state(state ++/state--) logic is not
possible.
3) set_cur_state is called as set_cur_state(cdev_instance).
There is a chance that people might confuse that these checks are
applicable for passive trip types also which is not the case here.
@@ -1187,6 +1228,21 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
tz-ops-get_trip_type(tz, count, trip_type);
if (trip_type == THERMAL_TRIP_PASSIVE)
passive = 1;
+ /*
+* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
+* be in ascending order.
+ */
+ if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
+ tz-ops-get_trip_temp(tz, count, trip_temp);
+ if (first_trip_temp == 0)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp) {
+ pr_warn(Zone trip points should be in
ascending order\n);
+ goto unregister;
+ }
+ }
}
if (!passive)
Anyway there is other alternative where this new trip type is not
needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
I had thought to make this generic and just to manage with 1 cooling
device.
What is your view?
Thanks,
Amit Daniel
thanks,
rui
Regards,
Amit Daniel
On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon folder
as suggested by Mark Brown and Guenter Roeck
*Added notifier support to notify the registered drivers of any cpu cooling
action. The driver can modify the default cooling behaviour(eg set
different
max clip frequency).
*The percentage based frequency replaced with absolute clipped frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
*Many review comments from R, Durgadoss durgados...@intel.com and
eduardo.valen...@ti.com implemented.
*Removed cooling stats through debugfs patch
*The V1 based can be found here,
https://lkml.org/lkml/2012/2/22/123
http://lkml.org/lkml/2012/3/3/32
Changes since RFC:
*Changed the cpu cooling registration/unregistration API's to instance
based
*Changed the STATE_ACTIVE trip type to pass correct instance id
*Adding support to restore back the policy-max_freq after doing frequency
clipping.
*Moved the trip cooling stats from sysfs node to debugfs node as suggested
by Greg KH g...@kroah.com
*Incorporated several review comments from eduardo.valen...@ti.com
*Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
as discussed with Guenter Roeck guenter.ro...@ericsson.com and
Donggeun Kim dg77@samsung.com (https://lkml.org/lkml/2012/1/5/7)
*Some changes according to the changes in common cpu cooling APIs
*The RFC based patches can be found here,
https://lkml.org/lkml/2011/12/13/186
https
Re: [PATCH] thermal: Fix for setting the thermal zone mode to enable/disable
On 21 March 2012 19:43, Jean Delvare kh...@linux-fr.org wrote: On Wed, 21 Mar 2012 16:40:01 +0530, Amit Daniel Kachhap wrote: Basically without this patch changing the mode of thermal zone is not possible as wrong string size is passed to strncmp. Actually it is possible, $ echo -n disabled mode works fine. But it fails without the -n, your patch would fix that. Thanks for pointing this out. Anyway this patch makes some sense until sysfs takes care of this. Acked-by: Jean Delvare kh...@linux-fr.org Note that a quick grep suggests that drivers/misc/ad525x_dpot.c, security/selinux/hooks.c and arch/m68k/sun3/prom/console.c suffer from the same issue, if you want to fix them too. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- drivers/thermal/thermal_sys.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 220ce7e..96da1af 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -152,9 +152,9 @@ mode_store(struct device *dev, struct device_attribute *attr, if (!tz-ops-set_mode) return -EPERM; - if (!strncmp(buf, enabled, sizeof(enabled))) + if (!strncmp(buf, enabled, sizeof(enabled) - 1)) result = tz-ops-set_mode(tz, THERMAL_DEVICE_ENABLED); - else if (!strncmp(buf, disabled, sizeof(disabled))) + else if (!strncmp(buf, disabled, sizeof(disabled) - 1)) result = tz-ops-set_mode(tz, THERMAL_DEVICE_DISABLED); else result = -EINVAL; -- Jean Delvare ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 3/6] thermal: Add generic cpuhotplug cooling implementation
On 19 March 2012 17:15, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 03/19/2012 11:47 AM, Amit Daniel Kachhap wrote:
This patch adds support for generic cpu thermal cooling low level
implementations using cpuhotplug based on the thermal level requested
from user. 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 the cpumask.
I am really not aware of the cpu thermal cooling stuff, but since this patch
deals with CPU Hotplug (which I am interested in), I have some questions
below..
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
+
+static int cpuhotplug_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ int ret = -EINVAL;
+ struct hotplug_cooling_device *hotplug_dev;
+
+ mutex_lock(cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, cooling_cpuhotplug_list, node) {
+ if (hotplug_dev hotplug_dev-cool_dev == cdev) {
+ *state = hotplug_dev-hotplug_state;
+ ret = 0;
+ break;
+ }
+ }
+ mutex_unlock(cooling_cpuhotplug_lock);
+ return ret;
+}
+
+/*This cooling may be as ACTIVE type*/
+static int cpuhotplug_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ int cpuid, this_cpu = smp_processor_id();
What prevents this task from being migrated to another CPU?
IOW, what ensures that 'this_cpu' remains valid throughout this function?
I see that you are acquiring mutex locks below.. So this is definitely not
a preempt disabled section.. so I guess my question above is valid..
Or is this code bound to a particular cpu?
No this thread is not bound to a cpu. Your comment is valid and some
synchronization is needed for preemption. Thanks for pointing this
out.
+ struct hotplug_cooling_device *hotplug_dev;
+
+ mutex_lock(cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, cooling_cpuhotplug_list, node)
+ if (hotplug_dev hotplug_dev-cool_dev == cdev)
+ break;
+
+ mutex_unlock(cooling_cpuhotplug_lock);
+ if (!hotplug_dev || hotplug_dev-cool_dev != cdev)
+ return -EINVAL;
+
+ if (hotplug_dev-hotplug_state == state)
+ return 0;
+
+ /*
+ * This cooling device may be of type ACTIVE, so state field can
+ * be 0 or 1
+ */
+ if (state == 1) {
+ for_each_cpu(cpuid, hotplug_dev-allowed_cpus) {
+ if (cpu_online(cpuid) (cpuid != this_cpu))
What prevents the cpu numbered cpuid from being taken down right at this
moment?
Don't you need explicit synchronization with CPU Hotplug using something like
get_online_cpus()/put_online_cpus() here?
+ cpu_down(cpuid);
+ }
+ } else if (state == 0) {
+ for_each_cpu(cpuid, hotplug_dev-allowed_cpus) {
+ if (!cpu_online(cpuid) (cpuid != this_cpu))
Same here.
+ cpu_up(cpuid);
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ hotplug_dev-hotplug_state = state;
+
+ return 0;
+}
+/* bind hotplug callbacks to cpu hotplug cooling device */
+static struct thermal_cooling_device_ops cpuhotplug_cooling_ops = {
+ .get_max_state = cpuhotplug_get_max_state,
+ .get_cur_state = cpuhotplug_get_cur_state,
+ .set_cur_state = cpuhotplug_set_cur_state,
+};
+
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On 13 March 2012 15:44, Sundar sunder.s...@gmail.com wrote: On Tue, Mar 13, 2012 at 3:30 PM, Amit Kucheria amit.kuche...@linaro.org wrote: Sundar, Hi Amit, At the moment it doesn't. But there was some discussion around creating something that will work with devfreq. This would allow peripheral drivers to be plugged in as well. Amit is investigating that at present. What if we work towards a generic constraint framework which models thermals as a performance constraint. Drivers can register to this constraint; platform code can then decide to issue restrictions either to the CPU or other power-hungry peripherals based on the platform conditions. That also allows to model CPU frequency as a generic constraint but via an actual consumer, say the thermal driver. Yes that should be helpful. Even the things your are suggesting are somewhat same with some patches submitted which sets cpufreq min/max constraint. Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss durgados...@intel.com wrote:
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Saturday, March 03, 2012 4:36 PM
To: linux...@lists.linux-foundation.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; lm-
sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
Durgadoss; patc...@linaro.org
Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
thermal layer
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
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 or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.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 linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
Yes Ideally this should be zero. But I wanted thermal monitoring to
always happen with some long interval in case of error scenarios.
Anyway I will check this again.
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
On 13 March 2012 09:24, Tushar Behera tushar.beh...@linaro.org wrote:
On 03/03/2012 04:36 PM, Amit Daniel Kachhap wrote:
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
If you are resubmitting the patchset, it would be good if you can
address the nitpicks. Sorry for being so late in pointing them out now,
none of the comments below are pertaning to the code flow - so you can
ignore these comments if there are no plans for resubmission.
Thanks tushar. I will include your suggestion for next patchset submission.
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
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 or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.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 linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d sec\n,
+ th_zone-therm_dev-polling_delay/1000);
+ return 0;
+}
+
+/*This may be called from interrupt based temperature sensor*/
+void exynos4_report_trigger(void)
+{
+ unsigned int monitor_temp;
+
+ if (!th_zone || !th_zone-therm_dev)
+
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On 11 March 2012 09:41, Sundar sunder.s...@gmail.com wrote: Hi Amit, I am new here; so please bear with my questions/doubts :) On Wed, Feb 22, 2012 at 3:44 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the request from user. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding Different cpu related cooling devices: Do you mean cooling devices for different CPUs (num_cpus) or are you referring to different customers aka consumer drivers who could use this framework and impose the cooling. Correct but the consumer driver only has to use the other thermal-sys.c functions. Only register cpu cooling devices is implemented in this work. trip points can be easily done as the registration API's return the cooling device pointer. The user of these api's are responsible for passing clipping frequency in percentages. Why do you want to pass the clipping frequency in percentages? Wouldnt it be simpler for any platform sensor driver to just pass the frequency it wants to throttle the CPU? Yes i also agree. + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq-%x. This api can support multiple instance of cpufreq cooling + devices. When you refer to cooling devices, is it the number of instances per-CPU that is supported? Sorry I am unable to follow. CPU cooling apis can be used as below 1)per cpus if different frequency clipping is needed. so multiple instance of this api can be called. 2)for all the cpus as provided with mask when same frequency clipping is needed. In this case single instance is fine. + .polling_interval: polling interval for this cooling state. + tab_size: the total number of cooling state. By cooling_state, I assume you are referring to the thermal state for the platform? or only for the CPU? Yes thermal state of the platform. + mask_val: all the allowed cpu's where frequency clipping can happen. Why should this be a new variable? The policy-affected_cpus should be the same as this IMO? yes this should be same. I will check this. + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An Apart from reducing the CPU frequency, (probably) CPU hotplug, what other means of reducing CPU temperature? Or are you referring to any platform temperature controls? No only CPU related. Other control ways I thought was cpuidle with low power states and cpu_power factor modifications used in the schedular. It isnt very clear from the documentation (at least to me) if this is only for CPU cooling or generic platform cooling. Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers'. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 17:51, Sylwester Nawrocki snj...@gmail.com wrote: On 03/03/2012 12:06 PM, Amit Daniel Kachhap wrote: This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in mfd folder and add necessary calls to get the temperature information. Signed-off-by: Amit Daniel Kachhapamit.kach...@linaro.org Signed-off-by: Donggeun Kimdg77@samsung.com --- Documentation/hwmon/exynos4_tmu | 81 -- Documentation/mfd/exynos4_tmu | 81 ++ drivers/hwmon/Kconfig | 10 - drivers/hwmon/Makefile | 1 - drivers/hwmon/exynos4_tmu.c | 514 --- drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/exynos4_tmu.c | 514 +++ 8 files changed, 606 insertions(+), 606 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/mfd/exynos4_tmu delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/mfd/exynos4_tmu.c Please consider adding -M option to git format-patch next time, which would make the patch smaller and would let to see clearly what's moved and what has changed. Sure , will keep it in mind. Thanks -- Thanks, Sylwester ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lm-sensors] [linux-pm] [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 23:34, Guenter Roeck guenter.ro...@ericsson.com wrote: On Sat, Mar 03, 2012 at 11:44:10AM -0500, Mark Brown wrote: On Sat, Mar 03, 2012 at 04:36:05PM +0530, Amit Daniel Kachhap wrote: This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in mfd folder and add necessary calls to get the temperature information. --- a/Documentation/hwmon/exynos4_tmu +++ /dev/null Moving this seems to be a failure, the device is exposing a hwmon interface even if you've moved the code to mfd (though it doesn't actually look like a multi-function device at all as far as I can see - usually a MFD would have a bunch of unrelated functionality while this has one function used by two subsystems). If anything it looks like the ADC driver ought to be moved into IIO with either generic or Exynos specific function drivers layered on top of it in hwmon and thermal making use of the values that are read. I would agree. Or maybe move it all to thermal, since thermal devices register the hwmon subsystem. Ok I agree with your suggestion of moving into thermal. Since I wanted to separate exynos specific generic thermal implementation with the H/W driver so that other versions of the sensor driver can easily hook into the common part. Anyway this implementation seems possible. Thanks for the comments Guenter ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 3/9] ARM: exynos: Consolidate time keeping and irq enable
Hi,
I verified this patch on exynos4 based origen board.
Tested-by: Amit Daniel amit.kach...@linaro.org
Thanks,
Amit D
On 29 February 2012 08:41, Robert Lee rob@linaro.org wrote:
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 53 ---
1 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 9bf6743..75bb88b 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -20,6 +20,7 @@
#include asm/smp_scu.h
#include asm/suspend.h
#include asm/unified.h
+#include asm/cpuidle.h
#include mach/regs-pmu.h
#include mach/pmu.h
@@ -34,22 +35,12 @@
#define S5P_CHECK_AFTR 0xFCBA0D10
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index);
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
- [0] = {
- .enter = exynos4_enter_idle,
- .exit_latency = 1,
- .target_residency = 10,
- .flags = CPUIDLE_FLAG_TIME_VALID,
- .name = C0,
- .desc = ARM clock gating(WFI),
- },
+ [0] = CPUIDLE_ARM_WFI_STATE,
[1] = {
.enter = exynos4_enter_lowpower,
.exit_latency = 300,
@@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
static struct cpuidle_driver exynos4_idle_driver = {
- .name = exynos4_idle,
- .owner = THIS_MODULE,
+ .name = exynos4_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
};
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
@@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct cpuidle_device
*dev,
struct cpuidle_driver *drv,
int index)
{
- struct timeval before, after;
- int idle_time;
unsigned long tmp;
- local_irq_disable();
- do_gettimeofday(before);
-
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
@@ -148,34 +135,6 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
/* Clear wakeup state register */
__raw_writel(0x0, S5P_WAKEUP_STAT);
- do_gettimeofday(after);
-
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
- return index;
-}
-
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- cpu_do_idle();
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
return index;
}
@@ -190,7 +149,7 @@ static int exynos4_enter_lowpower(struct cpuidle_device
*dev,
new_index = drv-safe_state_index;
if (new_index == 0)
- return exynos4_enter_idle(dev, drv, new_index);
+ return cpuidle_simple_enter(dev, drv, new_index);
else
return exynos4_enter_core0_aftr(dev, drv, new_index);
}
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
Hi Durgadoss, Thanks for the detailed review comments. On 24 February 2012 16:34, R, Durgadoss durgados...@intel.com wrote: Hi Amit, -Original Message- From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel Kachhap Sent: Wednesday, February 22, 2012 3:44 PM To: linux...@lists.linux-foundation.org Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux- a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org; patc...@linaro.org Subject: [PATCH 2/4] thermal: Add generic cpufreq cooling implementation This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the request from user. Different cpu related cooling devices can be registered by the I believe what you mean by 'user' is another Driver using this code.. right ?? Yes. user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration API's return the cooling device pointer. The user of these api's are responsible for passing clipping frequency in percentages. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 40 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 310 + include/linux/cpu_cooling.h | 54 + 5 files changed, 416 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..04de67c --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,40 @@ +CPU cooling api's How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 13 Dec 2011 + +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug) provides +registration/unregistration api's to the user. The binding of the cooling +devices to the trip point is left for the user. The registration api's returns +the cooling device pointer. + +1. cpufreq cooling api's + +1.1 cpufreq registration api's +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_pctg_table *tab_ptr, unsigned int tab_size, + const struct cpumask *mask_val) + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq-%x. This api can support multiple instance of cpufreq cooling + devices. + + tab_ptr: The table containing the percentage of frequency to be clipped for + each cooling state. + .freq_clip_pctg: Percentage of frequency to be clipped for each allowed + cpus. + .polling_interval: polling interval for this cooling state. + tab_size: the total number of cooling state. Although I can understand that the table size is equal to the total number of cooling states, it is better to name it 'num_cooling_states' (or something) that means what it is.. Yes your idea makes more sense. Will accept it in the next version. + mask_val: all the allowed cpu's where frequency clipping can 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. diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f7f71b2..298c1cd 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -18,3 +18,14 @@ config THERMAL_HWMON depends on THERMAL depends on HWMON=y || HWMON=THERMAL default y + +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL + 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 or M here. diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 31108a0..655cbc4 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c new file mode 100644 index 000
Re: [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
On 23 February 2012 12:16, R, Durgadoss durgados...@intel.com wrote:
Hi Amit,
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Wednesday, February 22, 2012 3:44 PM
To: linux...@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org;
amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org; patc...@linaro.org
Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
instance number
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/thermal_sys.c | 45
--
include/linux/thermal.h | 1 +
3 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-
api.txt
index 1733ab9..7a0c080 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 220ce7e..d4c9b20 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, passive\n);
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, active\n);
+ case THERMAL_TRIP_STATE_ACTIVE:
+ return sprintf(buf, state-active\n);
default:
return sprintf(buf, unknown\n);
}
@@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
void thermal_zone_device_update(struct thermal_zone_device *tz)
{
- int count, ret = 0;
- long temp, trip_temp;
+ int count, ret = 0, inst_id;
+ long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
- struct thermal_cooling_device_instance *instance;
+ struct thermal_cooling_device_instance *instance, *state_instance;
struct thermal_cooling_device *cdev;
mutex_lock(tz-lock);
@@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
cdev-ops-set_cur_state(cdev, 0);
}
break;
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+ if (instance-trip != count)
+ continue;
+
+ if (temp = last_trip_change)
+ continue;
+
+ inst_id = 0;
+ /*
+ *For this instance how many instance of same
+ *cooling device occured before
+ */
+
+ list_for_each_entry(state_instance,
+ tz-cooling_devices, node) {
+ if (instance-cdev ==
+ state_instance-cdev)
+ inst_id++;
+ if (state_instance-trip == count)
+ break;
+ }
Can you explain a bit more on this loop and the set_cur_state below ?
Sorry, I don't get the logic behind this..
This loop is basically finding the instance id of the same cooling device.
Say we have done like this,
thermal_zone_bind_cooling_device(thermal, 2, cdev);
thermal_zone_bind_cooling_device(thermal, 3, cdev);
thermal_zone_bind_cooling_device(thermal, 4, cdev);
In above same cooling device cdev is binded to trip no 2,3 and 4 with
inst_id generated as 1,2,3 respectively. so set_cur_state for those
trip reached will be called as,
set_cur_state(cdev, 1);
set_cur_state(cdev, 2);
set_cur_state(cdev, 3);
Thanks,
Amit D
Re: February 2012 Kernel Release
On 21 February 2012 16:37, Kukjin Kim kgene@samsung.com wrote: Amit Kachhap wrote: Hi kukjin Kim, Hi, I was on travel for elc and linaro conferences so little late for replying. Thanks for testing these patches. I just submitted the V6 series of the cpuidle patchset. I rebased it against the 3.3-rc4 kernel version. I also tested it for SMDKV310 (evt1) and Origen (evt1.1) boards and they are working fine. Some modification was done for CHECK_FLAG. OK, I checked it works fine on SMDKV310 now. As I said, will apply your patches for v3.4 but I'm not sure there is a problem with common cpuidle work. These patches could be part of your for-next branch (and available for v3.4 merge) and any work on common cpuidle code would be incremental changes to this patchset. Regards, Amit Daniel Anyway, good job. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Thanks, Amit Daniel On 18 February 2012 07:29, Kukjin Kim kgene@samsung.com wrote: Amit Kachhap wrote: Hi Amit Kucheria, Hi all, (Cc'ed Jaecheol Lee and Jongpill Lee) I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 month back. But seems like it is not present. If it works fine, then I'm apply this series. But now it is not working. As a note, I use your series on top of v3.3- rc3 and fixed following for test. arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of function 'BSYM' make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then rebooting happened. See below log. If any updates, please let me know. --- Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKV310 Memory policy: ECC disabled, Data cache writealloc CPU EXYNOS4210 (id 0x43210010) [snip] [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ [root@Samsung cpuidle]# ls state0/ state1/ [root@Samsung cpuidle]# cd state1 [root@Samsung state1]# ls desc latency name power time usage [root@Samsung state1]# cat name C1 [root@Samsung state1]# cat time 0 [root@Samsung state1]# echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung state1]# ðK U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 ... [snip] Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKC210 [snip] Samsung SMDK Board on a armv7l Samsung login: root login[1002]: root login on 'ttySAC1' [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung ~]# O [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Hi Mr Kim, Can you please queue this patchset in your tree for next merge window? The V5 version submitted fixes all the known issues. http://lists.infradead.org/pipermail/linux-arm-kernel/2012- January/079214.html Thanks, Amit Daniel On 17 February 2012 11:42, Amit Kucheria amit.kuche...@linaro.org wrote: On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena dsax...@linaro.org wrote: - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG Amit, is this now in your maintainer's tree queued up for 3.4? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: February 2012 Kernel Release
Hi kukjin Kim, I was on travel for elc and linaro conferences so little late for replying. Thanks for testing these patches. I just submitted the V6 series of the cpuidle patchset. I rebased it against the 3.3-rc4 kernel version. I also tested it for SMDKV310 (evt1) and Origen (evt1.1) boards and they are working fine. Some modification was done for CHECK_FLAG. Thanks, Amit Daniel On 18 February 2012 07:29, Kukjin Kim kgene@samsung.com wrote: Amit Kachhap wrote: Hi Amit Kucheria, Hi all, (Cc'ed Jaecheol Lee and Jongpill Lee) I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 month back. But seems like it is not present. If it works fine, then I'm apply this series. But now it is not working. As a note, I use your series on top of v3.3-rc3 and fixed following for test. arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of function 'BSYM' make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then rebooting happened. See below log. If any updates, please let me know. --- Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKV310 Memory policy: ECC disabled, Data cache writealloc CPU EXYNOS4210 (id 0x43210010) [snip] [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ [root@Samsung cpuidle]# ls state0/ state1/ [root@Samsung cpuidle]# cd state1 [root@Samsung state1]# ls desc latency name power time usage [root@Samsung state1]# cat name C1 [root@Samsung state1]# cat time 0 [root@Samsung state1]# echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung state1]# ðK U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 ... [snip] Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKC210 [snip] Samsung SMDK Board on a armv7l Samsung login: root login[1002]: root login on 'ttySAC1' [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung ~]# O [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Hi Mr Kim, Can you please queue this patchset in your tree for next merge window? The V5 version submitted fixes all the known issues. http://lists.infradead.org/pipermail/linux-arm-kernel/2012- January/079214.html Thanks, Amit Daniel On 17 February 2012 11:42, Amit Kucheria amit.kuche...@linaro.org wrote: On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena dsax...@linaro.org wrote: - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG Amit, is this now in your maintainer's tree queued up for 3.4? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: February 2012 Kernel Release
Hi Amit Kucheria, I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 month back. But seems like it is not present. Hi Mr Kim, Can you please queue this patchset in your tree for next merge window? The V5 version submitted fixes all the known issues. http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/079214.html Thanks, Amit Daniel On 17 February 2012 11:42, Amit Kucheria amit.kuche...@linaro.org wrote: On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena dsax...@linaro.org wrote: - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG Amit, is this now in your maintainer's tree queued up for 3.4? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Last call for patches for the 12.02 release of linux-linaro kernel
Hi Andrey, Please pull my latest thermal changes from git://git.linaro.org/people/amitdanielk/linux.gitexynos_thermal_latest The configs option which needed to be turn on is defined below, https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Arch-independent-1 https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Samsung_Exynos Thanks, Amit Daniel On 13 February 2012 12:22, Andrey Konovalov andrey.konova...@linaro.org wrote: Greetings, If someone has something which is not in the mainline, was not in the 12.01 kernel release, but worth including into the 12.02 kernel release, please let me know by the end of Feb 14, PST (the git branch where I could pull from). This release will be v3.3-rc3 based, so you patches should be based on that (easiest for me), or on the tip of the linus tree. My expectations are that the power management WG has some topics to add to the 12.02. I am aware of git://git.secretlab.ca/git/linux-2.6.git, irqdomain/next The kernel working group has some blueprints for 12.02. Please let me know, if there is something for me to do here. The following commits from linux-linaro-3.2 branch will be carried over to 12.02: commit 2eb6f8b98d8471c83be7e3ab53fe4386884c96a9 Author: Vincent Guittot vincent.guit...@linaro.org Date: Fri Oct 21 09:02:47 2011 +0200 sched: Ensure cpu_power periodic update commit 2b21b980917662503a16e079b5d4a5a8a17886cd Author: Arnd Bergmann a...@arndb.de Date: Sat Oct 8 17:07:50 2011 +0200 ARM: kprobes: work around build errors commit 61d24dd4d0528d369ea81f6e5d5e1db9c62ad46a Author: Ming Lei ming@canonical.com Date: Wed Aug 31 00:03:13 2011 +0800 usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP Amit (Amit Daniel Kachhap), please let me know if for 12.02 I should use the commits below, or take an updated version from you: ARM: exynos4: Add thermal sensor driver platform device support thermal: exynos4: Register the tmu sensor with the thermal interface layer thermal: exynos: Add thermal interface support for linux thermal layer thermal: Add generic cpu cooling implementation thermal: Add a new trip type to use cooling device instance number EXYNOS: Make EXYNOS common cpufreq driver ARM: exynos: Enable l2 configuration through device tree ARM: exynos: remove useless code to save/restore L2 ARM: exynos: save L2 settings during bootup ARM: s5p: add L2 early resume code ARM: exynos: Add support AFTR mode on EXYNOS4210 Thanks, Andrey Konovalov ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [RFC PATCH] thermal: Add support to report cooling statistics achieved by cooling devices
Hi eduardo,
Thanks for the detail review.
On 6 February 2012 23:09, Eduardo Valentin eduardo.valen...@ti.com wrote:
Hello Amit,
some comments embedded.
On Wed, Jan 18, 2012 at 02:51:07PM +0530, Amit Daniel Kachhap wrote:
Add a sysfs node code to report effective cooling of all cooling devices
attached to each trip points of a thermal zone. The cooling data reported
will be absolute if the higher temperature trip points are arranged first
otherwise the cooling stats is the cumulative effect of the earlier
invoked cooling handlers.
The basic assumption is that cooling devices will bring down the temperature
in a symmetric manner and those statistics can be stored back and used for
further tuning of the system.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt | 10
drivers/thermal/thermal_sys.c | 96
+++
include/linux/thermal.h | 8 +++
3 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index b61e46f..1db9a9d 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -209,6 +209,13 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+trip_stats
+ This attribute presents the effective cooling generated from all the
+ cooling devices attached to a trip point. The output is a pair of value
+ for each trip point. Each pair represents
+ (trip index, cooling temperature difference in millidegree Celsius)
+ RO, Optional
+
*
* Cooling device attributes *
*
@@ -261,6 +268,9 @@ method, the sys I/F structure will be built like this:
|---cdev0_trip_point: 1 /* cdev0 can be used for passive */
|---cdev1: ---/sys/class/thermal/cooling_device3
|---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
+ |---trip_stats 0 0
+ 1 8000 /*trip 1 causes 8 degree Celsius drop*/
+ 2 3000 /*trip 2 causes 3 degree Celsius drop*/
|cooling_device0:
|---type: Processor
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..47e7b6e 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -92,6 +92,64 @@ static void release_idr(struct idr *idr, struct mutex
*lock, int id)
if (lock)
mutex_unlock(lock);
}
+static void update_cooling_stats(struct thermal_zone_device *tz, long
cur_temp)
+{
+ int count, max_index, cur_interval;
+ long trip_temp, max_temp = 0, cool_temp;
+ static int last_trip_level = -1;
I got confused here. Are you sure using a static variable here is safe? I
suppose this function
is called for any thermal_zone_device, which in turns, may have different
amount of trips, and
different update rate. You may be using last_trip_level as reference for a
different tz. Meaning,
you would be screwing the stat buffers silently.
If that is the case, I suggest you to move this to your stat structure.
Agree. This looks a clear problem. Surely i will move last_trip_level
inside structure tz.
+
+ if (cur_temp = tz-last_temperature)
+ return;
+
+ /* find the trip according to last temperature */
+ for (count = 0; count tz-trips; count++) {
+ tz-ops-get_trip_temp(tz, count, trip_temp);
+ if (tz-last_temperature = trip_temp) {
+ if (max_temp trip_temp) {
+ max_temp = trip_temp;
+ max_index = count;
+ }
+ }
+ }
+
+ if (!max_temp) {
+ last_trip_level = -1;
+ return;
+ }
+
+ cur_interval = tz-stat[max_index].interval_ptr;
+ cool_temp = tz-last_temperature - cur_temp;
+
+ if (last_trip_level != max_index) {
+ if (++cur_interval == INTERVAL_HISTORY)
+ cur_interval = 0;
+ tz-stat[max_index].cool_temp[cur_interval] = cool_temp;
+ tz-stat[max_index].interval_ptr = cur_interval;
+ last_trip_level = max_index;
+ } else {
+ tz-stat[max_index].cool_temp[cur_interval] += cool_temp;
Why do you need to sum up here? Wouldn't this break your statistics? (I may
completely missed your idea for last_trip_level).
This will be summed up because after applying cooling action there is
some cooling happening but not enough to change the trip level. So
unless there is cooling enough to change the trip level I keep summing
the temperature.
+ }
+}
+
+static int calculate_cooling_temp_avg(struct thermal_zone_device *tz, int
trip,
+
Re: [linux-pm] [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
Hi eduardo, Again thanks for the review. On 7 February 2012 00:25, Eduardo Valentin eduardo.valen...@ti.com wrote: Hello Amit, On Tue, Dec 13, 2011 at 08:43:16PM +0530, Amit Daniel Kachhap wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling and cpuhotplugg currently. 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 API's return the cooling device pointer. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 52 + drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 302 + include/linux/cpu_cooling.h | 45 + 5 files changed, 411 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..d30b4f2 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling api's How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 13 Dec 2011 + +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug) provides +registration/unregistration api's to the user. The binding of the cooling +devices to the trip types is left for the user. The registration api's returns +the cooling device pointer. + +1. cpufreq cooling api's + +1.1 cpufreq registration api's +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_pctg_table *tab_ptr, unsigned int tab_size, + const struct cpumask *mask_val) + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq. + + tab_ptr: The table containing the percentage of frequency to be clipped for + each cooling state. + .freq_clip_pctg[NR_CPUS]:Percentage of frequency to be clipped for each + cpu. + .polling_interval: polling interval for this cooling state. + tab_size: the total number of cooling state. + mask_val: all the allowed cpu's where frequency clipping can happen. + +1.1.2 void cpufreq_cooling_unregister(void) + + This interface function unregisters the thermal-cpufreq cooling device. + + +1.2 cpuhotplug registration api's + +1.2.1 struct thermal_cooling_device *cpuhotplug_cooling_register( + const struct cpumask *mask_val) + + This interface function registers the cpuhotplug cooling device with the name + thermal-cpuhotplug. + + mask_val: all the allowed cpu's which can be hotplugged out. + +1.1.2 void cpuhotplug_cooling_unregister(void) + + This interface function unregisters the thermal-cpuhotplug cooling device. diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f7f71b2..298c1cd 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -18,3 +18,14 @@ config THERMAL_HWMON depends on THERMAL depends on HWMON=y || HWMON=THERMAL default y + +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL + 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 or M here. diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 31108a0..655cbc4 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c new file mode 100644 index 000..cdd148c --- /dev/null +++ b/drivers/thermal/cpu_cooling.c @@ -0,0 +1,302 @@ +/* + * linux/drivers/thermal/cpu_cooling.c + * + * Copyright (C) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) + * Copyright (C) 2011 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
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On 3 February 2012 12:42, Zhang Rui rui.zh...@intel.com wrote: Hi, sorry for the late response. On 四, 2012-01-19 at 14:47 +0530, Amit Kachhap wrote: On 13 December 2011 20:43, Amit Daniel Kachhap amit.kach...@linaro.org wrote: PATCH 1) [thermal: Add a new trip type to use cooling device instance number] This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. Sorry, I'm still not quite clear about how this will be used. Say, processor has P0~P3, then we need to register a thermal zone with three STATE_ACTIVE trip points, like the picture shown below? processor in full speed, i.e. P0 state active trip point 1 processor in P1 state active trip point 2 processor in P2 state active trip point 3 processor in P3 Thanks for the review. Your representation of the 3 PSTATES and trip points are correct. Also remember the case that we have registered one cpufreq cooling device and binded 3 instance of it with the 3 trip points. So in the current patch set_cur_state will pass the instance id also which will help in moving to the current P state. This same behaviour is achieved through PASSIVE state but it iterates through all the P states. so the current patch avoids the iteration and goes to a single state directly. PATCH 2) [thermal: Add generic cpu cooling implementation] This patch adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. 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. It seems that we can convert the ACPI processor thermal driver to follow this generic cpu cooling implementation, right? I am not sure if we can convert the processor thermal driver because it performs other cpu cooling like throttling, idle etc and then ACPI abstraction on top of it. I am thinking of exporting the generic low level cooling implementation like this patch is doing from processor_thermal.c file so that it can be usable with non-acpi interface. What is your opinion about it? Thanks, Amit Daniel thanks, rui Any comments on these patches? I submitted them quite long back. Regards, Amit D Amit Daniel Kachhap (2): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpu cooling implementation Documentation/thermal/cpu-cooling-api.txt | 52 + Documentation/thermal/sysfs-api.txt | 4 +- drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 302 + drivers/thermal/thermal_sys.c | 27 +++- include/linux/cpu_cooling.h | 45 + include/linux/thermal.h | 1 + 8 files changed, 440 insertions(+), 3 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
On 1 February 2012 20:27, Matthew Garrett m...@redhat.com wrote: On Tue, Dec 13, 2011 at 08:43:16PM +0530, Amit Daniel Kachhap wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling and cpuhotplugg currently. We've been over this kind of thing in the past. cpu hotplug is a relatively expensive operation, so people have previously been enthusiastic about using the scheduler to simply avoid running anything on CPUs if they're overheating. Has any general consensus been reached on this? yes you are right that cpuhotplug is an expensive process and it may further heat up the system before turning off so the ideal way would be to reduce the capacity of the cpu gradually. Anyway these patches are only exporting those API's and the actual use of them depends on the user. Although my bigger focus is on cpufreq as cooling devices so I might remove cpuhotplug in the next version. I'm also not entirely thrilled at now having two ways to manage the cpu through the thermal layer. ACPI already plugs in via the passive trip points. If we're going to do this then I'd like to see the ACPI code merged in with the generic cpu cooling code. Yeah I also agree that there is a kind of repetition and not entirely sure where to place these codes. I will try adding them inside acpi. Thanks for the suggestion. -- Matthew Garrett | mj...@srcf.ucam.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
On 1 February 2012 20:19, Matthew Garrett m...@redhat.com wrote:
I'm not really a fan of this as it stands - the name isn't very
intuitive and the code's pretty difficult to read. Would the following
(incomplete and obviously untested) not have the effect you want? Then
you register multiple trip points with the same cooling device but
different private values, and the state set does whatever you want it
to. Or am I misunderstanding the problem you're trying to solve?
Thanks for the detailed review of the patch. Actually i tried to merge the
benefits of trip type ACTIVE and PASSIVE into one so this name. This new
trip type is just like ACTIVE but instead of OFF(0)/ON(1) all values
greater then 0 is on. Anyways I looked at your implementation below but
this will not solve the purpose as thermal_cooling_device_register() need
to be be called only once to register a cooling device such cpu frequency
based. However the same cooling device may be binded many times to
different trips.
Say,
1) thermal_zone_bind_cooling_device(tz_dev, 0, cdev);
2) thermal_zone_bind_cooling_device(tz_dev, 1, cdev);
3) thermal_zone_bind_cooling_device(tz_dev, 2, cdev);
0,1, 2 are nothing but trip points so the set_cur_state should be called
like
set_cur_state(cdev, 0)
set_cur_state(cdev, 1)
set_cur_state(cdev, 2) when the trip point threshold are crossed.
Yeah I agree that implementation logic looks complex but this to prevent
the lower temp trip points cooling handlers to be called. I will surely
make this better in next version.
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 220ce7e..817f2ba 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -50,6 +50,7 @@ struct thermal_cooling_device_instance {
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
struct list_head node;
+ unsigned long private;
};
static DEFINE_IDR(thermal_tz_idr);
@@ -909,7 +910,8 @@ static struct class thermal_class = {
* @ops: standard thermal cooling devices callbacks.
*/
struct thermal_cooling_device *thermal_cooling_device_register(
- char *type, void *devdata, const struct thermal_cooling_device_ops
*ops)
+ char *type, void *devdata, const struct thermal_cooling_device_ops
*ops,
+ unsigned long private)
{
struct thermal_cooling_device *cdev;
struct thermal_zone_device *pos;
@@ -936,6 +938,7 @@ struct thermal_cooling_device
*thermal_cooling_device_register(
cdev-ops = ops;
cdev-device.class = thermal_class;
cdev-devdata = devdata;
+ cdev-private = private;
dev_set_name(cdev-device, cooling_device%d, cdev-id);
result = device_register(cdev-device);
if (result) {
@@ -1079,11 +1082,14 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
continue;
cdev = instance-cdev;
-
- if (temp = trip_temp)
- cdev-ops-set_cur_state(cdev, 1);
- else
- cdev-ops-set_cur_state(cdev, 0);
+ if (cdev-private) {
+ cdev-ops-set_cur_state(cdev,
cdev-private);
+ } else {
+ if (temp = trip_temp)
+
cdev-ops-set_cur_state(cdev, 1);
+ else
+
cdev-ops-set_cur_state(cdev, 0);
+ }
}
break;
case THERMAL_TRIP_PASSIVE:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 796f1ff..04aac09 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -148,7 +148,7 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *, int,
struct thermal_cooling_device *);
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 *);
+const struct thermal_cooling_device_ops *, unsigned
long private);
void thermal_cooling_device_unregister(struct thermal_cooling_device *);
#ifdef CONFIG_NET
--
Matthew Garrett | mj...@srcf.ucam.org
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
On 1 February 2012 20:19, Matthew Garrett m...@redhat.com wrote:
I'm not really a fan of this as it stands - the name isn't very
intuitive and the code's pretty difficult to read. Would the following
(incomplete and obviously untested) not have the effect you want? Then
you register multiple trip points with the same cooling device but
different private values, and the state set does whatever you want it
to. Or am I misunderstanding the problem you're trying to solve?
Thanks for the detailed review of the patch. Actually i tried to merge
the benefits of trip type ACTIVE and PASSIVE into one so this name.
This new trip type is just like ACTIVE but instead of OFF(0)/ON(1)
all values greater then 0 is on. Anyways I looked at your
implementation below but this will not solve the purpose as
thermal_cooling_device_register() need to be be called only once to
register a cooling device such cpu frequency based. However the same
cooling device may be binded many times to different trips.
Say,
1) thermal_zone_bind_cooling_device(tz_dev, 0, cdev);
2) thermal_zone_bind_cooling_device(tz_dev, 1, cdev);
3) thermal_zone_bind_cooling_device(tz_dev, 2, cdev);
0,1, 2 are nothing but trip points so the set_cur_state should be called like
set_cur_state(cdev, 0)
set_cur_state(cdev, 1)
set_cur_state(cdev, 2) when the trip point threshold are crossed.
Yeah I agree that implementation logic looks complex but this to
prevent the lower temp trip points cooling handlers to be called. I
will surely make this better in next version.
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 220ce7e..817f2ba 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -50,6 +50,7 @@ struct thermal_cooling_device_instance {
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
struct list_head node;
+ unsigned long private;
};
static DEFINE_IDR(thermal_tz_idr);
@@ -909,7 +910,8 @@ static struct class thermal_class = {
* @ops: standard thermal cooling devices callbacks.
*/
struct thermal_cooling_device *thermal_cooling_device_register(
- char *type, void *devdata, const struct thermal_cooling_device_ops *ops)
+ char *type, void *devdata, const struct thermal_cooling_device_ops
*ops,
+ unsigned long private)
{
struct thermal_cooling_device *cdev;
struct thermal_zone_device *pos;
@@ -936,6 +938,7 @@ struct thermal_cooling_device
*thermal_cooling_device_register(
cdev-ops = ops;
cdev-device.class = thermal_class;
cdev-devdata = devdata;
+ cdev-private = private;
dev_set_name(cdev-device, cooling_device%d, cdev-id);
result = device_register(cdev-device);
if (result) {
@@ -1079,11 +1082,14 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
continue;
cdev = instance-cdev;
-
- if (temp = trip_temp)
- cdev-ops-set_cur_state(cdev, 1);
- else
- cdev-ops-set_cur_state(cdev, 0);
+ if (cdev-private) {
+ cdev-ops-set_cur_state(cdev,
cdev-private);
+ } else {
+ if (temp = trip_temp)
+
cdev-ops-set_cur_state(cdev, 1);
+ else
+
cdev-ops-set_cur_state(cdev, 0);
+ }
}
break;
case THERMAL_TRIP_PASSIVE:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 796f1ff..04aac09 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -148,7 +148,7 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *, int,
struct thermal_cooling_device *);
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 *);
+ const struct thermal_cooling_device_ops *, unsigned long
private);
void thermal_cooling_device_unregister(struct thermal_cooling_device *);
#ifdef CONFIG_NET
--
Matthew Garrett | mj...@srcf.ucam.org
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On 13 December 2011 20:43, Amit Daniel Kachhap amit.kach...@linaro.org wrote: PATCH 1) [thermal: Add a new trip type to use cooling device instance number] This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. PATCH 2) [thermal: Add generic cpu cooling implementation] This patch adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. 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. Any comments on these patches? I submitted them quite long back. Regards, Amit D Amit Daniel Kachhap (2): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpu cooling implementation Documentation/thermal/cpu-cooling-api.txt | 52 + Documentation/thermal/sysfs-api.txt | 4 +- drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 302 + drivers/thermal/thermal_sys.c | 27 +++- include/linux/cpu_cooling.h | 45 + include/linux/thermal.h | 1 + 8 files changed, 440 insertions(+), 3 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro powertop doesn't work during initialization of ncurse
Hi Chanwoo Choi, I remember I found some of those issues when making cross-compiled static powertop binaries due to incompatible ncurses database files. Then I moved to native compilation of powertop binaries for ARM boards. May be this will give you some pointers. Anyway I will test with new libcurses library and let you know. Thanks, Amit Daniel On 12 January 2012 17:37, Chanwoo Choi cwcho...@gmail.com wrote: Hi Amit, I used linaro powertop to check idle state on embedded board with EXYNOS4 series. I modified Makefile to use -lncurse instead of -lncursew and it was well operated on my board. - kernel : 2.6.36 - libncurse : libncurses5-dev But, same powertop binary doesn't work on new embedded board. When execute powertop, I faced one problem which stop powertop during initialization of ncurse in display.cpp. (init_display function) - kernel : 3.0 - libncurse : libncurses5-dev Does anyone have experience about it? Regards, Chanwoo Choi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
On 11 January 2012 13:32, Rob Lee rob@linaro.org wrote: Hey Amit, I was able to use your code on an i.MX6Q thermal implementation and it seemed to work pretty well. Thanks for adding this. A couple of comments below. Thanks for testing and reviewing the code. On Tue, Dec 13, 2011 at 9:13 AM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling and cpuhotplugg currently. 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 API's return the cooling device pointer. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 52 + drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 302 + include/linux/cpu_cooling.h | 45 + 5 files changed, 411 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..d30b4f2 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling api's How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 13 Dec 2011 + +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug) provides +registration/unregistration api's to the user. The binding of the cooling +devices to the trip types is left for the user. The registration api's returns +the cooling device pointer. + +1. cpufreq cooling api's + +1.1 cpufreq registration api's +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_pctg_table *tab_ptr, unsigned int tab_size, + const struct cpumask *mask_val) + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq. + + tab_ptr: The table containing the percentage of frequency to be clipped for + each cooling state. + .freq_clip_pctg[NR_CPUS]:Percentage of frequency to be clipped for each + cpu. + .polling_interval: polling interval for this cooling state. + tab_size: the total number of cooling state. + mask_val: all the allowed cpu's where frequency clipping can happen. + +1.1.2 void cpufreq_cooling_unregister(void) + + This interface function unregisters the thermal-cpufreq cooling device. + + +1.2 cpuhotplug registration api's + +1.2.1 struct thermal_cooling_device *cpuhotplug_cooling_register( + const struct cpumask *mask_val) + + This interface function registers the cpuhotplug cooling device with the name + thermal-cpuhotplug. + + mask_val: all the allowed cpu's which can be hotplugged out. + +1.1.2 void cpuhotplug_cooling_unregister(void) + + This interface function unregisters the thermal-cpuhotplug cooling device. diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f7f71b2..298c1cd 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -18,3 +18,14 @@ config THERMAL_HWMON depends on THERMAL depends on HWMON=y || HWMON=THERMAL default y + +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL + 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 or M here. diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 31108a0..655cbc4 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c new file mode 100644 index 000..cdd148c --- /dev/null +++ b/drivers/thermal/cpu_cooling.c @@ -0,0 +1,302 @@ +/* + * linux/drivers/thermal/cpu_cooling.c + * + * Copyright (C) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) + * Copyright (C) 2011 Amit Daniel amit.kach...@linaro.org + * + * ~~ + * This
Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Rob,
I got your point. The main idea of doing like this is to keep the
cooling implementation independent from thermal zone
algorithms(thermal_sys.c). But binding freq_tab index to the trip
numbers may be not be bad idea. I will give more thought into it in
the next patchset.
Regards,
Amit D
On 11 January 2012 13:42, Rob Lee rob@linaro.org wrote:
Hey Amit/Vincent,
It appears that with this implementation the STATE_ACTIVE trip number
used will also be the index of the cool_freq_tab used. If that is
true, then perhaps a common structure would be beneficial that links
each STATE_ACTIVE trip point with its corresponding cooling data.
BR,
Rob
On Tue, Dec 20, 2011 at 11:11 PM, Amit Kachhap amit.kach...@linaro.org
wrote:
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cpu frequency. But
this has to be done again in cooling devices so to make the cooling
devices generic and to avoid the temperature comparison again this new
trip type passes the cooling device instance id.
Also about your queries that this may add dependency between trip
index and cooling state. This is actually needed and this dependency
is created when the cooling device is binded with trip points(For
cpufreq type cooling device just the instance of cooling device is
associated with trip points). More over the existing PASSIVE cooling
trip type does the same thing and iterates across all the cooling
state.
Thanks,
Amit Daniel
On 20 December 2011 18:07, Vincent Guittot vincent.guit...@linaro.org
wrote:
Hi Amit,
I'm not sure that using the trip index for setting the state of a
cooling device is a generic solution because you are adding a
dependency between the trip index and the cooling device state that
might be difficult to handle. This dependency implies that a cooling
device like cpufreq_cooling_device must be registered in the 1st trips
of a thermal_zone which is not possible when we want to register 2
cpufreq_cooling_devices in the same thermal_zone.
You should only rely on the current and last temperatures to detect if
a trip_temp has been crossed and you should increase or decrease the
current state of the cooling device accordingly.
something like below should work with cpufreq_cooling_device and will
not add any constraint on the trip index. The state of a cooling
device is increased/decreased once for each trip
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+ if (instance-trip != count)
+ continue;
+
+ cdev = instance-cdev;
+
+ if ((temp = trip_temp)
+ (trip_temp
tz-last_temperature)) {
+ cdev-ops-get_max_state(cdev,
+ max_state);
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (++current_state = max_state)
+
cdev-ops-set_cur_state(cdev,
+
current_state);
+ }
+ else if ((temp trip_temp)
+ (trip_temp =
tz-last_temperature)) {
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (current_state 0)
+
cdev-ops-set_cur_state(cdev,
+
--current_state);
+ }
+ break;
Regards,
Vincent
On 13 December 2011 16:13, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt | 4 ++--
drivers/thermal/thermal_sys.c | 27 ++-
include/linux/thermal.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Zach/Ricardo, All the thermal Kconfigs are enabled in https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig. Thanks, Amit D On 10 January 2012 23:55, Amit Kucheria amit.kuche...@linaro.org wrote: Amit, could you please add the required Kconfig options that need to be enabled to https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig under Exynos-Thermal? Zach and Ricardo will then ensure that their kernels have those Kconfig options enabled. /Amit On Wed, Dec 14, 2011 at 6:54 PM, Amit Kachhap amit.kach...@linaro.org wrote: Hi Nicolas, Please pull my samsung thermal implementation work from git repository (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). Some of the patches are under review and some are in mainline in 3.2 rc* version. It is all based on the tip of your tree. The patches are added since commit id 971be11492b1e248798f7078592b1fa0dfbf3534 Thanks, Amit Daniel On 14 December 2011 20:11, Amit Kachhap amit.kach...@linaro.org wrote: Hi Nicolas, Is it possible for you to add these 2 patches for this month release? I am not able to give you the git link as there is seems some problem with the linaro git server. Also I attached the patches in case required. Thanks, Amit Daniel On 13 December 2011 20:43, Amit Daniel Kachhap amit.kach...@linaro.org wrote: PATCH 1) [thermal: Add a new trip type to use cooling device instance number] This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. PATCH 2) [thermal: Add generic cpu cooling implementation] This patch adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. 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. Amit Daniel Kachhap (2): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpu cooling implementation Documentation/thermal/cpu-cooling-api.txt | 52 + Documentation/thermal/sysfs-api.txt |4 +- drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 302 + drivers/thermal/thermal_sys.c | 27 +++- include/linux/cpu_cooling.h | 45 + include/linux/thermal.h |1 + 8 files changed, 440 insertions(+), 3 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
Hi Guenter,
The main idea of this work is to leave the current userspace based
notification scheme and add the kernel based cooling scheme on top of
it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
this creates 2 hwmon entries.
Adding CC: Donggeun Kim to know his opinion.
Thanks,
Amit Daniel
On 4 January 2012 03:55, Guenter Roeck guenter.ro...@ericsson.com wrote:
On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
Export and register information from the hwmon tmu sensor to the samsung
exynos kernel thermal framework where different cooling devices and thermal
zone are binded. The exported information is based according to the data
structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
functions are currently left although all of them are present in generic
linux thermal layer.
Also the platform data structure is modified to pass frequency cooling
in percentages for each thermal level.
Hi Amit,
wouldn't it make more sense to merge the code as necessary from
hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
hwmon/exynos4_tmu.c entirely ?
With that, you should get the hwmon entries for free, and we would not
have to maintain two drivers with overlapping functionality.
Thanks,
Guenter
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/hwmon/exynos4_tmu.c | 34
++--
include/linux/platform_data/exynos4_tmu.h | 7 ++
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
index f2359a0..6912a7f 100644
--- a/drivers/hwmon/exynos4_tmu.c
+++ b/drivers/hwmon/exynos4_tmu.c
@@ -37,6 +37,9 @@
#include linux/hwmon-sysfs.h
#include linux/platform_data/exynos4_tmu.h
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+#include linux/exynos_thermal.h
+#endif
#define EXYNOS4_TMU_REG_TRIMINFO 0x0
#define EXYNOS4_TMU_REG_CONTROL 0x20
@@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
kobject_uevent(data-hwmon_dev-kobj, KOBJ_CHANGE);
- enable_irq(data-irq);
clk_disable(data-clk);
mutex_unlock(data-lock);
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ exynos4_report_trigger();
+#endif
+ enable_irq(data-irq);
}
static irqreturn_t exynos4_tmu_irq(int irq, void *id)
@@ -345,6 +351,14 @@ static const struct attribute_group
exynos4_tmu_attr_group = {
.attrs = exynos4_tmu_attributes,
};
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+static struct thermal_sensor_conf exynos4_sensor_conf = {
+ .name = exynos4-therm,
+ .read_temperature = (int (*)(void *))exynos4_tmu_read,
+};
+#endif
+/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
+
static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
{
struct exynos4_tmu_data *data;
@@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct
platform_device *pdev)
}
exynos4_tmu_control(pdev, true);
-
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ (exynos4_sensor_conf)-private_data = data;
+ (exynos4_sensor_conf)-sensor_data = pdata;
+ ret = exynos4_register_thermal(exynos4_sensor_conf);
+ if (ret) {
+ dev_err(pdev-dev, Failed to register thermal interface\n);
+ goto err_hwmon_device;
+ }
+#endif
return 0;
-
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+err_hwmon_device:
+ hwmon_device_unregister(data-hwmon_dev);
+#endif
err_create_group:
sysfs_remove_group(pdev-dev.kobj, exynos4_tmu_attr_group);
err_clk:
@@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct
platform_device *pdev)
exynos4_tmu_control(pdev, false);
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ exynos4_unregister_thermal();
+#endif
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(pdev-dev.kobj, exynos4_tmu_attr_group);
diff --git a/include/linux/platform_data/exynos4_tmu.h
b/include/linux/platform_data/exynos4_tmu.h
index 39e038c..642c508 100644
--- a/include/linux/platform_data/exynos4_tmu.h
+++ b/include/linux/platform_data/exynos4_tmu.h
@@ -21,6 +21,7 @@
#ifndef _LINUX_EXYNOS4_TMU_H
#define _LINUX_EXYNOS4_TMU_H
+#include linux/cpu_cooling.h
enum calibration_type {
TYPE_ONE_POINT_TRIMMING,
@@ -64,6 +65,9 @@ enum calibration_type {
* in the positive-TC generator block
* 0 = reference_voltage = 31
* @cal_type: calibration type for temperature
+ * @freq_pctg_table: Table representing frequency reduction percentage.
+ * @freq_tab_count: Count of the above table as frequency reduction may
+ * applicable to only some of the trigger levels.
*
* This structure is required for configuration of exynos4_tmu driver.
*/
@@ -79,5 +83,8 @@ struct exynos4_tmu_platform_data {
u8 reference_voltage;
enum calibration_type cal_type;
+
+ struct
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
On 3 January 2012 18:52, Kukjin Kim kgene@samsung.com wrote: amit kachhap wrote: Hi Mr kim, All the comments have been addressed for the Exynos cpu idle patchset. The updated patchset was posted about one month back and there have been no further comments on the patchset since then. As this patchset seems to be stable now, do you think these these patches can merged in this 3.3 merge window? Kindly let me know your opinion. This conflicts with local common.[ch] working for ARM restart. Please wait until after the merge window for this patches. Thanks for the update. Actually I have fixed the merging issue in common.[ch] files so sending the V5 series of the patchset shortly. If possible add in this merge window or next merge window is also fine. Regards, Amit daniel Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
Hi Mr kim, All the comments have been addressed for the Exynos cpu idle patchset. The updated patchset was posted about one month back and there have been no further comments on the patchset since then. As this patchset seems to be stable now, do you think these these patches can merged in this 3.3 merge window? Kindly let me know your opinion. Thanks, Amit Daniel On Mon, Dec 5, 2011 at 4:36 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: Changes since V3: *Implemented Russell feedback and moved sleep magic 4byte memory before s3c_cpu_resume to data section. Changes since V2: *Implemented the suggestion of MyungJoo Ham and used INFORM0/1 registers for resume for some board versions. *Added back save/restore through CPU PM notifiers as suggested by Lorenzo Pieralisi. This is useful to restore vfp state. *some patch modularization (s5p/exynos) and proper commit logs. Changes since V1: *rebased the whole patch against 3.2-rc1 tree *removed GIC save/restore in AFTR cpuidle state as it is external to cpu powerdomain *Added L2 setup code through device tree *Removed only l2 save/restore registers in sleep This Patch series adds support for AFTR mode cpuidle state based on patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier submitted by Jaecheol Lee jc@samsung.com. This patch uses CPU PM notifiers , common l2 save/restore and new cpu_suspend/resume interfaces and is based on the tip of for-next branch of samsung tree. (git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next). Amit Daniel Kachhap (5): ARM: exynos: Add support AFTR mode on EXYNOS4210 ARM: exynos: save L2 settings during bootup ARM: s5p: add L2 early resume code ARM: exynos: remove useless code to save/restore L2 ARM: exynos: Enable l2 configuration through device tree arch/arm/mach-exynos/cpu.c | 60 +--- arch/arm/mach-exynos/cpuidle.c | 152 ++- arch/arm/mach-exynos/include/mach/pmu.h | 2 + arch/arm/mach-exynos/pm.c | 15 --- arch/arm/plat-s5p/sleep.S | 44 - 5 files changed, 233 insertions(+), 40 deletions(-) -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cufreq. But this has to
be done again in cooling devices so to make the cooling devices generic and
to avoid the temperature comparision again this new trip type passes the
cooling device instance id.
Also about your queries that this may add dependency between trip index and
cooling state. This is actually needed and this dependency is created when
the cooling device is binded with trip points(For cpufreq type cooling
device just the instance of cooling device is associated with trip points).
More over the existing PASSIVE cooling trip type does the same thing and
iterates across all the cooling state.
Thanks,
Amit Daniel
On 20 December 2011 18:07, Vincent Guittot vincent.guit...@linaro.orgwrote:
Hi Amit,
I'm not sure that using the trip index for setting the state of a
cooling device is a generic solution because you are adding a
dependency between the trip index and the cooling device state that
might be difficult to handle. This dependency implies that a cooling
device like cpufreq_cooling_device must be registered in the 1st trips
of a thermal_zone which is not possible when we want to register 2
cpufreq_cooling_devices in the same thermal_zone.
You should only rely on the current and last temperatures to detect if
a trip_temp has been crossed and you should increase or decrease the
current state of the cooling device accordingly.
something like below should work with cpufreq_cooling_device and will
not add any constraint on the trip index. The state of a cooling
device is increased/decreased once for each trip
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+ if (instance-trip != count)
+ continue;
+
+ cdev = instance-cdev;
+
+ if ((temp = trip_temp)
+(trip_temp
tz-last_temperature)) {
+ cdev-ops-get_max_state(cdev,
+ max_state);
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (++current_state = max_state)
+
cdev-ops-set_cur_state(cdev,
+
current_state);
+ }
+ else if ((temp trip_temp)
+(trip_temp =
tz-last_temperature)) {
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (current_state 0)
+
cdev-ops-set_cur_state(cdev,
+
--current_state);
+ }
+ break;
Regards,
Vincent
On 13 December 2011 16:13, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt |4 ++--
drivers/thermal/thermal_sys.c | 27 ++-
include/linux/thermal.h |1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for
ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c
b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, passive\n);
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, active\n);
+ case
Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cpu frequency. But
this has to be done again in cooling devices so to make the cooling
devices generic and to avoid the temperature comparison again this new
trip type passes the cooling device instance id.
Also about your queries that this may add dependency between trip
index and cooling state. This is actually needed and this dependency
is created when the cooling device is binded with trip points(For
cpufreq type cooling device just the instance of cooling device is
associated with trip points). More over the existing PASSIVE cooling
trip type does the same thing and iterates across all the cooling
state.
Thanks,
Amit Daniel
On 20 December 2011 18:07, Vincent Guittot vincent.guit...@linaro.org wrote:
Hi Amit,
I'm not sure that using the trip index for setting the state of a
cooling device is a generic solution because you are adding a
dependency between the trip index and the cooling device state that
might be difficult to handle. This dependency implies that a cooling
device like cpufreq_cooling_device must be registered in the 1st trips
of a thermal_zone which is not possible when we want to register 2
cpufreq_cooling_devices in the same thermal_zone.
You should only rely on the current and last temperatures to detect if
a trip_temp has been crossed and you should increase or decrease the
current state of the cooling device accordingly.
something like below should work with cpufreq_cooling_device and will
not add any constraint on the trip index. The state of a cooling
device is increased/decreased once for each trip
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+ if (instance-trip != count)
+ continue;
+
+ cdev = instance-cdev;
+
+ if ((temp = trip_temp)
+ (trip_temp
tz-last_temperature)) {
+ cdev-ops-get_max_state(cdev,
+ max_state);
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (++current_state = max_state)
+
cdev-ops-set_cur_state(cdev,
+
current_state);
+ }
+ else if ((temp trip_temp)
+ (trip_temp =
tz-last_temperature)) {
+ cdev-ops-get_cur_state(cdev,
+ current_state);
+ if (current_state 0)
+
cdev-ops-set_cur_state(cdev,
+
--current_state);
+ }
+ break;
Regards,
Vincent
On 13 December 2011 16:13, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt | 4 ++--
drivers/thermal/thermal_sys.c | 27 ++-
include/linux/thermal.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Nicolas,
Is it possible for you to add these 2 patches for this month release? I am
not able to give you the git link as there is seems some problem with the
linaro git server.
Also I attached the patches in case required.
Thanks,
Amit Daniel
On 13 December 2011 20:43, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
PATCH 1) [thermal: Add a new trip type to use cooling device instance
number]
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
cooling device instance number and may be helpful for cpufreq cooling
devices
to take the correct cooling action.
PATCH 2) [thermal: Add generic cpu cooling implementation]
This patch adds generic cpu cooling low level implementation through
frequency
clipping and cpu hotplug. 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.
Amit Daniel Kachhap (2):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpu cooling implementation
Documentation/thermal/cpu-cooling-api.txt | 52 +
Documentation/thermal/sysfs-api.txt |4 +-
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile |1 +
drivers/thermal/cpu_cooling.c | 302
+
drivers/thermal/thermal_sys.c | 27 +++-
include/linux/cpu_cooling.h | 45 +
include/linux/thermal.h |1 +
8 files changed, 440 insertions(+), 3 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
From 8719c5aca30fc986a7e89c600fa54d340342e9e2 Mon Sep 17 00:00:00 2001
From: Amit Daniel Kachhap amit.kach...@linaro.org
Date: Thu, 1 Dec 2011 18:51:39 +0530
Subject: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt |4 ++--
drivers/thermal/thermal_sys.c | 27 ++-
include/linux/thermal.h |1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct device_attribute *attr,
return sprintf(buf, passive\n);
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, active\n);
+ case THERMAL_TRIP_STATE_ACTIVE:
+ return sprintf(buf, state-active\n);
default:
return sprintf(buf, unknown\n);
}
@@ -1035,7 +1037,7 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
void thermal_zone_device_update(struct thermal_zone_device *tz)
{
int count, ret = 0;
- long temp, trip_temp;
+ long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
struct thermal_cooling_device_instance *instance;
struct thermal_cooling_device *cdev;
@@ -1086,6 +1088,29 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
cdev-ops-set_cur_state(cdev, 0);
}
break;
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+if (instance-trip != count)
+ continue;
+
+if (temp = last_trip_change)
+ continue;
+
+cdev = instance-cdev;
+cdev-ops-get_max_state(cdev, max_state);
+
+if ((temp = trip_temp)
+ ((count + 1) = max_state))
+ cdev-ops-set_cur_state(cdev,
+count + 1);
+else if ((temp trip_temp)
+ (count = max_state))
+
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Nicolas, Please pull my samsung thermal implementation work from git repository (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). Some of the patches are under review and some are in mainline in 3.2 rc* version. It is all based on the tip of your tree. The patches are added since commit id 971be11492b1e248798f7078592b1fa0dfbf3534 Thanks, Amit Daniel On 14 December 2011 20:11, Amit Kachhap amit.kach...@linaro.org wrote: Hi Nicolas, Is it possible for you to add these 2 patches for this month release? I am not able to give you the git link as there is seems some problem with the linaro git server. Also I attached the patches in case required. Thanks, Amit Daniel On 13 December 2011 20:43, Amit Daniel Kachhap amit.kach...@linaro.org wrote: PATCH 1) [thermal: Add a new trip type to use cooling device instance number] This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. PATCH 2) [thermal: Add generic cpu cooling implementation] This patch adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. 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. Amit Daniel Kachhap (2): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpu cooling implementation Documentation/thermal/cpu-cooling-api.txt | 52 + Documentation/thermal/sysfs-api.txt |4 +- drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 302 + drivers/thermal/thermal_sys.c | 27 +++- include/linux/cpu_cooling.h | 45 + include/linux/thermal.h |1 + 8 files changed, 440 insertions(+), 3 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro powertop doesn't work well on a single core ARM SoC
Hi Barry,
You fix for invalid cpu id looks fine. As for the P states this new
powertop combines with the cpuidle numbers. so if the system is highly
idle it means processor is idle and hence P states is shown as 0.
Thanks,
Amit Daniel
On 12 December 2011 15:55, Barry Song 21cn...@gmail.com wrote:
Hi Tony/Amit,
anybody has tried to use powertop from linaro on a single core ARM
SoC? What i am using is
git://android.git.linaro.org/platform/external/powertop.git.
I got two questions:
1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
number(-1), then i made the following change to make it work:
powertop: fix segment fault for single cpu env
Signed-off-by: Barry Song baohua.s...@csr.com
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 29fc72c..c56c746 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -302,6 +302,9 @@ void enumerate_cpus(void)
model = strtoull(c, NULL, 10);
}
}
+
+ if (number == -1)
+ number = 0;
if (strncasecmp(line, bogomips\t, 9) == 0) {
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);
2. after fixing problem1, powertop can run on PrimaII, but i always
get 0.0% for every p states as you can see from attached pic.
but if we check cpufreq stats in
/sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
based on ondemand.
# cat time_in_state
80 2064
60 181
40 341
20 60381
# cat trans_table
From : To
: 80 60 40 20
80: 0 13 13 14
60: 5 0 3 5
40: 5 0 0 11
20: 29 0 0 0
# cat total_trans
98
does anyone have experiences about it?
Thanks
barry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
On 11 November 2011 13:03, MyungJoo Ham myungjoo@gmail.com wrote: On Sat, Nov 5, 2011 at 2:03 AM, amit.kach...@linaro.org wrote: From: Amit Daniel Kachhap amit.kach...@linaro.org This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode. This patch ports the code to the latest interfaces to save/restore CPU state inclusive of CPU PM notifiers, l2 resume and cpu_suspend/resume. Signed-off-by: Jaecheol Lee jc@samsung.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- [] +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \ + S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24)) +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \ + S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20)) [] + + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)), + REG_DIRECTGO_ADDR); + __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG); + return 0; Hello, Why are you using INFORM6 and 7 registers in order to save resume address and power-mode flags? INFORM0 and 1 have been used in pm.c for the exactly same purpose. Please use the same registers in cpuidle.c as well. The same part in bootloader (IPL) can handle whether it's suspend-to-RAM or AFTR and the both modes are mutually exclusive and you only need one value for resume PC. Therefore, you can keep the value at the same location, which is the method we have been using. Hi, I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c. But this doesnt work. Looks like my irom fused code checks for the wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My cpu version is S5PV310AH--0AH1113(Origen board). I suggest adding support for both type of wakeups(directly from irom and through bootloader). Thanks, Amit D Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7 registers are used by in-chip code (iROM or iRAM). Cheers! MyungJoo -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, DMC Business, Samsung Electronics ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freeze date for the Linaro 11.11 kernel release
Hi Nicolas, Please pull the samsung cpuidle code from, (git://git.linaro.org/people/amitdanielk/linux.git branch: samsung_cpuidle_l2_retention). The above branch is rebased on top of your tree and contains some necessary patches already in mainline. All these patches are submitted and under review(http://www.spinics.net/lists/arm-kernel/msg146579.html). Thanks, Amit Daniel On 9 November 2011 12:55, Amit Kucheria amit.kuche...@linaro.org wrote: On Wed, Nov 9, 2011 at 12:59 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote: We are considering freezing the 11.11 kernel this next Monday (Nov 14) in order to release it on Wednesday (Nov 16), so it is out there before the US Thanksgiving holiday. If anyone would like to see their patches included in the Linaro kernel for this month, please consider submitting them ASAP. As discussed in Orlando, we are also considering a shift towards using the latest tagged release from Torvalds' mainline tree. This process is not fully in place yet, so the regular Linaro release based on the latest stable upstream release will still occur for this month. Vincent, Amit: Could you please ensure that sched_mc optimisation and samsung cpuidle patches are integrated and enabled into Nico's tree? Mike: Any chance of getting a preview of common clk on a separate branch and asking the platform team to create a build for it? Rob, Daniel: Same thing for cpuidle core + imx changes as Mike. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 4/4] ARM: exynos4: remove useless code to save/restore L2 and GIC state
On 4 November 2011 23:03, Sylwester Nawrocki s.nawro...@samsung.com wrote:
On 11/04/2011 06:03 PM, amit.kach...@linaro.org wrote:
From: Amit Daniel Kachhap amit.kach...@linaro.org
Following the merge of CPU PM notifiers and L2 resume code, this patch
removes useless code to save and restore L2 and GIC registers.
This is now automatically covered by suspend calls which integrated
CPU PM notifiers and new sleep code that allows to resume L2 before MMU
is turned on.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos4/pm.c | 86
1 files changed, 0 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index 62e4f43..7499f14 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -63,77 +63,6 @@ static struct sleep_save exynos4_vpll_save[] = {
};
static struct sleep_save exynos4_core_save[] = {
- /* GIC side */
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x008),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x00C),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x014),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x018),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x000),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x004),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x100),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x104),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x108),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x300),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x304),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x308),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x400),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x404),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x408),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x40C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x410),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x414),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x418),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x41C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x420),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x424),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x428),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x42C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x430),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x434),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x438),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x43C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x440),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x444),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x448),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x44C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x450),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x454),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x458),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x45C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x800),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x804),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x808),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x80C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x810),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x814),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x818),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x81C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x820),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x824),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x828),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x82C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x830),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x834),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x838),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x83C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x840),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x844),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x848),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x84C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x850),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x854),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x858),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x85C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC00),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC04),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC08),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC0C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC10),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC14),
This list is not complete anyway, some peripheral devices interrupts do not
work after resume from system suspend to RAM.
Is there any code already handling GIC state during system suspend/resume
cycles?
Or you refer to some upcoming patches ?
In my next patch series I have left the GIC save/restore from platform code.
--
Thanks,
Sylwester
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/4] ARM: Exynos4: Add thermal sensor driver for samsung exynos4 platform.
On 27 October 2011 04:08, Kyungmin Park kmp...@infradead.org wrote:
Hi,
exynos4 tmu is already merged 3.2-rc
you can find it at below message and latest git kernel
http://www.spinics.net/lists/lm-sensors/msg33872.html
Thank you,
Kyungmin Park
ok I will rebase my work on top of sensor
Thanks for pointing this out.
On Wed, Oct 26, 2011 at 8:36 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
This patch adds support for thermal sensor driver. It supports 3 trigger
level. The first 2 level are warn and monitor temperature level. The
third critical trigger level resets the system. The threshold
change information is sent to the thermal interface layer.
Signed-off-by: SangWook Ju sw...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos4/include/mach/exynos4-tmu.h | 75
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/thermal_exynos4/sensor/Kconfig | 14 +
drivers/staging/thermal_exynos4/sensor/Makefile | 4 +
.../thermal_exynos4/sensor/exynos4210_tmu.c | 465
6 files changed, 561 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
create mode 100644 drivers/staging/thermal_exynos4/sensor/Kconfig
create mode 100644 drivers/staging/thermal_exynos4/sensor/Makefile
create mode 100644 drivers/staging/thermal_exynos4/sensor/exynos4210_tmu.c
diff --git a/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
new file mode 100644
index 000..dc7bf37
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
@@ -0,0 +1,75 @@
+/**
+ * exynos4-tmu.h - definitions of exynos4 specific thermal interface
+ *
+ * Copyright (C) 2011 Samsung Electronics Co. ltd.
+
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef _EXYNOS4_TMU_H
+#define _EXYNOS4_TMU_H
+
+/**
+ * tmu_data - tmu driver private structure
+ * @t1: colling stop temperature.
+ * @dc_temp: Temperature base.
+ * @init_threshold: Initial threshold temperature.
+ * @mode: Compensation mode.
+ * @comp_threshold: compensated threshold temperature.
+ *
+ */
+struct tmu_data {
+ char te1;
+ char te2;
+ unsigned int init_threshold;
+ int mode;
+ int cooling;
+ unsigned int comp_threshold;
+ int tmu_flag;
+};
+
+/**
+ * tmu_platform_device - tmu platform specific structure
+ * @id: Device id.
+ * @tmu_base: Memory register base.
+ * @dev: TMU device.
+ * @data: TMU driver private data structure.
+ *
+ */
+struct tmu_platform_device {
+ int id;
+ struct platform_device *pdev;
+ void __iomem *tmu_base;
+ struct device *dev;
+ struct tmu_data data;
+ struct thermal_dev *therm_fw;
+};
+
+#ifdef CONFIG_PM
+struct exynos4_tmu_register {
+ unsigned int regval_thresh_temp;
+ unsigned int regval_trig_lev0;
+ unsigned int regval_trig_lev1;
+ unsigned int regval_trig_lev2;
+ unsigned int regval_trig_lev3;
+ unsigned int regval_tmu_con0;
+ unsigned int regval_int_en;
+};
+#endif
+
+extern void exynos4_tmu_set_platdata(struct tmu_data *pd);
+extern struct tmu_platform_device *exynos4_tmu_get_platdata(void);
+extern int exynos4_tmu_get_irqno(int num);
+#endif /* _EXYNOS4_TMU_H */
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 2582e18..4376fed 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -148,4 +148,6 @@ source drivers/staging/mei/Kconfig
source drivers/staging/nvec/Kconfig
+source drivers/staging/thermal_exynos4/Kconfig
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 50d112f..24a2943 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += ste_rmi4/
obj-$(CONFIG_DRM_PSB) += gma500/
obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_MFD_NVEC) += nvec/
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE)
Re: samsung cpuidle pull request.
Hi Nicolas, As suggested by you, I have cherry picked the necessary patches from rmk-next tree and applied it on top of latest linaro tree. Please pull them for next linaro release. The pull path is, git://git.linaro.org/people/amitdanielk/linux.git samsung_cpuidle_l2_retention. All the patches are tested and there details are, Amit Daniel Kachhap (3): ARM: EXYNOS4: Add support AFTR mode on EXYNOS4210 ARM: EXYNOS4: Added function to read chip id ARM: exynos4: add L2 early resume code Barry Song (3): ARM: 7089/1: L2X0: add explicit cpu_relax() for busy wait loop ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0 ARM: 7114/1: cache-l2x0: add resume entry for l2 in secure mode Lorenzo Pieralisi (2): ARM: exynos4: remove useless churn in sleep.S ARM: exynos4: remove useless code to save/restore L2 and GIC state Rob Herring (1): ARM: 7009/1: l2x0: Add OF based initialization Shawn Guo (1): ARM: 7100/1: smp_scu: remove __init annotation from scu_enable() Documentation/devicetree/bindings/arm/l2cc.txt | 42 + arch/arm/include/asm/hardware/cache-l2x0.h | 42 + arch/arm/include/asm/outercache.h |7 + arch/arm/kernel/asm-offsets.c | 12 ++ arch/arm/kernel/smp_scu.c |2 +- arch/arm/mach-exynos4/cpu.c| 47 +- arch/arm/mach-exynos4/cpuidle.c| 151 - arch/arm/mach-exynos4/include/mach/pmu.h |2 + arch/arm/mach-exynos4/platsmp.c|7 +- arch/arm/mach-exynos4/pm.c | 87 -- arch/arm/mach-exynos4/sleep.S | 29 +++- arch/arm/mm/cache-l2x0.c | 216 +++- arch/arm/plat-s5p/include/plat/exynos4.h |1 + Thanks, Amit Daniel On 21 October 2011 02:19, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 20 Oct 2011, Amit Kachhap wrote: Hi Nicolas, This is a request to pull L2 retention cpuidle implementation from git://git.linaro.org/people/amitdanielk/linux.git (branch- samsung_cpuidle_l2_retention) The top 5 patches on this refers to the work and this is heavily based on Russell's rmk-next tree. So if it is possible to take this patches for this month linaro release then please pull them. The Linaro kernel for this month was frozen today already. Still, I was ready to pull those patches if they were trivial. But they are based on RMK's for-next branch which is _not_ a stable branch, therefore I'm for sure not willing to pull all his for-next branch into the linaro repository, and even less so on the Linaro kernel freeze deadline. If you want those patches available in the Linaro kernel (maybe for next month's release) I'd ask you to cherry-pick the required patches and apply them to a branch which is based on the current state of the linux-linaro-3.1 repository, and please test the resulting branch. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.
On 19 August 2011 19:29, Kyungmin Park kmp...@infradead.org wrote:
On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
This adds a function to get the revision id.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
---
arch/arm/mach-exynos4/cpu.c | 10 ++
arch/arm/plat-s5p/include/plat/exynos4.h | 1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..8b106b8 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
early_initcall(exynos4_l2x0_cache_init);
#endif
+int exynos4_subrev(void)
+{
+ static int subrev = -1;
+
+ if (unlikely(subrev 0))
+ subrev = readl(S5P_VA_CHIPID) 0xf;
How about to add the clock control here?
1. Register chipid clk
2. Get the chipid clk
3. Read CHPIID,
4. Put tht chipid clk.
Nice suggestion. Will do it in the next patch version. Actually the
main focus of this
patch series was to have a proof of concept of the new cpuidle common code.
Thanks,
Amit Daniel
Then you can save some power.
Thank you,
Kyungmin Park
+
+ return subrev;
+}
+
int __init exynos4_init(void)
{
printk(KERN_INFO EXYNOS4: Initializing architecture\n);
diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h
b/arch/arm/plat-s5p/include/plat/exynos4.h
index 907caab..d62f7f7 100644
--- a/arch/arm/plat-s5p/include/plat/exynos4.h
+++ b/arch/arm/plat-s5p/include/plat/exynos4.h
@@ -15,6 +15,7 @@
extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void exynos4_register_clocks(void);
extern void exynos4_setup_clocks(void);
+extern int exynos4_subrev(void);
#ifdef CONFIG_CPU_EXYNOS4210
--
1.7.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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 06/17] ARM: kernel: save/restore generic infrastructure
On 7 July 2011 21:20, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
This patch provides the code infrastructure needed to maintain
a generic per-cpu architecture implementation of idle code.
sr_platform.c :
- code manages patchset initialization and memory management
sr_context.c:
- code initializes run-time context save/restore generic
support
sr_power.c:
- provides the generic infrastructure to enter exit low
power modes and communicate with Power Control Unit (PCU)
v7 support hinges on the basic infrastructure to provide per-cpu
arch implementation basically through standard function pointers
signatures.
Preprocessor defines include size of data needed to save/restore
L2 state. This define value should be moved to the respective
subsystem (PL310) once the patchset IF to that subsystem is settled.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/sr.h | 162
+
arch/arm/kernel/sr_context.c | 23 ++
arch/arm/kernel/sr_helpers.h | 56 ++
arch/arm/kernel/sr_platform.c | 48
arch/arm/kernel/sr_power.c | 26 +++
5 files changed, 315 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/sr.h
create mode 100644 arch/arm/kernel/sr_context.c
create mode 100644 arch/arm/kernel/sr_helpers.h
create mode 100644 arch/arm/kernel/sr_platform.c
create mode 100644 arch/arm/kernel/sr_power.c
diff --git a/arch/arm/kernel/sr.h b/arch/arm/kernel/sr.h
new file mode 100644
index 000..6b24e53
--- /dev/null
+++ b/arch/arm/kernel/sr.h
@@ -0,0 +1,162 @@
+#define SR_NR_CLUSTERS 1
+
+#define STACK_SIZE 512
+
+#define CPU_A5 0x4100c050
+#define CPU_A8 0x4100c080
+#define CPU_A9 0x410fc090
+#define L2_DATA_SIZE 16
+#define CONTEXT_SPACE_UNCACHED (2 * PAGE_SIZE)
+#define PA(f) ((typeof(f) *)virt_to_phys((void *)f))
+
+#ifndef __ASSEMBLY__
+
+#include linux/types.h
+#include linux/threads.h
+#include linux/cpumask.h
+#include asm/page.h
+
+/*
+ * Structures we hide from the OS API
+ */
+
+struct sr_cpu_context {
+ u32 flags;
+ u32 saved_items;
+ u32 *mmu_data;
+};
+
+struct sr_cluster_context {
+ u32 saved_items;
+ u32 *l2_data;
+};
+
+struct sr_main_table {
+ pgd_t *os_mmu_context[SR_NR_CLUSTERS][CONFIG_NR_CPUS];
+ cpumask_t cpu_idle_mask[SR_NR_CLUSTERS];
+ pgd_t *fw_mmu_context;
+ u32 num_clusters;
+ struct sr_cluster *cluster_table;
+};
+
+
+/*
+ * A cluster is a container for CPUs, typically either a single CPU or a
+ * coherent cluster.
+ * We assume the CPUs in the cluster can be switched off independently.
+ */
+struct sr_cluster {
+ u32 cpu_type; /* A9mpcore, A5mpcore, etc */
+ u32 num_cpus;
+ struct sr_cluster_context *context;
+ struct sr_cpu *cpu_table;
+ u32 power_state;
+ u32 cluster_down;
+ void __iomem *scu_address;
+ void *lock;
+};
+
+struct sr_cpu {
+ struct sr_cpu_context *context;
+ u32 power_state;
+};
+
+/*
+ * arch infrastructure
+ */
+struct sr_arch {
+ unsigned int cpu_val;
+ unsigned int cpu_mask;
+
+ int (*init)(void);
+
+ int (*save_context)(struct sr_cluster *, struct sr_cpu *,
+ unsigned);
+ int (*restore_context)(struct sr_cluster *, struct sr_cpu *);
+ int (*enter_cstate)(unsigned cpu_index,
+ struct sr_cpu *cpu,
+ struct sr_cluster *cluster);
+ int (*leave_cstate)(unsigned, struct sr_cpu *,
+ struct sr_cluster *);
+ void (*reset)(void);
+
+};
+
+extern struct sr_arch *arch;
+extern int lookup_arch(void);
+
+/*
+ * Global variables
+ */
+extern struct sr_main_table main_table;
+extern unsigned long idle_save_context;
+extern unsigned long idle_restore_context;
+extern unsigned long idle_mt;
+extern void *context_memory_uncached;
+
+/*
+ * Context save/restore
+ */
+typedef u32 (sr_save_context_t)
+ (struct sr_cluster *,
+ struct sr_cpu*, u32);
+typedef u32 (sr_restore_context_t)
+ (struct sr_cluster *,
+ struct sr_cpu*);
+
+extern sr_save_context_t sr_save_context;
+extern sr_restore_context_t sr_restore_context;
+
+
+extern struct sr_arch *get_arch(void);
+
+
+/*
+ * 1:1 mappings
+ */
+
+extern int linux_sr_setup_translation_tables(void);
+
+/*
+ * dumb memory allocator
+ */
+
+extern void *get_memory(unsigned int size);
+
+/*
+ * Entering/Leaving C-states function entries
+ */
+
+extern int sr_platform_enter_cstate(unsigned cpu_index, struct sr_cpu *cpu,
+ struct sr_cluster
Re: [RFC PATCH 17/17] ARM: kernel: save/restore build infrastructure
On 7 July 2011 21:20, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: This patch adds the required Kconfig and Makefile entries to enable and compile common idle code for ARM kernel. Common idle code depends on CPU_PM platform notifiers to trigger save/restore of kernel subsystems like PMU, VFP, GIC. Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/Kconfig | 11 +++ arch/arm/kernel/Makefile | 4 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 356f266..5b670bd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1992,6 +1992,17 @@ config VFP Say N if your target does not have VFP hardware. +config CONTEXT_SR + bool Save/Restore code support for CPU/Cluster Power Management + depends on CPU_V7 CPU_PM + help + Say Y to include Save/Restore code in the kernel. This provides + generic infrastructure to put the code in dormant/shutdown mode + and save/restore the required system state inclusive of L2 cache + logic. + + Say N if your target does not have Power Management hardware. + Currently this is placed inside the Floating point emulation menu. cpu power management menu may be a better option. Also I did not find where configs CPU_PM, ARCH_USES_CPU_PM are enabled. config VFPv3 bool depends on VFP diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile index 8b42d58..ac931f1 100644 --- a/arch/arm/kernel/Makefile +++ b/arch/arm/kernel/Makefile @@ -49,6 +49,10 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o obj-$(CONFIG_SWP_EMULATE) += swp_emulate.o CFLAGS_swp_emulate.o := -Wa,-march=armv7-a obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o +obj-$(CONFIG_CONTEXT_SR) += lb_lock.o sr_api.o sr_mapping.o \ + sr_entry.o sr_arch.o sr_context.o \ + sr_platform.o sr_power.o reset_v7.o \ + sr_v7_helpers.o obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 -- 1.7.4.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] powertop: Disable pci bus measurement for arm platforms
On 15 July 2011 22:56, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Thu, Jul 14, 2011 at 11:35 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch disables pci related measurement which is not needed for ARM platforms and also library libpci is not needed. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Android.mk | 7 ++- devices/runtime_pm.cpp | 3 ++- lib.cpp | 7 --- main.cpp | 6 ++ tuning/runtime.cpp | 2 ++ 5 files changed, 20 insertions(+), 5 deletions(-) diff --git a/Android.mk b/Android.mk index 146f57a..6948011 100644 --- a/Android.mk +++ b/Android.mk @@ -4,7 +4,6 @@ include $(CLEAR_VARS) LOCAL_MODULE_TAGS := debug LOCAL_SHARED_LIBRARIES := libstlport \ libnl \ - libpci \ LOCAL_MODULE := powertop @@ -14,6 +13,12 @@ LOCAL_CPPFLAGS += -DDISABLE_NCURSES -DDISABLE_I18N -DDISABLE_TRYCATCH LOCAL_C_INCLUDES += external/stlport/stlport/ external/stlport/stlport/stl external/stlport/stlport/using/h/ bionic external/libnl/include/ +ifneq ($(TARGET_ARCH),arm) +LOCAL_SHARED_LIBRARIES += libpci +else #TARGET_ARCH != arm +LOCAL_CPPFLAGS += -DDISABLE_PCI +endif #TARGET_ARCH == arm should probably not use #ifdef ARM but something like #ifdef HAVE_LIBPCI instead.. there will be other architectures that don't have libpci as well. Thanks for your comments. i will use this macro in the next patches. LOCAL_SRC_FILES += \ parameters/parameters.cpp \ parameters/persistent.cpp \ diff --git a/devices/runtime_pm.cpp b/devices/runtime_pm.cpp index 368d995..5a55426 100644 --- a/devices/runtime_pm.cpp +++ b/devices/runtime_pm.cpp @@ -200,7 +200,7 @@ static void do_bus(const char *bus) continue; dev = new class runtime_pmdevice(entry-d_name, filename); - +#ifndef DISABLE_PCI I'd prefer a nice HAVE_LIBPCI here instead as well for the rest of these... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/3] powertop: ncurses: Enable ncurses for android and miscellaneous changes
On 15 July 2011 23:05, Kok, Auke-jan H auke-jan.h@intel.com wrote:
On Thu, Jul 14, 2011 at 11:35 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
This patch enables ncurses for android. NCURSES_NOMACRO flag is enabled
as there is some conflict with stl libraries.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Android.mk | 23 +++
display.cpp | 5 -
display.h | 3 ++-
lib.cpp | 6 --
main.cpp | 5 +
process/do_process.cpp | 4
6 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/Android.mk b/Android.mk
index 6948011..e6e73b1 100644
--- a/Android.mk
+++ b/Android.mk
@@ -1,17 +1,32 @@
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
-LOCAL_MODULE_TAGS := debug
+LOCAL_MODULE_TAGS := optional
LOCAL_SHARED_LIBRARIES := libstlport \
- libnl \
+ libnl
+
+LOCAL_STATIC_LIBRARIES := libncurses
LOCAL_MODULE := powertop
#LOCAL_CFLAGS += -Wall -O2 -g -fno-omit-frame-pointer -fstack-protector
-Wshadow -Wformat -D_FORTIFY_SOURCE=2
#LOCAL_CPPFLAGS += -Wall -O2 -g -fno-omit-frame-pointer
-LOCAL_CPPFLAGS += -DDISABLE_NCURSES -DDISABLE_I18N -DDISABLE_TRYCATCH
+LOCAL_CPPFLAGS += \
+ -DDISABLE_I18N \
+ -DDISABLE_TRYCATCH \
+ -DNCURSES_NOMACROS \
+ -DDISABLE_WSTRING \
+ -DDEFAULT_TERM=\xterm\ \
-LOCAL_C_INCLUDES += external/stlport/stlport/ external/stlport/stlport/stl
external/stlport/stlport/using/h/ bionic external/libnl/include/
+LOCAL_C_INCLUDES += external/stlport/stlport/ \
+ external/stlport/stlport/stl \
+ external/stlport/stlport/using/h/ \
+ bionic \
+ external/libnl/include/ \
+ external/ncurses \
+ external/ncurses/lib \
+ external/ncurses/include \
+ external/ncurses/include/ncurses
ifneq ($(TARGET_ARCH),arm)
LOCAL_SHARED_LIBRARIES += libpci
diff --git a/display.cpp b/display.cpp
index f486050..283743c 100644
--- a/display.cpp
+++ b/display.cpp
@@ -84,8 +84,11 @@ void reset_display(void)
keypad(stdscr, FALSE);
echo();
nocbreak();
-
+#ifndef NCURSES_NOMACROS
resetterm();
+#else
+ reset_shell_mode();
+#endif
}
diff --git a/display.h b/display.h
index 3b24914..023f68d 100644
--- a/display.h
+++ b/display.h
@@ -49,7 +49,8 @@ public:
int cursor_pos;
int cursor_max;
WINDOW *win;
-
+
+ virtual ~tab_window() {};
virtual void cursor_down(void) { if (cursor_pos cursor_max )
cursor_pos++; repaint(); } ;
virtual void cursor_up(void) { if (cursor_pos 0) cursor_pos--;
repaint(); };
diff --git a/lib.cpp b/lib.cpp
index d058e4f..86fcf96 100644
--- a/lib.cpp
+++ b/lib.cpp
@@ -238,10 +238,12 @@ void format_watts(double W, char *buffer, unsigned int
len)
if (W 0.0001)
sprintf(buffer, _( 0 mW));
-#ifndef DISABLE_NCURSES
+#ifndef DISABLE_NCURSES
+#ifndef DISABLE_WSTRING
while (mbstowcs(NULL,buffer,0) len)
strcat(buffer, );
-#endif
+#endif //DISABLE_WSTRING
+#endif //DISABLE_NCURSES
}
#ifndef DISABLE_PCI
diff --git a/main.cpp b/main.cpp
index 3ee0a7e..fc4b0cf 100644
--- a/main.cpp
+++ b/main.cpp
@@ -280,6 +280,11 @@ int main(int argc, char **argv)
bindtextdomain (powertop, /usr/share/locale);
textdomain (powertop);
#endif
+
+#ifdef DEFAULT_TERM
+ if (!getenv(TERM))
+ setenv(TERM, DEFAULT_TERM, 1);
+#endif
uid = getuid();
if (uid != 0) {
diff --git a/process/do_process.cpp b/process/do_process.cpp
index 5c382f1..7e39321 100644
--- a/process/do_process.cpp
+++ b/process/do_process.cpp
@@ -720,7 +720,9 @@ void process_update_display(void)
if (!show_power)
strcpy(power, );
sprintf(name, %s, all_power[i]-type());
+#ifndef DISABLE_WSTRING
while (mbstowcs(NULL,name,0) 14) strcat(name, );
+#endif
if (all_power[i]-events() == 0 all_power[i]-usage() == 0
all_power[i]-Witts() == 0)
@@ -733,7 +735,9 @@ void process_update_display(void)
else
sprintf(usage, %5i%s,
(int)all_power[i]-usage(), all_power[i]-usage_units());
}
+#ifndef DISABLE_WSTRING
while (mbstowcs(NULL,usage,0) 14) strcat(usage, );
+#endif
sprintf(events, %5.1f, all_power[i]-events());
if (!all_power[i]-show_events())
events[0] = 0;
most of the
Re: [PATCH powertop2.0] Modification to fix the removal of lock_depth field
On 23 June 2011 10:41, Arjan van de Ven ar...@linux.intel.com wrote: On 6/22/2011 10:12 PM, Amit Daniel Kachhap wrote: lock_depth field is removed from the power frequency events in the new linux kernel(2.6.38 onwards). So this creates issue to retrieve the lower members of the trace data. To fix this problem 2 separate structures are created and their use depends upon the format of the power_frequency events. These changes have been tested to work fine with both old and new kernels as well as on x86 and ARM platform. eh no while it was temporarily removed in an -rc, it was added back (as padding) after it was found to break powertop (and abi). or am I missing something??? Ohh the padding field fixes this issue. Then this patch may not be needed. Thanks Arjan for quick review. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Add Arm cpu topology definition
I have some doubts about the bit fields of the MPIDR register.
Comments added below.
On 16 June 2011 14:19, Vincent Guittot vincent.guit...@linaro.org wrote:
The affinity between Arm processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency. The cpu topology
of an Arm platform can be set thanks to this register and this topology
is then used by sched_mc and sched_smt.
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
arch/arm/Kconfig | 26
arch/arm/include/asm/topology.h | 33 ++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/smp.c | 6 ++
arch/arm/kernel/topology.c | 133
+++
5 files changed, 199 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/topology.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..bacf9af 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -219,6 +219,24 @@ source kernel/Kconfig.freezer
menu System Type
+config SCHED_MC
+ bool Multi-core scheduler support
+ depends on SMP ARM_CPU_TOPOLOGY
+ default n
+ help
+ Multi-core scheduler support improves the CPU scheduler's decision
+ making when dealing with multi-core CPU chips at a cost of slightly
+ increased overhead in some places. If unsure say N here.
+
+config SCHED_SMT
+ bool SMT scheduler support
+ depends on SMP ARM_CPU_TOPOLOGY
+ default n
+ help
+ Improves the CPU scheduler's decision making when dealing with
+ MultiThreading at a cost of slightly increased overhead in some
+ places. If unsure say N here.
+
config MMU
bool MMU-based Paged Memory Management Support
default y
@@ -1062,6 +1080,14 @@ if !MMU
source arch/arm/Kconfig-nommu
endif
+config ARM_CPU_TOPOLOGY
+ bool Support cpu topology definition
+ depends on SMP CPU_V7
+ help
+ Support Arm cpu topology definition. The MPIDR register defines
+ affinity between processors which is used to set the cpu
+ topology of an Arm System.
+
config ARM_ERRATA_411920
bool ARM errata: Invalidation of the Instruction Cache operation can
fail
depends on CPU_V6 || CPU_V6K
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index accbd7c..cb90d0a 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -1,6 +1,39 @@
#ifndef _ASM_ARM_TOPOLOGY_H
#define _ASM_ARM_TOPOLOGY_H
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+
+#include linux/cpumask.h
+
+struct cputopo_arm {
+ int thread_id;
+ int core_id;
+ int socket_id;
+ cpumask_t thread_sibling;
+ cpumask_t core_sibling;
+};
+
+extern struct cputopo_arm cpu_topology[NR_CPUS];
+
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id)
+#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
+#define topology_core_cpumask(cpu) ((cpu_topology[cpu].core_sibling))
+#define topology_thread_cpumask(cpu) ((cpu_topology[cpu].thread_sibling))
+
+#define mc_capable() (cpu_topology[0].socket_id != -1)
+#define smt_capable() (cpu_topology[0].thread_id != -1)
+
+void init_cpu_topology(void);
+void store_cpu_topology(unsigned int cpuid);
+const struct cpumask *cpu_coregroup_mask(unsigned int cpu);
+
+#else
+
+#define init_cpu_topology() {};
+#define store_cpu_topology(cpuid) {};
+
+#endif
+
#include asm-generic/topology.h
#endif /* _ASM_ARM_TOPOLOGY_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index a5b31af..816a481 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_IWMMXT) += iwmmxt.o
obj-$(CONFIG_CPU_HAS_PMU) += pmu.o
obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
+obj-$(CONFIG_ARM_CPU_TOPOLOGY) += topology.o
ifneq ($(CONFIG_ARCH_EBSA110),y)
obj-y += io.o
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 344e52b..3e8dc3b 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -31,6 +31,7 @@
#include asm/cacheflush.h
#include asm/cpu.h
#include asm/cputype.h
+#include asm/topology.h
#include asm/mmu_context.h
#include asm/pgtable.h
#include asm/pgalloc.h
@@ -268,6 +269,9 @@ static void __cpuinit smp_store_cpu_info(unsigned int
cpuid)
struct cpuinfo_arm *cpu_info = per_cpu(cpu_data, cpuid);
cpu_info-loops_per_jiffy = loops_per_jiffy;
+
+ store_cpu_topology(cpuid);
+
}
/*
@@ -354,6 +358,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
{
unsigned int ncores = num_possible_cpus();
+ init_cpu_topology();
+
[PATCH 2/2] Added an arm compiler flag
From: Amit Daniel Kachhap amit.kach...@linaro.org
Modified to extract correct elements of power_entry structure.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
cpu/cpu.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 451c120..f9995be 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -747,7 +747,7 @@ void w_display_cpu_pstates(void)
struct power_entry {
-#ifdef __x86_64__
+#if defined(__x86_64__) || defined(__arm__)
int dummy;
#endif
int64_t type;
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] Modified Powertop to support ARM processor
From: Amit Daniel Kachhap amit.kach...@linaro.org
Added a compulsory field bogomips for each processor in case other
fields like model is missing. Error handling code added in case
of package id remains uninitialised.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
cpu/cpu.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 39f00e7..451c120 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -171,6 +171,8 @@ static void handle_one_cpu(unsigned int number, char
*vendor, int family, int mo
file.close();
}
+ if (package_number == (unsigned int)-1)
+ package_number = 0;
if (system_level.children.size() = package_number)
system_level.children.resize(package_number + 1, NULL);
@@ -263,6 +265,10 @@ void enumerate_cpus(void)
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);
}
+ if (strncasecmp(line, bogomips\t,9) == 0) {
+ handle_one_cpu(number, vendor, family, model);
+ set_max_cpu(number);
+ }
}
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] Modified Powertop2.0 to support ARM processor
The following set of patches modify the powertop version 2.0 to work for ARM platform. The C states and P states was measured after doing these changes in powertop. Amit Daniel Kachhap (2): Modified Powertop to support ARM processor Added an arm compiler flag cpu/cpu.cpp |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) [PATCH 1/2] Modified Powertop to support ARM processor [PATCH 2/2] Added an arm compiler flag ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung: CPUIDLE Support
Hi John, I forgot to mention that CONFIG_PM has dependency on CONFIG_SUSPEND. I tested in the latest Linaro kernel. Please enable the following macros, CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_PM_OPS=y CONFIG_ARCH_SUSPEND_POSSIBLE=y Regards, Amit Daniel On 12 April 2011 10:54, John Rigby john.ri...@linaro.org wrote: On Tue, Apr 12, 2011 at 2:39 AM, Amit Kachhap amit.kach...@linaro.org wrote: Hi John, Following macros can be enabled, CONFIG_CPU_IDLE, CONFIG_PM, CONFIG_PM_DEBUG Currently fails to compile with CONFIG_PM on. Thanks, Amit Daniel On 11 April 2011 10:52, John Rigby john.ri...@linaro.org wrote: Amitk, So can I turn on all the CONFIG_PM* stuff for samsung now? On Mon, Apr 11, 2011 at 8:46 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Mon, 11 Apr 2011, Amit Kachhap wrote: Hi Nicolas, I could not find this changes in the latest 2.6.38 Linaro kernel. Please merge the patch from the below mentioned samsung maintainers next link as this is required for the PM Linaro release. It is merged now. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V1] ARM: Samsung: Basic CPUIDLE Support
Hi Nicolas,
Please take this cpuidle commit from the samsung tree needed for Linaro new
rebuilt tree.
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=commit;h=df7bf189d23ecd1c211c273de462b93d9e3e1fef
Thanks,
Amit Daniel
On 18 March 2011 08:51, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This patch supports cpuidle framework for EXYNOS4210. Currently,
Only one idle state is possible to use, but more idle states can
be added following by this patch.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
FIX: Fixed the merging issue reported by Nicolas Pitre
nicolas.pi...@linaro.org
Sending the rebased patch for linaro 2.6.38 kernel. This patch adds basic
cpuidle
infrastructure and fixes the launchpad bug(bug id: 723543). This patch is
under review in samsung mailing list.
http://www.spinics.net/lists/linux-samsung-soc/msg04268.html
arch/arm/mach-exynos4/Makefile |1 +
arch/arm/mach-exynos4/cpuidle.c | 87
+++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos4/cpuidle.c
diff --git a/arch/arm/mach-exynos4/Makefile
b/arch/arm/mach-exynos4/Makefile
index b8f0e7d..f8a3a74 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o
irq-combiner.o
obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o gpiolib.o irq-eint.o dma.o
obj-$(CONFIG_PM) += pm.o sleep.o
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
diff --git a/arch/arm/mach-exynos4/cpuidle.c
b/arch/arm/mach-exynos4/cpuidle.c
new file mode 100644
index 000..a543a18
--- /dev/null
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -0,0 +1,87 @@
+/* linux/arch/arm/mach-exynos4/cpuidle.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.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 linux/kernel.h
+#include linux/init.h
+#include linux/cpuidle.h
+#include linux/io.h
+
+#include asm/proc-fns.h
+
+static int exynos4_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
+static struct cpuidle_state exynos4_cpuidle_set[] = {
+ [0] = {
+ .enter = exynos4_enter_idle,
+ .exit_latency = 1,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = IDLE,
+ .desc = ARM clock gating(WFI),
+ },
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
+
+static struct cpuidle_driver exynos4_idle_driver = {
+ .name = exynos4_idle,
+ .owner = THIS_MODULE,
+};
+
+static int exynos4_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ cpu_do_idle();
+
+ do_gettimeofday(after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+
+ return idle_time;
+}
+
+static int __init exynos4_init_cpuidle(void)
+{
+ int i, max_cpuidle_state, cpu_id;
+ struct cpuidle_device *device;
+
+ cpuidle_register_driver(exynos4_idle_driver);
+
+ for_each_cpu(cpu_id, cpu_online_mask) {
+ device = per_cpu(exynos4_cpuidle_device, cpu_id);
+ device-cpu = cpu_id;
+
+ device-state_count = (sizeof(exynos4_cpuidle_set) /
+ sizeof(struct
cpuidle_state));
+
+ max_cpuidle_state = device-state_count;
+
+ for (i = 0; i max_cpuidle_state; i++) {
+ memcpy(device-states[i], exynos4_cpuidle_set[i],
+ sizeof(struct cpuidle_state));
+ }
+
+ if (cpuidle_register_device(device)) {
+ printk(KERN_ERR CPUidle register device
failed\n,);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
+device_initcall(exynos4_init_cpuidle);
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: Samsung: Basic CPUIDLE Support
Hi nicolas,
Can you merge this patch for adding basic cpuidle support? This may be
needed
for the current linaro release cycle.
Regards,
Amit Daniel
On 10 March 2011 10:41, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This patch supports cpuidle framework for samsung S5PV310. Currently,
Only one idle state is possible to use, but more idle states can
be added followed by this patch.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Rebasing the patch for linaro 2.6.38 kernel. This patch adds basic cpuidle
infrastructure and fixes the launchpad bug(bug id: 723543). This patch is
under review in samsung mailing list.
http://www.spinics.net/lists/linux-samsung-soc/msg04268.html
arch/arm/mach-s5pv310/Makefile |1 +
arch/arm/mach-s5pv310/cpuidle.c | 87
+++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/cpuidle.c
diff --git a/arch/arm/mach-s5pv310/Makefile
b/arch/arm/mach-s5pv310/Makefile
index 036fb38..c5db0fa 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -15,6 +15,7 @@ obj- :=
obj-$(CONFIG_CPU_S5PV310) += cpu.o init.o clock.o irq-combiner.o
obj-$(CONFIG_CPU_S5PV310) += setup-i2c0.o time.o gpiolib.o irq-eint.o
dma.o
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
diff --git a/arch/arm/mach-s5pv310/cpuidle.c
b/arch/arm/mach-s5pv310/cpuidle.c
new file mode 100644
index 000..f35b537
--- /dev/null
+++ b/arch/arm/mach-s5pv310/cpuidle.c
@@ -0,0 +1,87 @@
+/* linux/arch/arm/mach-s5pv310/cpuidle.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.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 linux/kernel.h
+#include linux/init.h
+#include linux/cpuidle.h
+#include linux/io.h
+
+#include asm/proc-fns.h
+
+static int s5pv310_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
+static struct cpuidle_state s5pv310_cpuidle_set[] = {
+ [0] = {
+ .enter = s5pv310_enter_idle,
+ .exit_latency = 1,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = IDLE,
+ .desc = ARM clock gating(WFI),
+ },
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, s5pv310_cpuidle_device);
+
+static struct cpuidle_driver s5pv310_idle_driver = {
+ .name = s5pv310_idle,
+ .owner = THIS_MODULE,
+};
+
+static int s5pv310_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ cpu_do_idle();
+
+ do_gettimeofday(after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+
+ return idle_time;
+}
+
+static int __init s5pv310_init_cpuidle(void)
+{
+ int i, max_cpuidle_state, cpu_id;
+ struct cpuidle_device *device;
+
+ cpuidle_register_driver(s5pv310_idle_driver);
+
+ for_each_cpu(cpu_id, cpu_online_mask) {
+ device = per_cpu(s5pv310_cpuidle_device, cpu_id);
+ device-cpu = cpu_id;
+
+ device-state_count = (sizeof(s5pv310_cpuidle_set) /
+ sizeof(struct
cpuidle_state));
+
+ max_cpuidle_state = device-state_count;
+
+ for (i = 0; i max_cpuidle_state; i++) {
+ memcpy(device-states[i], s5pv310_cpuidle_set[i],
+ sizeof(struct cpuidle_state));
+ }
+
+ if (cpuidle_register_device(device)) {
+ printk(KERN_ERR CPUidle register device
failed\n,);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
+device_initcall(s5pv310_init_cpuidle);
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] CPUFREQ : calculate delay after dbs_check_cpu
Hi Vincent,
I checked this patch and I can see some performance improvement in my
arm platform also. So in your patch there are 2 changes. First one is
for calculating delay after rate_mult is set, this can be tested with
cpufreq-bench tool. For the second part which requires enabling power
save bias , the cpufreq-bench does not do that. So I tested with one
time setting of powersave_bias parameter and here also there is some
increase in performance. But ideally powersave mode should have more
power saving and some compromise in performance.
//Amit Daniel
On 15 February 2011 04:41, Vincent Guittot vincent.guit...@linaro.org wrote:
Hi,
The ondemand delay value is calculated before calling dbs_check_cpu
which can lead to a delay value of sampling_rate*sampling_down_factor
but a frequency set to the lowest value. The main result is a slow
responsiveness during this period. This patch moves the calculation of
delay after the call of dbs_check_cpu. I have seen this problem when
testing cpufreq-bench on my Arm platform.
Vincent
On 7 February 2011 17:14, Vincent Guittot vincent.guit...@linaro.org wrote:
calculate ondemand delay after dbs_check_cpu call because it can
modify rate_mult value
use freq_lo_jiffies value for the sub sample period of powersave_bias mode
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
drivers/cpufreq/cpufreq_ondemand.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 58aa85e..44c2dba 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -641,13 +641,7 @@ static void do_dbs_timer(struct work_struct *work)
container_of(work, struct cpu_dbs_info_s, work.work);
unsigned int cpu = dbs_info-cpu;
int sample_type = dbs_info-sample_type;
-
- /* We want all CPUs to do sampling nearly on same jiffy */
- int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
- * dbs_info-rate_mult);
-
- if (num_online_cpus() 1)
- delay -= jiffies % delay;
+ int delay;
mutex_lock(dbs_info-timer_mutex);
@@ -660,10 +654,22 @@ static void do_dbs_timer(struct work_struct *work)
/* Setup timer for SUB_SAMPLE */
dbs_info-sample_type = DBS_SUB_SAMPLE;
delay = dbs_info-freq_hi_jiffies;
+ } else {
+ /* We want all CPUs to do sampling nearly on
+ * same jiffy
+ */
+ delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
+ * dbs_info-rate_mult);
+
+ if (num_online_cpus() 1)
+ delay -= jiffies % delay;
+
}
+
} else {
__cpufreq_driver_target(dbs_info-cur_policy,
dbs_info-freq_lo, CPUFREQ_RELATION_H);
+ delay = dbs_info-freq_lo_jiffies;
}
schedule_delayed_work_on(cpu, dbs_info-work, delay);
mutex_unlock(dbs_info-timer_mutex);
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
