[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Despite this patch set is working and applicable on top of 3.14-rc5, 
please regard it solely as a pure RFC.

This patch provides support for LAB governor build on top of ondemand.
Previous version of LAB can be found here:
http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq

LAB short reminder:

LAB uses information about how many cores are in "idle" state (the core 
idleness is represented as the value between 0 and 100) and the overall 
load of the system (from 0 to 100) to decide about frequency to be set.
It is extremely useful with SoCs like Exynos4412, which can set only one
frequency for all cores.

Important design decisions:

- Reuse well established ondemand governor's internal code. To do this
  I had to expose some previously static internal ondemand code. 
  This allowed smaller LAB code when compared to previous version.
	
- LAB works on top of ondemand, which means that one via device tree
  attributes can specify if and when e.g. BOOST shall be enabled or if 
  any particular frequency shall be imposed. For situation NOT important 
  from the power consumption reduction viewpoint the ondemand is used to 
  set proper frequency.

- It is only possible to either compile in or not the LAB into the kernel. 
  There is no "M" option for Kconfig. It is done on purpose, since ondemand 
  itself can be also compiled as a module and then it would be possible to
  remove ondemand when LAB is working on top of it.

- The LAB operation is specified (and thereof extendable) via device tree
  lab-ctrl-freq attribute defined at /cpus/cpu0.


Problems:
- How the governor will work for big.LITTLE systems (especially Global Task
  Scheduling).
- Will there be agreement to expose internal ondemand code to be reused for
  more specialized governors.

Test HW:
	Exynos4412 - Trats2 board.
Above patches were posted on top of Linux 3.14-rc5
(SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)

Lukasz Majewski (5):
  cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
  cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support
    LAB
  cpufreq:LAB:lab Add LAB governor code
  cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
  cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

 arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
 drivers/cpufreq/Kconfig                 |   28 ++
 drivers/cpufreq/Makefile                |    1 +
 drivers/cpufreq/cpufreq_governor.c      |    7 +
 drivers/cpufreq/cpufreq_governor.h      |   12 +
 drivers/cpufreq/cpufreq_lab.c           |  457 +++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_ondemand.c      |   24 +-
 7 files changed, 550 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

-- 
1.7.10.4

[RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods

[Lukasz Majewski]

Ondemand code needed to be slightly adjusted to allow its reusage.
Mostly one needed to remove static qualifiers and provide some hacks to
allow its working with LAB.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.h |   10 ++++++++++
 drivers/cpufreq/cpufreq_ondemand.c |   24 ++++++++++++++++--------
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index bfb9ae1..34b1cf2 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -270,4 +270,14 @@ void od_register_powersave_bias_handler(unsigned int (*f)
 		(struct cpufreq_policy *, unsigned int, unsigned int),
 		unsigned int powersave_bias);
 void od_unregister_powersave_bias_handler(void);
+
+/* COMMON CODE FOR DEMAND BASED SWITCHING */
+void od_dbs_timer(struct work_struct *work);
+int od_init(struct dbs_data *dbs_data);
+void od_exit(struct dbs_data *dbs_data);
+void od_check_cpu(int cpu, unsigned int load_freq);
+void update_sampling_rate(struct dbs_data *dbs_data,
+			  unsigned int new_rate);
+
+extern struct od_ops od_ops;
 #endif /* _CPUFREQ_GOVERNOR_H */
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 18d4091..a27326d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -27,9 +27,9 @@
 #define MIN_FREQUENCY_UP_THRESHOLD		(11)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)
 
-static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
 
-static struct od_ops od_ops;
+struct od_ops od_ops;
 
 #ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
 static struct cpufreq_governor cpufreq_gov_ondemand;
@@ -152,7 +152,7 @@ static void dbs_freq_increase(struct cpufreq_policy *policy, unsigned int freq)
  * (default), then we try to increase frequency. Else, we adjust the frequency
  * proportional to load.
  */
-static void od_check_cpu(int cpu, unsigned int load)
+void od_check_cpu(int cpu, unsigned int load)
 {
 	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
@@ -188,7 +188,7 @@ static void od_check_cpu(int cpu, unsigned int load)
 	}
 }
 
-static void od_dbs_timer(struct work_struct *work)
+void od_dbs_timer(struct work_struct *work)
 {
 	struct od_cpu_dbs_info_s *dbs_info =
 		container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
@@ -233,6 +233,9 @@ max_delay:
 /************************** sysfs interface ************************/
 static struct common_dbs_data od_dbs_cdata;
 
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+extern struct cpufreq_governor cpufreq_gov_lab;
+#endif
 /**
  * update_sampling_rate - update sampling rate effective immediately if needed.
  * @new_rate: new sampling rate
@@ -246,7 +249,7 @@ static struct common_dbs_data od_dbs_cdata;
  * reducing the sampling rate, we need to make the new value effective
  * immediately.
  */
-static void update_sampling_rate(struct dbs_data *dbs_data,
+void update_sampling_rate(struct dbs_data *dbs_data,
 		unsigned int new_rate)
 {
 	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
@@ -263,7 +266,12 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 		policy = cpufreq_cpu_get(cpu);
 		if (!policy)
 			continue;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+		if (policy->governor != &cpufreq_gov_ondemand &&
+		    policy->governor != &cpufreq_gov_lab) {
+#else
 		if (policy->governor != &cpufreq_gov_ondemand) {
+#endif
 			cpufreq_cpu_put(policy);
 			continue;
 		}
@@ -472,7 +480,7 @@ static struct attribute_group od_attr_group_gov_pol = {
 
 /************************** sysfs end ************************/
 
-static int od_init(struct dbs_data *dbs_data)
+int od_init(struct dbs_data *dbs_data)
 {
 	struct od_dbs_tuners *tuners;
 	u64 idle_time;
@@ -514,14 +522,14 @@ static int od_init(struct dbs_data *dbs_data)
 	return 0;
 }
 
-static void od_exit(struct dbs_data *dbs_data)
+void od_exit(struct dbs_data *dbs_data)
 {
 	kfree(dbs_data->tuners);
 }
 
 define_get_cpu_dbs_routines(od_cpu_dbs_info);
 
-static struct od_ops od_ops = {
+struct od_ops od_ops = {
 	.powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu,
 	.powersave_bias_target = generic_powersave_bias_target,
 	.freq_increase = dbs_freq_increase,
-- 
1.7.10.4

[RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB

[Lukasz Majewski]

Some minor adjustments were needed to support LAB operation in the
cpufreq_governor.[h|c] files.

Most notably, code for proper estimation of the idle time for each CPU is
added here.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.c |    7 +++++++
 drivers/cpufreq/cpufreq_governor.h |    2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index ba43991..99fc3e8 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -98,6 +98,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 
 		load = 100 * (wall_time - idle_time) / wall_time;
 
+		if (dbs_data->cdata->governor == GOV_LAB) {
+			struct od_cpu_dbs_info_s *od_dbs_info =
+				dbs_data->cdata->get_cpu_dbs_info_s(j);
+
+			od_dbs_info->idle_time = (100 * idle_time) / wall_time;
+		}
+
 		if (load > max_load)
 			max_load = load;
 	}
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 34b1cf2..82a519f 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -152,6 +152,7 @@ struct od_cpu_dbs_info_s {
 	unsigned int freq_lo_jiffies;
 	unsigned int freq_hi_jiffies;
 	unsigned int rate_mult;
+	unsigned int idle_time;
 	unsigned int sample_type:1;
 };
 
@@ -187,6 +188,7 @@ struct common_dbs_data {
 	/* Common across governors */
 	#define GOV_ONDEMAND		0
 	#define GOV_CONSERVATIVE	1
+	#define GOV_LAB                 2
 	int governor;
 	struct attribute_group *attr_group_gov_sys; /* one governor - system */
 	struct attribute_group *attr_group_gov_pol; /* one governor - policy */
-- 
1.7.10.4

[RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code

[Lukasz Majewski]

This patch adds code for LAB governor. It shall be noted, that it reuses
a lot of ondemand code.

The main difference is that it works on top of ondemand, and this code is
able to "call" ondemand when needed. This means that all ondemand "backing"
data are properly updated.

Such approach has one major advantage - with LAB we can focus on saving
energy and leave the "normal" cpufreq management to well tested ondemand.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Makefile      |    1 +
 drivers/cpufreq/cpufreq_lab.c |  457 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 458 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..64bff8dc 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)	+= cpufreq_powersave.o
 obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE)	+= cpufreq_userspace.o
 obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)	+= cpufreq_ondemand.o
 obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)	+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB)		+= cpufreq_lab.o
 obj-$(CONFIG_CPU_FREQ_GOV_COMMON)		+= cpufreq_governor.o
 
 obj-$(CONFIG_GENERIC_CPUFREQ_CPU0)	+= cpufreq-cpu0.o
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 0000000..153c06b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *		Jonghwa Lee <jonghw3.lee@samusng.com>
+ *		Lukasz Majewski <l.majewski@samsung.com>
+ *
+ * LAB (Legacy Application Boost) cpufreq governor
+ *
+ * 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/cpufreq.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kernel_stat.h>
+#include <linux/kobject.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/percpu-defs.h>
+#include <linux/sysfs.h>
+#include <linux/tick.h>
+#include <linux/types.h>
+#include <linux/cpuidle.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+
+#include "cpufreq_governor.h"
+
+#define MAX_HIST		5
+
+#define LB_BOOST_ENABLE        ~0UL
+#define LB_MIN_FREQ            ~1UL
+#define LB_ONDEMAND             0
+
+/*
+ * Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int *idle_hist;
+static int idle_cpus, lb_threshold = 90;
+static unsigned int *lb_ctrl_table, lb_load;
+static int lb_ctrl_table_size, lb_num_of_states;
+static bool boost_init_state;
+
+static DECLARE_BITMAP(boost_hist, MAX_HIST);
+DECLARE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+
+struct cpufreq_governor cpufreq_gov_lab;
+
+
+static struct lb_wq_boost_data {
+	bool state;
+	struct work_struct work;
+} lb_boost_data;
+
+/*
+ * Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+	int i, sum;
+
+	for (i = 0, sum = 0; i < size; p++, i++) {
+		sum += *p;
+		*p >>= 1;
+	}
+	sum *= 100;
+
+	return (int) (sum / history_weight_sum[size - 1]);
+}
+
+static unsigned int lb_chose_freq(unsigned int load, int idle_cpus)
+{
+	unsigned int p, q = 100 / lb_num_of_states;
+	int idx;
+
+	for (idx = 0, p = q; idx < lb_num_of_states; idx++, p += q)
+		if (load <= p)
+			break;
+
+	return *(lb_ctrl_table + (lb_num_of_states * idle_cpus) + idx);
+}
+
+static void lb_cpufreq_boost_work(struct work_struct *work)
+{
+	struct lb_wq_boost_data *d = container_of(work,
+						  struct lb_wq_boost_data,
+						  work);
+	cpufreq_boost_trigger_state(d->state);
+}
+
+static struct common_dbs_data lb_dbs_cdata;
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load)
+{
+	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
+	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+	unsigned int freq = 0, op;
+	static int cnt;
+	int i, idx, bs;
+
+	idle_cpus = 0;
+	lb_load = load;
+	idx = cnt++ % MAX_HIST;
+
+	for_each_possible_cpu(i) {
+		struct od_cpu_dbs_info_s *dbs_cpu_info =
+			&per_cpu(od_cpu_dbs_info, i);
+
+		idle_hist[i * MAX_HIST + idx] = dbs_cpu_info->idle_time;
+		idle_avg[i] = cpu_idle_calc_avg(&idle_hist[i * MAX_HIST],
+					cnt < MAX_HIST ? cnt : MAX_HIST);
+
+		if (idle_avg[i] > lb_threshold)
+			idle_cpus++;
+	}
+
+	if (idle_cpus < 0 || idle_cpus > num_possible_cpus()) {
+		pr_warn("%s: idle_cpus: %d out of range\n", __func__,
+			idle_cpus);
+		return;
+	}
+
+	if (!lb_ctrl_table)
+		return;
+
+	op = lb_chose_freq(load, idle_cpus);
+	if (op == LB_BOOST_ENABLE)
+		set_bit(idx, boost_hist);
+	else
+		clear_bit(idx, boost_hist);
+
+	bs = cpufreq_boost_enabled();
+	/*
+	 * - To disable boost -
+	 *
+	 * Operation different than LB_BOOST_ENABLE is
+	 * required for at least MAX_HIST previous operations
+	 */
+	if (bs && bitmap_empty(boost_hist, MAX_HIST)) {
+		lb_boost_data.state = false;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	/*
+	 * - To enable boost -
+	 *
+	 * Only (MAX_HIST - 1) bits are required. This allows entering
+	 * BOOST mode earlier, since we skip one "round" of LAB operation
+	 * before work is executed.
+	 */
+	if (!bs &&
+	    (bitmap_weight(boost_hist, MAX_HIST) == (MAX_HIST - 1))) {
+		lb_boost_data.state = true;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	switch (op) {
+	case LB_BOOST_ENABLE:
+		freq = policy->max;
+		break;
+
+	case LB_MIN_FREQ:
+		freq = policy->min;
+		break;
+
+	case LB_ONDEMAND:
+		od_check_cpu(cpu, load);
+		return;
+
+	default:
+		freq = op;
+	}
+
+	if (policy->cur == freq)
+		return;
+
+	__cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
+}
+
+static ssize_t show_load(struct kobject *kobj,
+			 struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_load);
+}
+define_one_global_ro(load);
+
+static ssize_t show_idle_cpus_num(struct kobject *kobj,
+				  struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", idle_cpus);
+}
+define_one_global_ro(idle_cpus_num);
+
+static ssize_t show_idle_avg_cpus_val(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	char off;
+	int i;
+
+	for (i = 0, off = 0; i < num_possible_cpus(); i++)
+		off += sprintf(buf + off, "%u ", idle_avg[i]);
+
+	*(buf + off - 1) = '\n';
+
+	return off;
+}
+define_one_global_ro(idle_avg_cpus_val);
+
+static ssize_t show_idle_threshold(struct kobject *kobj,
+				   struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_threshold);
+}
+
+static ssize_t store_idle_threshold(struct kobject *a, struct attribute *b,
+				    const char *buf, size_t count)
+{
+	unsigned int val;
+	int ret;
+
+	ret = sscanf(buf, "%u", &val);
+	if (ret != 1)
+		return -EINVAL;
+
+	if (val < 0 || val > 100) {
+		pr_err("%s: Only value in a range 0 to 100 accepted\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	lb_threshold = val;
+	return count;
+}
+define_one_global_rw(idle_threshold);
+
+ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
+				   const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+	if (ret != 1)
+		return -EINVAL;
+
+	update_sampling_rate(dbs_data, input);
+	return count;
+}
+
+static ssize_t show_sampling_rate(struct kobject *kobj, struct attribute *attr,
+				  char *buf)
+{
+	struct od_dbs_tuners *tuners = lb_dbs_cdata.gdbs_data->tuners;
+
+	return sprintf(buf, "%u\n", tuners->sampling_rate);
+}
+define_one_global_rw(sampling_rate);
+
+static ssize_t show_sampling_rate_min(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+
+	return sprintf(buf, "%u\n", dbs_data->min_sampling_rate);
+}
+define_one_global_ro(sampling_rate_min);
+
+static struct attribute *dbs_attributes_gov_sys[] = {
+	&sampling_rate_min.attr,
+	&idle_avg_cpus_val.attr,
+	&idle_threshold.attr,
+	&idle_cpus_num.attr,
+	&sampling_rate.attr,
+	&load.attr,
+	NULL
+};
+
+static struct attribute_group lb_attr_group_gov_sys = {
+	.attrs = dbs_attributes_gov_sys,
+	.name = "lab",
+};
+
+static int lb_ctrl_table_of_init(struct device_node *dn,
+				 unsigned int **ctrl_tab, int size)
+{
+	struct property *pp;
+	int len;
+
+	pp = of_find_property(dn, "lab-ctrl-freq", &len);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-ctrl-freq'  not found\n", __func__);
+		return -ENODEV;
+	}
+
+	if (len != (size * sizeof(**ctrl_tab))) {
+		pr_err("%s: Wrong 'lab-ctrl-freq' size\n", __func__);
+		return -EINVAL;
+	}
+
+	*ctrl_tab = kzalloc(len, GFP_KERNEL);
+	if (!*ctrl_tab) {
+		pr_err("%s: Not enough memory for LAB control structure\n",
+		       __func__);
+		return -ENOMEM;
+	}
+
+	if (of_property_read_u32_array(dn, pp->name, *ctrl_tab, size)) {
+		pr_err("Property: %s cannot be read!\n", pp->name);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int lb_of_init(void)
+{
+	struct device_node *dn;
+	struct property *pp;
+	int ret;
+
+	dn = of_find_node_by_path("/cpus/cpu@0");
+	if (!dn) {
+		pr_err("%s: Node: '/cpus/cpu@0/' not found\n", __func__);
+		return -ENODEV;
+	}
+
+	pp = of_find_property(dn, "lab-num-of-states", NULL);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-num-of-states'  not found\n",
+		       __func__);
+		ret = -ENODEV;
+		goto dn_err;
+	}
+	lb_num_of_states = be32_to_cpup(pp->value);
+
+	lb_ctrl_table_size = lb_num_of_states * (num_possible_cpus() + 1);
+	ret = lb_ctrl_table_of_init(dn, &lb_ctrl_table, lb_ctrl_table_size);
+	if (ret) {
+		kfree(lb_ctrl_table);
+		lb_ctrl_table = NULL;
+		pr_err("%s: Cannot parse LAB control structure from OF\n",
+		       __func__);
+		return ret;
+	}
+
+dn_err:
+	of_node_put(dn);
+	return ret;
+}
+
+static int lb_init(struct dbs_data *dbs_data)
+{
+	int ret;
+
+	idle_avg = kzalloc(num_possible_cpus() * sizeof(*idle_avg), GFP_KERNEL);
+	if (!idle_avg) {
+		pr_err("%s: Not enough memory", __func__);
+		return -ENOMEM;
+	}
+
+	idle_hist = kzalloc(num_possible_cpus() * MAX_HIST * sizeof(*idle_hist),
+			    GFP_KERNEL);
+	if (!idle_hist) {
+		pr_err("%s: Not enough memory", __func__);
+		ret = -ENOMEM;
+		goto err_idle_avg;
+	}
+
+	ret = lb_of_init();
+	if (ret)
+		goto err_idle_hist;
+
+	boost_init_state = cpufreq_boost_enabled();
+	if (boost_init_state)
+		cpufreq_boost_trigger_state(false);
+
+	od_init(dbs_data);
+
+	INIT_WORK(&lb_boost_data.work, lb_cpufreq_boost_work);
+
+	return 0;
+
+err_idle_hist:
+	kfree(idle_hist);
+err_idle_avg:
+	kfree(idle_avg);
+
+	return ret;
+}
+
+void lb_exit(struct dbs_data *dbs_data)
+{
+	od_exit(dbs_data);
+
+	kfree(lb_ctrl_table);
+	lb_ctrl_table = NULL;
+
+	cpufreq_boost_trigger_state(boost_init_state);
+
+	kfree(idle_avg);
+	kfree(idle_hist);
+}
+
+define_get_cpu_dbs_routines(od_cpu_dbs_info);
+
+static struct common_dbs_data lb_dbs_cdata = {
+	.governor = GOV_LAB,
+	.attr_group_gov_sys = &lb_attr_group_gov_sys,
+	.get_cpu_cdbs = get_cpu_cdbs,
+	.get_cpu_dbs_info_s = get_cpu_dbs_info_s,
+	.gov_dbs_timer = od_dbs_timer,
+	.gov_check_cpu = lb_check_cpu,
+	.gov_ops = &od_ops,
+	.init = lb_init,
+	.exit = lb_exit,
+};
+
+static int lb_cpufreq_governor_dbs(struct cpufreq_policy *policy,
+		unsigned int event)
+{
+	return cpufreq_governor_dbs(policy, &lb_dbs_cdata, event);
+}
+
+struct cpufreq_governor cpufreq_gov_lab = {
+	.name			= "lab",
+	.governor		= lb_cpufreq_governor_dbs,
+	.max_transition_latency = TRANSITION_LATENCY_LIMIT,
+	.owner			= THIS_MODULE,
+};
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+	return cpufreq_register_governor(&cpufreq_gov_lab);
+}
+
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+fs_initcall(cpufreq_gov_dbs_init);
+#else
+module_init(cpufreq_gov_dbs_init);
+#endif
-- 
1.7.10.4

[RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig

[Lukasz Majewski]

Provide support for LAB governor for the Kbuild.

It is important to note, that LAB is not possible to be compiled in as
a module since we cannot assure (in the kernel) that backing ondemand
module will not be removed without notice to LAB.

For this reason the LAB can be only compiled into the kernel without
possibility to be compiled as a module.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Kconfig |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..3a870ea 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -102,6 +102,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
 	  Be aware that not all cpufreq drivers support the conservative
 	  governor. If unsure have a look at the help section of the
 	  driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_LAB
+	bool "lab"
+	select CPU_FREQ_GOV_LAB
+	select CPU_FREQ_GOV_PERFORMANCE
+	help
+	  Use the CPUFreq governor 'lab' as default. This allows
+	  you to get a full dynamic frequency capable system by simply
+	  loading your cpufreq low-level hardware driver.
+	  Be aware that not all cpufreq drivers support the lab governor.
+	  If unsure have a look at the help section of the driver.
+	  Fallback governor will be the performance governor.
 endchoice
 
 config CPU_FREQ_GOV_PERFORMANCE
@@ -183,6 +195,22 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+config CPU_FREQ_GOV_LAB
+	bool "'lab' cpufreq policy governor - ONDEMAND extension"
+	select CPU_FREQ_TABLE
+	select CPU_FREQ_GOV_COMMON
+	select CPU_FREQ_GOV_ONDEMAND
+	help
+	  'lab' - This driver adds a dynamic cpufreq policy governor.
+
+	  LAB governor shall be regarded as an extension of the ONDEMAND on
+	  platforms with very weak HW support for power management.
+
+	  LAB governor can be either compiled in or not. It is not possible to
+	  compile it as module because of explicit ONDEMAND dependency.
+
+	  If in doubt, say N.
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
-- 
1.7.10.4

[RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

[Lukasz Majewski]

Adds LAB attributes to proper CPU0 node.
The lab-num-of-states attribute shows how many compartments will be used.
The LAB code is prepared to be more fine grained.

The lab-ctrl-freq defines how the LAB governor will be controlled:
	- 0xFFFFFFFE 		- use the minimal frequency
	- 0xFFFFFFFF 		- enable boost
	- non zero 		- set the frequency specified
	- zero		- use ondemand to specify output frequency

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..9eeeb38 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -511,6 +511,35 @@
 		};
 	};
 
+	cpus {
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			lab-num-of-states = <5>;
+			lab-ctrl-freq = < 0          0          0          1300000    1200000
+					  0          0          0          0          1300000
+					  0          0          0          0          0xFFFFFFFF
+					  0          0          0          0xFFFFFFFF 0xFFFFFFFF
+					  0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE
+				>;
+		};
+
+		cpu@1 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@2 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@3 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+	};
+
 	camera {
 		pinctrl-0 = <&cam_port_b_clk_active>;
 		pinctrl-names = "default";
-- 
1.7.10.4

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Dear all,

> Despite this patch set is working and applicable on top of 3.14-rc5, 
> please regard it solely as a pure RFC.
> 
> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> 
> LAB short reminder:
> 
> LAB uses information about how many cores are in "idle" state (the
> core idleness is represented as the value between 0 and 100) and the
> overall load of the system (from 0 to 100) to decide about frequency
> to be set. It is extremely useful with SoCs like Exynos4412, which
> can set only one frequency for all cores.
> 
> Important design decisions:
> 
> - Reuse well established ondemand governor's internal code. To do this
>   I had to expose some previously static internal ondemand code. 
>   This allowed smaller LAB code when compared to previous version.
> 	
> - LAB works on top of ondemand, which means that one via device tree
>   attributes can specify if and when e.g. BOOST shall be enabled or
> if any particular frequency shall be imposed. For situation NOT
> important from the power consumption reduction viewpoint the ondemand
> is used to set proper frequency.
> 
> - It is only possible to either compile in or not the LAB into the
> kernel. There is no "M" option for Kconfig. It is done on purpose,
> since ondemand itself can be also compiled as a module and then it
> would be possible to remove ondemand when LAB is working on top of it.
> 
> - The LAB operation is specified (and thereof extendable) via device
> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> 
> 
> Problems:
> - How the governor will work for big.LITTLE systems (especially
> Global Task Scheduling).
> - Will there be agreement to expose internal ondemand code to be
> reused for more specialized governors.
> 
> Test HW:
> 	Exynos4412 - Trats2 board.
> Above patches were posted on top of Linux 3.14-rc5
> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> 

Any comments about those patches?

> Lukasz Majewski (5):
>   cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
>   cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to
> support LAB
>   cpufreq:LAB:lab Add LAB governor code
>   cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
>   cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
>  drivers/cpufreq/Kconfig                 |   28 ++
>  drivers/cpufreq/Makefile                |    1 +
>  drivers/cpufreq/cpufreq_governor.c      |    7 +
>  drivers/cpufreq/cpufreq_governor.h      |   12 +
>  drivers/cpufreq/cpufreq_lab.c           |  457
> +++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq_ondemand.c      |   24 +- 7 files changed,
> 550 insertions(+), 8 deletions(-) create mode 100644
> drivers/cpufreq/cpufreq_lab.c
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Despite this patch set is working and applicable on top of 3.14-rc5,
>> please regard it solely as a pure RFC.
>>
>> This patch provides support for LAB governor build on top of ondemand.
>> Previous version of LAB can be found here:
>> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>>
>> LAB short reminder:
>>
>> LAB uses information about how many cores are in "idle" state (the
>> core idleness is represented as the value between 0 and 100) and the
>> overall load of the system (from 0 to 100) to decide about frequency
>> to be set. It is extremely useful with SoCs like Exynos4412, which
>> can set only one frequency for all cores.
>>
>> Important design decisions:
>>
>> - Reuse well established ondemand governor's internal code. To do this
>>   I had to expose some previously static internal ondemand code.
>>   This allowed smaller LAB code when compared to previous version.
>>
>> - LAB works on top of ondemand, which means that one via device tree
>>   attributes can specify if and when e.g. BOOST shall be enabled or
>> if any particular frequency shall be imposed. For situation NOT
>> important from the power consumption reduction viewpoint the ondemand
>> is used to set proper frequency.
>>
>> - It is only possible to either compile in or not the LAB into the
>> kernel. There is no "M" option for Kconfig. It is done on purpose,
>> since ondemand itself can be also compiled as a module and then it
>> would be possible to remove ondemand when LAB is working on top of it.
>>
>> - The LAB operation is specified (and thereof extendable) via device
>> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
>>
>>
>> Problems:
>> - How the governor will work for big.LITTLE systems (especially
>> Global Task Scheduling).
>> - Will there be agreement to expose internal ondemand code to be
>> reused for more specialized governors.
>>
>> Test HW:
>>       Exynos4412 - Trats2 board.
>> Above patches were posted on top of Linux 3.14-rc5
>> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
>>
>
> Any comments about those patches?

Sorry for being late on reviewing these..

I tried to go through the patches but didn't looked at the minutest
of the details. Its been a long time when you first sent this patchset.
And the memories have corrupted by now :) ..

To get context back, can we discuss again the fundamentals behind
this new governor you are proposing. And then we can discuss about
it again, its pros/cons, etc..

I tried to go to earlier threads but I think we better do it again..

People are reluctant in getting another governor in and want to give
existing governors a try if possible.

So, please explain the basics behind your governor again and then
we can put our arguments again..

--
viresh

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> wrote:
> >> Despite this patch set is working and applicable on top of
> >> 3.14-rc5, please regard it solely as a pure RFC.
> >>
> >> This patch provides support for LAB governor build on top of
> >> ondemand. Previous version of LAB can be found here:
> >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >>
> >> LAB short reminder:
> >>
> >> LAB uses information about how many cores are in "idle" state (the
> >> core idleness is represented as the value between 0 and 100) and
> >> the overall load of the system (from 0 to 100) to decide about
> >> frequency to be set. It is extremely useful with SoCs like
> >> Exynos4412, which can set only one frequency for all cores.
> >>
> >> Important design decisions:
> >>
> >> - Reuse well established ondemand governor's internal code. To do
> >> this I had to expose some previously static internal ondemand code.
> >>   This allowed smaller LAB code when compared to previous version.
> >>
> >> - LAB works on top of ondemand, which means that one via device
> >> tree attributes can specify if and when e.g. BOOST shall be
> >> enabled or if any particular frequency shall be imposed. For
> >> situation NOT important from the power consumption reduction
> >> viewpoint the ondemand is used to set proper frequency.
> >>
> >> - It is only possible to either compile in or not the LAB into the
> >> kernel. There is no "M" option for Kconfig. It is done on purpose,
> >> since ondemand itself can be also compiled as a module and then it
> >> would be possible to remove ondemand when LAB is working on top of
> >> it.
> >>
> >> - The LAB operation is specified (and thereof extendable) via
> >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> >>
> >>
> >> Problems:
> >> - How the governor will work for big.LITTLE systems (especially
> >> Global Task Scheduling).
> >> - Will there be agreement to expose internal ondemand code to be
> >> reused for more specialized governors.
> >>
> >> Test HW:
> >>       Exynos4412 - Trats2 board.
> >> Above patches were posted on top of Linux 3.14-rc5
> >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> >>
> >
> > Any comments about those patches?
> 
> Sorry for being late on reviewing these..
> 
> I tried to go through the patches but didn't looked at the minutest
> of the details. Its been a long time when you first sent this
> patchset. And the memories have corrupted by now :) ..

Unfortunately memory is volatile ... since LAB governor is a follow up
of BOOST, which review and inclusion took considerable time, some
details could be forgotten. 

> 
> To get context back, can we discuss again the fundamentals behind
> this new governor you are proposing. And then we can discuss about
> it again, its pros/cons, etc..

Please consider following links:

The original implementation - threads:
http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab


LAB justification data:
http://article.gmane.org/gmane.linux.kernel/1472381


> People are reluctant in getting another governor in and want to give
> existing governors a try if possible.

As I've stated in the covering letter, this code is an extension of
Ondemand.

This is totally different from what have been posted previously (v1,
v2).
The first LAB proposal was written with some parts copied from Ondemand.
It was a separate, standalone governor.


The approach proposed in those patches is very different. It simply
reuses Ondemand code as much as possible (timers, default attributes
exported to sysfs, etc.).

On top of the Ondemand we have the LAB, which thereof is its optional
extension. The existing code is reused and can be easily extracted as a
common code.

> 
> So, please explain the basics behind your governor again and then
> we can put our arguments again..
> 

I hope that provided overview is sufficient. More in depth
information can be found in posted patches or provided LKML archives.

> --
> viresh

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> Despite this patch set is working and applicable on top of
> > >> 3.14-rc5, please regard it solely as a pure RFC.
> > >>
> > >> This patch provides support for LAB governor build on top of
> > >> ondemand. Previous version of LAB can be found here:
> > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >>
> > >> LAB short reminder:
> > >>
> > >> LAB uses information about how many cores are in "idle" state
> > >> (the core idleness is represented as the value between 0 and
> > >> 100) and the overall load of the system (from 0 to 100) to
> > >> decide about frequency to be set. It is extremely useful with
> > >> SoCs like Exynos4412, which can set only one frequency for all
> > >> cores.
> > >>
> > >> Important design decisions:
> > >>
> > >> - Reuse well established ondemand governor's internal code. To do
> > >> this I had to expose some previously static internal ondemand
> > >> code. This allowed smaller LAB code when compared to previous
> > >> version.
> > >>
> > >> - LAB works on top of ondemand, which means that one via device
> > >> tree attributes can specify if and when e.g. BOOST shall be
> > >> enabled or if any particular frequency shall be imposed. For
> > >> situation NOT important from the power consumption reduction
> > >> viewpoint the ondemand is used to set proper frequency.
> > >>
> > >> - It is only possible to either compile in or not the LAB into
> > >> the kernel. There is no "M" option for Kconfig. It is done on
> > >> purpose, since ondemand itself can be also compiled as a module
> > >> and then it would be possible to remove ondemand when LAB is
> > >> working on top of it.
> > >>
> > >> - The LAB operation is specified (and thereof extendable) via
> > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> > >>
> > >>
> > >> Problems:
> > >> - How the governor will work for big.LITTLE systems (especially
> > >> Global Task Scheduling).
> > >> - Will there be agreement to expose internal ondemand code to be
> > >> reused for more specialized governors.
> > >>
> > >> Test HW:
> > >>       Exynos4412 - Trats2 board.
> > >> Above patches were posted on top of Linux 3.14-rc5
> > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> > >>
> > >
> > > Any comments about those patches?
> > 
> > Sorry for being late on reviewing these..
> > 
> > I tried to go through the patches but didn't looked at the minutest
> > of the details. Its been a long time when you first sent this
> > patchset. And the memories have corrupted by now :) ..
> 
> Unfortunately memory is volatile ... since LAB governor is a follow up
> of BOOST, which review and inclusion took considerable time, some
> details could be forgotten. 
> 
> > 
> > To get context back, can we discuss again the fundamentals behind
> > this new governor you are proposing. And then we can discuss about
> > it again, its pros/cons, etc..
> 
> Please consider following links:
> 
> The original implementation - threads:
> http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab
> 
> 
> LAB justification data:
> http://article.gmane.org/gmane.linux.kernel/1472381
> 
> 
> > People are reluctant in getting another governor in and want to give
> > existing governors a try if possible.
> 
> As I've stated in the covering letter, this code is an extension of
> Ondemand.
> 
> This is totally different from what have been posted previously (v1,
> v2).
> The first LAB proposal was written with some parts copied from
> Ondemand. It was a separate, standalone governor.
> 
> 
> The approach proposed in those patches is very different. It simply
> reuses Ondemand code as much as possible (timers, default attributes
> exported to sysfs, etc.).
> 
> On top of the Ondemand we have the LAB, which thereof is its optional
> extension. The existing code is reused and can be easily extracted as
> a common code.
> 
> > 
> > So, please explain the basics behind your governor again and then
> > we can put our arguments again..
> > 
> 
> I hope that provided overview is sufficient. More in depth
> information can be found in posted patches or provided LKML archives.
> 

Viresh, will you find time for reviewing this RFC in a near future?

> > --
> > viresh
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 24 March 2014 12:17, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Viresh, will you find time for reviewing this RFC in a near future?

Yes. I have been trying hard last week but couldn't find some time
for it. Will try this week for sure.. Sorry to keep you waiting :(

@Rafael: Please see if you can also give them a look..

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.

Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fresh mind.
i.e. with zero memories of earlier discussions :)

LAB was: Legacy Application Boost ??

Probably mention that in your new threads as well, so that new readers
know the details. Also, like other governors, just name it "boost" governor.

> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> LAB short reminder:
>
> LAB uses information about how many cores are in "idle" state (the core
> idleness is represented as the value between 0 and 100) and the overall
> load of the system (from 0 to 100) to decide about frequency to be set.
> It is extremely useful with SoCs like Exynos4412, which can set only one
> frequency for all cores.

Probably a description of how exactly these two values come into play
would have been more interesting here for all. Always think of new followers
of your patchset and so add all interesting things about it when you resend
it.

If I remember well the logic was more or less like this:
- More idle cores means run few running cores at high frequency
- Less idle cores means don't run them at very high frequencies

Right?

What about making it as simple as:
- changing the ondemand governor only instead of adding a new governor
- Keeping the bahavior as is for all platforms not publishing boost frequencies
- If more cores are idle, enable switching to boost frequencies and take them
into consideration all the time.
- If less cores are idle, disable boost frequencies..

Lets discuss this first and then I will get into the very details of your
implementation.

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
> 
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
> 
> LAB was: Legacy Application Boost ??

Yes, correct.

> 
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.

I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.

> 
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
> 
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
> 
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
> 
> Right?

This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.

> 
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor

My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.

> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies

This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.

> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.

I'm not sure if I have understood you, but something like that is also
performed in the code.

> - If less cores are idle, disable boost frequencies..

As written above.

> 
> Lets discuss this first and then I will get into the very details of
> your implementation.

Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]

On 24 March 2014 15:30, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:

> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.

It doesn't matter with Mainline how you do naming initially for your code :)
We need to pick the right name now, and the decision should be made
now (after discussions obviously) :)

>> What about making it as simple as:
>> - changing the ondemand governor only instead of adding a new governor
>
> My goal is to not touch the ondemand code. It has matured, so I would
> like to leave it as it is.

Because the boost feature is already part of CPUFreq core, I think its
better if we enhance current governors to use it. So, I would like to
make this part of existing governors. Not only ondemand but maybe
conservative as well..

Also, I feel we maynot necessarily move this piece of code into cpufreq.
All you are doing is thermal management here :)

If we are sure we will not burn out our SoC (When many cores are idle),
run at max freq (if there is enough load of course :))..

And if there are chances that we might burn our chip (when very few
cores are idle), don't run on boost frequencies..

This is actually a 'cooling' device :)

Think of it this way: CPUFreq will provide a range of frequency which
SoC's can use. And then based on some conditions we may or may not
want to run on these frequencies.

@Zhang/Eduardo: Can we have your inputs here as well ?

This may look hard but we need to design things in the best possible
way for managing things better in future. Lets see what others have
to say on this.