Re: What is the commit for ARM VE 5.0 release
On Tue, 2013-02-05 at 15:13 +0800, Leo Yan wrote: On 01/29/2013 06:26 PM, Jon Medhurst (Tixy) wrote: What I suspect is that the configuration in SITE1/HBI0249A/board.txt isn't right, particularly the value for SCC 0x700. We are currently putting the files and instructions together for the 13.01 release, but if you use the attached board.txt file then I hope that will get the system booting on all CPUs. (One quirk I found when swapping back and forth between firmware versions is that it seemed to take two boots before the changes firmware worked correctly, I don't know if that's just something I'm doing different or if it is a general problem.) Tixy, thx a lot for the board.txt. Here i have some questions related with power management on TC2 board with 13.01 release: Sorry, I've not been involved in any of the actual development work for TC2 and am not familiar with how any of the power management works. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems
On Tue, Feb 5, 2013 at 6:37 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Monday, February 04, 2013 04:45:11 PM Nathan Zimmer wrote: I am noticing the cpufreq_driver_lock is quite hot. On an idle 512 system perf shows me most of the system time is spent on this lock. This is quite signifigant as top shows 5% of time in system time. My solution was to first convert the lock to a rwlock and then to the rcu. Nathan Zimmer (2): cpufreq: Convert the cpufreq_driver_lock to a rwlock cpufreq: Convert the cpufreq_driver_lock to use the rcu drivers/cpufreq/cpufreq.c | 139 ++ 1 file changed, 79 insertions(+), 60 deletions(-) I like these changes. Viresh, anyone, any comments? Hi Nathan/Rafael, Even i liked the basic idea behind the patchset, but didn't like the way it is divided into patches. For me, it is highly discouraged to undo something that you added in the same patchset. And you did exactly the same thing. Patch 2 is revert of 1 + rcu stuff. So, i would expect a single patch, i.e. merge of both patches + rebased on latest stuff. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 4 February 2013 19:06, Borislav Petkov b...@alien8.de wrote: On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote: Its not only for multicluster system, but a system where multiple cpus have separate clock control and hence multiple policy structures. What are those systems? Examples? Qualcomm's ARM based krait. Currently shipping in millions of Android phones. http://en.wikipedia.org/wiki/Krait_(CPU) Thanks Charles for pointing it out, I knew there is one :) -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What is the commit for ARM VE 5.0 release
On 02/05/2013 04:17 PM, Jon Medhurst (Tixy) wrote: On Tue, 2013-02-05 at 15:13 +0800, Leo Yan wrote: On 01/29/2013 06:26 PM, Jon Medhurst (Tixy) wrote: What I suspect is that the configuration in SITE1/HBI0249A/board.txt isn't right, particularly the value for SCC 0x700. We are currently putting the files and instructions together for the 13.01 release, but if you use the attached board.txt file then I hope that will get the system booting on all CPUs. (One quirk I found when swapping back and forth between firmware versions is that it seemed to take two boots before the changes firmware worked correctly, I don't know if that's just something I'm doing different or if it is a general problem.) Tixy, thx a lot for the board.txt. Here i have some questions related with power management on TC2 board with 13.01 release: Sorry, I've not been involved in any of the actual development work for TC2 and am not familiar with how any of the power management works. I will create a new thread to ask power related questions, thx. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 14:45, Borislav Petkov b...@alien8.de wrote:
On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
I think this is cleaner but whatever - I don't care that much. My
only strong concern is that this thing should be a Kconfig option and
optional for arches where it doesn't apply.
Your concern is: we don't want to fix userspace for existing platforms
where we have just a single cluster and so struct policy in the system.
No, as I said so many times already and you're unwilling to understand
it:
I am willing to, but not able to :)
multiple policies support in cpufreq should be optional and
selectable in Kconfig so that systems which don't need that, don't
have to see or use it. It is yet another feature which doesn't apply
universally so we make such features optional. Like the rest of the
gazillion things in the kernel already.
I understand what Kconfig options are for, but i am not able to understand
what's the benefit of this option here. For example: for single image solutions
we need to keep it enabled. And so, would need some sort of logic in cpufreq
core platform driver to decide where to create the governors directory.
The code without Kconfig option would be as simple as:
platform_driver:
init(struct cpufreq_policy *policy)
{
..
policy-have_multiple_policies = true;
..
}
cpufreq-core:
add_dev()
{
if (policy-have_multiple_policies)
create-folder-in-cpu/cpu*/cpufreq;
else
create-folder-in-cpu/cpufreq;
}
And so, platforms like Krait or big.LITTLE can set it to true from their
cpufreq-drivers. And this wouldn't break any of the current platforms.
The existing sysfs layout cannot be changed because you're breaking
userspace and we don't do that. It is that simple.
That's fine. I understood it already. :)
The problem i see is:
- both governor tunables, cpufreq-stats policy tunables (P-states) have the
same requirement. They are all per policy or clock-domain, instead of per cpu.
- I want to keep all of these at the same place, as they should be
present in the
same hierarchy.
- If we move everything to cpu/cpufreq/policy-names/ then also we would break
existing userspace stuff for stats and P-states.
- If we move everything to cpu/cpu*/cpufreq/ then also we would break
existing userspace stuff for governors.
Concerning adding new sysfs entries, I told you to make it as easy as
possible and as sensible as possible, dictated by the use cases. If you
can't come up with some, then talk to the people who are going to use
your design and ask them what makes sense the most.
For me cpu/cpu*/ is the most sensible as it is an very easy/convenient interface
for users. I am the first one who is going to use it :)
@Rafael: What's your view on this discussion we are having? We probably need few
more minds to jump in, as we are not moving towards a conclusion. :)
--
viresh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems
On Tuesday, February 05, 2013 01:58:20 PM Viresh Kumar wrote: On Tue, Feb 5, 2013 at 6:37 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Monday, February 04, 2013 04:45:11 PM Nathan Zimmer wrote: I am noticing the cpufreq_driver_lock is quite hot. On an idle 512 system perf shows me most of the system time is spent on this lock. This is quite signifigant as top shows 5% of time in system time. My solution was to first convert the lock to a rwlock and then to the rcu. Nathan Zimmer (2): cpufreq: Convert the cpufreq_driver_lock to a rwlock cpufreq: Convert the cpufreq_driver_lock to use the rcu drivers/cpufreq/cpufreq.c | 139 ++ 1 file changed, 79 insertions(+), 60 deletions(-) I like these changes. Viresh, anyone, any comments? Hi Nathan/Rafael, Even i liked the basic idea behind the patchset, but didn't like the way it is divided into patches. For me, it is highly discouraged to undo something that you added in the same patchset. And you did exactly the same thing. Patch 2 is revert of 1 + rcu stuff. So, i would expect a single patch, i.e. merge of both patches + rebased on latest stuff. I actually don't agree with that, becuase the Nathan's apprach shows the reasoning that leads to the RCU introduction quite clearly. So if you don't have technical problems with the patchset, I'm going to take it as is. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems
On Tuesday, February 05, 2013 03:28:30 PM Viresh Kumar wrote: On Tue, Feb 5, 2013 at 3:33 PM, Rafael J. Wysocki r...@sisk.pl wrote: I actually don't agree with that, becuase the Nathan's apprach shows the reasoning that leads to the RCU introduction quite clearly. So if you don't have technical problems with the patchset, I'm going to take it as is. Great!! Okay.. I don't have any technical problems with it, i reviewed most of it carefully. The only pending thing is rebase on linux-next, after that i can give my ack for it. Yes, it would be great if it were rebased and retested. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 15:57, Borislav Petkov b...@alien8.de wrote: Are you kidding me? You're simply not reading what I'm saying to you: ... should be optional and selectable in Kconfig so that systems which don't need that, don't have to see or use it. Because on those systems it doesn't apply. How about we add an x86-specific extension which is a big wad of code and is needlessly run on ARM just because it is easier? There isn't lot of code that we have to keep inside the macro you suggest. Its just an if else (with single line block), which would give the parent kobject. Nothing else. I didn't wanted to create a macro for just that. For me an if/else is not that big code. Anyway, if nobody else comes on my side i can create that macro for you. But, personally i would prefer code without such macros. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] PM / devfreq: set min/max freq limit from freq table
On 5 February 2013 12:21, MyungJoo Ham myungjoo@gmail.com wrote:
On Tue, Jan 15, 2013 at 8:21 PM, Rajagopal Venkat
rajagopal.ven...@linaro.org wrote:
On 14 January 2013 20:06, MyungJoo Ham myungjoo@samsung.com wrote:
On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
rajagopal.ven...@linaro.org wrote:
Set devfreq device min and max frequency limits when device
is added to devfreq, provided frequency table is supplied.
This helps governors to suggest target frequency with in
limits.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
Could you please elaborate the benefit of the patch?
When freq table is supplied, it's unreasonable to suggest the target
frequency
which is - target_freq min_freq and target_freq max_freq. It avoids
unnecessary checks at devfreq drivers.
Is it a safety barrier against userspace processes or devfreq governors?
Users are allowed to enter min_freq and max_freq via sysfs interfaces anyway.
Also, as mentioned earlier, users are allowed to enter 0 in order to
disengage the min/max_freq.
It doesn't interfere with userspace updates to min_freq/max_freq. The
min/max limits from freq table are assigned only during the device
devfreq init, which can be overwritten by userspace.
If we need hardware-specific min/max value, we'd need another sysfs
interfaces and values (i.e., scaling_min/max_freq vs
cpuinfo_min/max_freq).
In my opinion, min_freq and max_freq itself represents the devfreq
device freq limits. Additional sysfs interfaces may not be required.
Besides, if you are able to provide freq_table, it means that you
are able to provide OPP for the device.
Then, you can use OPP APIs to avoid unnecessary checks at devfreq
driver (even you can use the devfreq helper functions)
That's my intention as well. If driver is able to provide freq_table,
based on the load, let devfreq core suggest only the supported opps
(not just the limits, but for all intermediate opps). In which case,
devfreq core must mandate drivers to add OPP table(instead of passing
freq array) before registering with devfreq.
The devfreq device drivers are required to choose proper frequencies
anyway regardless which values the governors may give (hopefully by
choosing the closest value that can support the required performance).
Yes. but then each driver needs to have conditional checks for choosing
closet value even though freq table is provided.
Even with this min/max-freq, when governors suggests some values
between min/max, each driver needs to have checks unless it uses OPP.
With above proposal, devfreq should suggest only supported opps.
Besides, the min/max values are to be set by userspace. Users may
enter 0 in order to express that they do not want to limit the
behaviors of governors.
Because of this, this patch will create discrepency from/to userspace
interfaces.
As said above, there is no conflict of interest between userspace and
this patch.
In summary, I propose making OPP table mandatory for all devfreq
drivers, to enable devfreq core to suggest only supported opps. Any
thoughts?
Cheers,
MyungJoo.
Cheers,
MyungJoo.
---
drivers/devfreq/devfreq.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a8f0173..5782c9b 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -69,6 +69,29 @@ static struct devfreq *find_device_devfreq(struct
device *dev)
}
/**
+ * devfreq_set_freq_limits() - Set min and max frequency from freq_table
+ * @devfreq: the devfreq instance
+ */
+static void devfreq_set_freq_limits(struct devfreq *devfreq)
+{
+ int idx;
+ unsigned long min = ~0, max = 0;
+
+ if (!devfreq-profile-freq_table)
+ return;
+
+ for (idx = 0; idx devfreq-profile-max_state; idx++) {
+ if (min devfreq-profile-freq_table[idx])
+ min = devfreq-profile-freq_table[idx];
+ if (max devfreq-profile-freq_table[idx])
+ max = devfreq-profile-freq_table[idx];
+ }
+
+ devfreq-min_freq = min;
+ devfreq-max_freq = max;
+}
+
+/**
* devfreq_get_freq_level() - Lookup freq_table for the frequency
* @devfreq: the devfreq instance
* @freq: the target frequency
@@ -476,6 +499,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq-profile-max_state,
GFP_KERNEL);
devfreq-last_stat_updated = jiffies;
+ devfreq_set_freq_limits(devfreq);
dev_set_name(devfreq-dev, dev_name(dev));
err = device_register(devfreq-dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 16:34, Borislav Petkov b...@alien8.de wrote:
Here's an even cleaner way:
platform_driver:
init(struct cpufreq_policy *policy)
{
...
add_additional_sysfs_entries(policy);
...
}
...
static void add_additional_sysfs_entries(struct cpufreq_policy *policy)
{
#ifdef CONFIG_CPUFREQ_MULTIPLE_POLICIES
create-folder-in-cpu/cpu*/cpufreq;
...
#endif
}
and the platform driver will have in its Kconfig section:
config CPUFREQ_PLATFORM_DRIVER_X
...
select CPUFREQ_MULTIPLE_POLICIES
You don't need the policy-have_multiple_policies member even.
Tricky part is the name of this routine: add_additional_sysfs_entries().
I am not proposing additional set of directories inside cpu/cpu*/cpufreq/
but either of cpu/cpufreq/ or cpu/cpu*/cpufreq/ for governor.
And so, keeping that additional variable looks a better solution. Let me
get a patch with this change only and see how it looks.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 16:49, Borislav Petkov b...@alien8.de wrote: On Tue, Feb 05, 2013 at 04:42:23PM +0530, Viresh Kumar wrote: Tricky part is the name of this routine: add_additional_sysfs_entries(). Now you're just being silly - this is just an example how to do it. If you want me to do it for ya, you need to send me your monthly salary. Haha... I don't want you to do it. I don't want such routine to be exposed to cpufreq drivers as this belongs to the core code. Just some kind of indication from platform driver is required about how/where it wants its governor directory to be present. And the variable suits more here. Lets discuss it more on the next patch i send :) -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
Qualcomm's ARM based krait. Currently shipping in millions of Android phones. http://en.wikipedia.org/wiki/Krait_(CPU) Thanks Charles for pointing it out, I knew there is one :) -- viresh On 4 February 2013 19:06, Borislav Petkov b...@alien8.de wrote: On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote: Its not only for multicluster system, but a system where multiple cpus have separate clock control and hence multiple policy structures. What are those systems? Examples? Qualcomm's ARM based krait. Currently shipping in millions of Android phones. http://en.wikipedia.org/wiki/Krait_(CPU) Thanks Charles for pointing it out, I knew there is one :) -- viresh Actually shooting myself in the foot here, Krait is not such a great example because although you can use difference between frequencies you are less likely to use different tunables (not inconceivable but unlikely). The best examples systems are multi cluster and hereterogeneous systems, like the recently announced Samsung Exynos 5 octa http://en.wikipedia.org/wiki/Exynos_(system_on_chip). We will see more systems like this appearing, sporting low power cores combined with high performance ones, all running at the same time. I appreciate this is all very new, but more will come, and the requirement to have different tunables per cluster is very real. In ARM on our own multi cluster test chip, using an experimental version of this approach, we have seen good improvements in power consumption without compromising performance. (Apologies ahead for any bit my mail server appends, not much I can do about it) -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 17:02, Borislav Petkov b...@alien8.de wrote: On Tue, Feb 05, 2013 at 04:56:03PM +0530, Viresh Kumar wrote: Just some kind of indication from platform driver is required about how/where it wants its governor directory to be present. The indication is this: config CPUFREQ_PLATFORM_DRIVER_X ... select CPUFREQ_MULTIPLE_POLICIES You really need to slow down and really look at what I'm proposing. This indication isn't enough. On a single image solution, we need to identify the system which needs support for multiple policies and i still feel we need that variable type indication :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 5 February 2013 18:52, Borislav Petkov b...@alien8.de wrote: On Tue, Feb 05, 2013 at 05:54:57PM +0530, Viresh Kumar wrote:q This indication isn't enough. On a single image solution, we need to identify the system which needs support for multiple policies and i still feel we need that variable type indication :) If the image is going to run also on systems which support only a single policy, then I guess you can make it a bool, stuff it in struct cpufreq_policy and ifdef around it. That's what i proposed initially. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On 4 February 2013 17:08, Viresh Kumar viresh.ku...@linaro.org wrote:
Currently, there can't be multiple instances of single governor_type. If we
have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't
have
multiple instances of ondemand governor for multiple packages.
Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
governor-name/. Which again reflects that there can be only one instance of a
governor_type in the system.
This is a bottleneck for multicluster system, where we want different packages
to use same governor type, but with different tunables.
This patchset is inclined towards fixing this issue.
After a long hot discussion over the changes made by this patchset, following
patches came out:
--x--x---
commit 15b5548c9ccfb8088270f7574710d9d67edfe33b
Author: Viresh Kumar viresh.ku...@linaro.org
Date: Tue Feb 5 21:29:05 2013 +0530
cpufreq: Make governors directory sysfs location based on
have_multiple_policies
Until now directory for governors tunables was getting created in
cpu/cpufreq/gov-name. With the introduction of following patch:
cpufreq: governor: Implement per policy instances of governors
this directory would be created in
cpu/cpunum/cpufreq/gov-name. This might
break userspace of existing platforms. Lets do this change only
for platforms
which need support for multiple policies and thus above mentioned patch.
From now on, such platforms would be require to do following from
their init()
routines:
policy-have_multiple_policies = true;
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq_governor.c | 2 +-
include/linux/cpufreq.h| 14 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 545ae24..41ee86f 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -300,7 +300,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
dbs_data-cdata-gov_dbs_timer);
}
- rc = sysfs_create_group(policy-kobj,
+ rc = sysfs_create_group(get_governor_parent_kobj(policy),
dbs_data-cdata-attr_group);
if (rc) {
mutex_unlock(dbs_data-mutex);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 5dae7e6..6e1abd2 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -107,6 +107,11 @@ struct cpufreq_policy {
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
+ /* This should be set by init() of platforms having multiple
+* clock-domains, i.e. supporting multiple policies. With this sysfs
+* directories of governor would be created in cpu/cpunum/cpufreq/
+* directory */
+ boolhave_multiple_policies;
struct work_struct update; /* if update_policy() needs to be
* called, but you're in IRQ context */
@@ -134,6 +139,15 @@ static inline bool policy_is_shared(struct
cpufreq_policy *policy)
return cpumask_weight(policy-cpus) 1;
}
+static inline struct kobject *
+get_governor_parent_kobj(struct cpufreq_policy *policy)
+{
+ if (policy-have_multiple_policies)
+ return policy-kobj;
+ else
+ return cpufreq_global_kobject;
+}
+
/ cpufreq transition notifiers ***/
#define CPUFREQ_PRECHANGE (0)
--x--x---
Plus the following patch, though i am still not in favor of this patch.
@Rafael: Please share your opinion too on this one. :)
--x--x---
commit 1c7e9871fce7388136eda1c86ca75a520e4d3b9d
Author: Viresh Kumar viresh.ku...@linaro.org
Date: Tue Feb 5 21:41:40 2013 +0530
cpufreq: Add Kconfig option to enable/disable have_multiple_policies
have_multiple_policies is required by platforms having multiple
clock-domains
for cpus, i.e. supporting multiple policies for cpus. This patch adds in a
Kconfig option for enabling execution of this code.
Requested-by: Borislav Petkov b...@alien8.de
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/Kconfig | 3 +++
include/linux/cpufreq.h | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..e6e6939 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -23,6 +23,9 @@ config CPU_FREQ_TABLE
config CPU_FREQ_GOV_COMMON
bool
+config
RE: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
On Tue, Feb 05, 2013 at 11:29:04AM +, Charles Garcia-Tobin wrote: Actually shooting myself in the foot here, Krait is not such a great example because although you can use difference between frequencies you are less likely to use different tunables (not inconceivable but unlikely). The best examples systems are multi cluster and hereterogeneous systems, like the recently announced Samsung Exynos 5 octa http://en.wikipedia.org/wiki/Exynos_(system_on_chip). We will see more systems like this appearing, sporting low power cores combined with high performance ones, all running at the same time. I appreciate this is all very new, but more will come, and the requirement to have different tunables per cluster is very real. In ARM on our own multi cluster test chip, using an experimental version of this approach, we have seen good improvements in power consumption without compromising performance. Ok, thanks for giving this insight, this is useful. Question: do you need the granularity of that control to be per cpu (with that I mean what linux understands under cpu, i.e. logical or physical core) or does one governor suffice per a set of cores, or as you call it, a cluster? Later. Whatever you'd like to call it, but essentially a set of cpus, as linux understands them, that are logically related by the fact that you'd like to be able to use the same tuning policy and same governor across all of them. Cheers Charles (apologies again for annoying addendums to follow) -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
big.LITTLE MP status Feb 5, 2013
https://wiki.linaro.org/projects/big.LITTLE.MP Work Items for functional completion: https://wiki.linaro.org/projects/big.LITTLE.MP/WorkItems Roadmap Cards == Improving HMP Linux scheduling - http://cards.linaro.org/browse/CARD-190 Blueprints === Big.LITTLE MP blueprints are in the process of being updated to reflect the upcoming development iteration. https://blueprints.launchpad.net/linaro-big-little-system/+spec/cpu-hot-plug-latency https://blueprints.launchpad.net/linaro-big-little-system/+spec/power-aware-scheduler https://blueprints.launchpad.net/linaro-power-kernel/+spec/multi-cluster-cpuidle https://blueprints.launchpad.net/linaro-big-little-system/+spec/sched-cooperation-with-dvfs-and-idling https://blueprints.launchpad.net/linaro-big-little-system/+spec/timer-workqueue-cpu-quiescent https://blueprints.launchpad.net/linaro-big-little-system/+spec/big.little.mp.oem.reference.doc https://blueprints.launchpad.net/linaro-big-little-system/+spec/cpuidle-add-cpu-specific-states-capability QA === Bugs: https://bugs.launchpad.net/linaro-big-little-system/+bug/1112116: ARM requires confirmation that this is a TC2 issue not a generic ARM issue https://bugs.launchpad.net/linaro-big-little-system/+bug/1087149: Complicated and being investigated. Testing Results and Summary: https://docs.google.com/spreadsheet/ccc?key=0Ai9ggMs8bsGJdER3azBqWGtXNjRwb1UzSnZ4RGg3OUEusp=sharing See attachment for summary -- David Zinman, Project Manager Linaro.org | Open source software for ARM SoCs bL MP sched_test_results - Summary-Week-5.pdf Description: Adobe PDF document ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems
On Tuesday, February 05, 2013 02:58:35 PM Nathan Zimmer wrote: Ok, I'll rebase and retest from linux-next then. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Agenda posted for Android Platform/Mobile Development Meeting
We playing around with a new meeting format. We may split this meeting into 2, 30 min calls depending on how things go. Agenda: == Concall details == * https://wiki.linaro.org/Resources/ZipConferenceLine * Code: 6893745032 * Please try not to use the toll-free numbers if you can help it == Agenda == * Common * Discuss new meeting format, concall * Issues for ABS? * Platform * Connect topics * AOSP upstreaming, Arndale * Android Validation and Infrastructure * galaxynexus-aosp? * Ideas for making linux-linaro better * Vishal to send more agenda items * Mobile Development * Android optimization * big.LITTLE * Memory Hotplug * Android kernel feature upstreaminging * General Discussion * AOB Feel free to add more topics here or in https://wiki.linaro.org/Platform/Android/Meetings/2013-02-06. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/3] pm-qa: thermal: let tests return if heater program cannot be launched
If the heater program for heating CPU cannot be launched for some reason, the
tests should return right now, it is wasting time to execute all the rest parts
without heater program.
Signed-off-by: Hongbo Zhang hongbo.zh...@linaro.org
---
thermal/thermal_03.sh | 1 +
thermal/thermal_04.sh | 1 +
thermal/thermal_06.sh | 1 +
3 files changed, 3 insertions(+)
diff --git a/thermal/thermal_03.sh b/thermal/thermal_03.sh
index ff8ca33..f2cfb81 100755
--- a/thermal/thermal_03.sh
+++ b/thermal/thermal_03.sh
@@ -48,6 +48,7 @@ check_temperature_change() {
cpu_pid=$(ps | grep heat_cpu| awk '{print $1}')
test -z $cpu_pid cpu_pid=0
check start cpu heat binary test $cpu_pid -ne 0
+test $cpu_pid -eq 0 return
start_glmark2
diff --git a/thermal/thermal_04.sh b/thermal/thermal_04.sh
index 8f0dee7..7fe53e2 100755
--- a/thermal/thermal_04.sh
+++ b/thermal/thermal_04.sh
@@ -58,6 +58,7 @@ verify_cooling_device_temp_change() {
local cool_temp=0
./$HEAT_CPU_MODERATE moderate
pid=$!
+test $pid -eq 0 return
while (test $count -le $max_state); do
echo 0 $dirpath/cur_state
diff --git a/thermal/thermal_06.sh b/thermal/thermal_06.sh
index 0084281..b0a9442 100755
--- a/thermal/thermal_06.sh
+++ b/thermal/thermal_06.sh
@@ -60,6 +60,7 @@ check_trip_point_change() {
cpu_pid=$(ps | grep heat_cpu| awk '{print $1}')
test -z $cpu_pid cpu_pid=0
check start cpu heat binary test $cpu_pid -ne 0
+test $cpu_pid -eq 0 return
start_glmark2
--
1.8.0
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/3] pm-qa: collecting seperated test switches into one central file.
It is inconvenient for user to edit these seperated switches, so move them into
one central file.
Signed-off-by: Hongbo Zhang hongbo.zh...@linaro.org
---
Switches | 11 +++
include/functions.sh | 2 ++
suspend/suspend_01.sh | 5 +
suspend/suspend_02.sh | 5 +
suspend/suspend_03.sh | 5 +
suspend/suspend_04.sh | 5 +
suspend/suspend_05.sh | 4 +---
thermal/thermal_06.sh | 4 +---
8 files changed, 19 insertions(+), 22 deletions(-)
create mode 100644 Switches
diff --git a/Switches b/Switches
new file mode 100644
index 000..3a46ffe
--- /dev/null
+++ b/Switches
@@ -0,0 +1,11 @@
+# These are switches to enable/disable some tests.
+
+# Thermal tests
+thermal_try_max=0
+
+# Suspend tests
+suspend_dbus=0
+suspend_pmsuspend=1
+suspend_mem=1
+suspend_ac=0
+suspend_power=0
diff --git a/include/functions.sh b/include/functions.sh
index c39b6b7..7ee809b 100644
--- a/include/functions.sh
+++ b/include/functions.sh
@@ -23,6 +23,8 @@
# - initial API and implementation
#
+source ../Switches
+
CPU_PATH=/sys/devices/system/cpu
TEST_NAME=$(basename ${0%.sh})
PREFIX=$TEST_NAME
diff --git a/suspend/suspend_01.sh b/suspend/suspend_01.sh
index d67a66b..e591dc9 100755
--- a/suspend/suspend_01.sh
+++ b/suspend/suspend_01.sh
@@ -29,10 +29,7 @@
source ../include/functions.sh
source ../include/suspend_functions.sh
-# test_dbus: switch on/off this test
-test_dbus=1
-
-if [ $test_dbus -eq 0 ]; then
+if [ $suspend_dbus -eq 0 ]; then
log_skip dbus message suspend test not enabled
exit 0
fi
diff --git a/suspend/suspend_02.sh b/suspend/suspend_02.sh
index 7e33624..5e41d08 100755
--- a/suspend/suspend_02.sh
+++ b/suspend/suspend_02.sh
@@ -29,10 +29,7 @@
source ../include/functions.sh
source ../include/suspend_functions.sh
-# test_pmsuspend: switch on/off this test
-test_pmsuspend=1
-
-if [ $test_pmsuspend -eq 0 ]; then
+if [ $suspend_pmsuspend -eq 0 ]; then
log_skip pm-suspend test not enabled
exit 0
fi
diff --git a/suspend/suspend_03.sh b/suspend/suspend_03.sh
index 64f2fa1..b71966c 100755
--- a/suspend/suspend_03.sh
+++ b/suspend/suspend_03.sh
@@ -29,10 +29,7 @@
source ../include/functions.sh
source ../include/suspend_functions.sh
-# test_mem: switch on/off this test
-test_mem=1
-
-if [ $test_mem -eq 0 ]; then
+if [ $suspend_mem -eq 0 ]; then
log_skip suspend to ram via sysfs not enabled
exit 0
fi
diff --git a/suspend/suspend_04.sh b/suspend/suspend_04.sh
index 9f85400..8947afd 100755
--- a/suspend/suspend_04.sh
+++ b/suspend/suspend_04.sh
@@ -29,10 +29,7 @@
source ../include/functions.sh
source ../include/suspend_functions.sh
-# test_ac: switch on/off this test
-test_ac=0
-
-if [ $test_ac -eq 0 ]; then
+if [ $suspend_ac -eq 0 ]; then
log_skip suspend test involving ac power remove
exit 0
fi
diff --git a/suspend/suspend_05.sh b/suspend/suspend_05.sh
index 8604331..a87490c 100755
--- a/suspend/suspend_05.sh
+++ b/suspend/suspend_05.sh
@@ -29,11 +29,9 @@
source ../include/functions.sh
source ../include/suspend_functions.sh
-# test_power: switch on/off this test
-test_power=0
args_power_sleep=60
-if [ $test_power -eq 0 ]; then
+if [ $suspend_power -eq 0 ]; then
log_skip battery consumption test while suspend
exit 0
fi
diff --git a/thermal/thermal_06.sh b/thermal/thermal_06.sh
index 28fdaec..0084281 100755
--- a/thermal/thermal_06.sh
+++ b/thermal/thermal_06.sh
@@ -28,9 +28,7 @@
source ../include/functions.sh
source ../include/thermal_functions.sh
-# test_switch: switch on/off this test
-test_switch=0
-if [ $test_switch -eq 0 ]; then
+if [ $thermal_try_max -eq 0 ]; then
log_skip test of trip points being crossed
exit 0
fi
--
1.8.0
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/3] pm-qa: shced_mc: remove the obsolete sched_mc test
The sched_mc test is obsolete now and should be removed, if you still want to use this test for some reason, use tag pm-qa-0.4.0 or earlier. Signed-off-by: Hongbo Zhang hongbo.zh...@linaro.org --- Makefile | 2 -- sched_mc/Android.mk | 18 sched_mc/Makefile | 25 - sched_mc/sched_01.sh | 32 -- sched_mc/sched_01.txt | 1 - sched_mc/sched_02.sh | 38 - sched_mc/sched_02.txt | 1 - sched_mc/sched_03.sh | 33 -- sched_mc/sched_03.txt | 1 - sched_mc/sched_04.sh | 70 --- sched_mc/sched_04.txt | 1 - sched_mc/sched_sanity.sh | 35 sched_mc/sched_sanity.txt | 1 - 13 files changed, 258 deletions(-) delete mode 100644 sched_mc/Android.mk delete mode 100644 sched_mc/Makefile delete mode 100755 sched_mc/sched_01.sh delete mode 100644 sched_mc/sched_01.txt delete mode 100755 sched_mc/sched_02.sh delete mode 100644 sched_mc/sched_02.txt delete mode 100755 sched_mc/sched_03.sh delete mode 100644 sched_mc/sched_03.txt delete mode 100755 sched_mc/sched_04.sh delete mode 100644 sched_mc/sched_04.txt delete mode 100755 sched_mc/sched_sanity.sh delete mode 100644 sched_mc/sched_sanity.txt diff --git a/Makefile b/Makefile index fa979e0..52aa60d 100644 --- a/Makefile +++ b/Makefile @@ -30,7 +30,6 @@ check: @(cd cpufreq; $(MAKE) check) @(cd cpuhotplug; $(MAKE) check) @(cd cpuidle; $(MAKE) check) - @(cd sched_mc; $(MAKE) check) # @(cd suspend; $(MAKE) check) @(cd thermal; $(MAKE) check) # @(cd powertop; $(MAKE) check) @@ -39,7 +38,6 @@ uncheck: @(cd cpufreq; $(MAKE) uncheck) @(cd cpuhotplug; $(MAKE) uncheck) @(cd cpuidle; $(MAKE) uncheck) - @(cd sched_mc; $(MAKE) uncheck) # @(cd suspend; $(MAKE) uncheck) @(cd thermal; $(MAKE) uncheck) diff --git a/sched_mc/Android.mk b/sched_mc/Android.mk deleted file mode 100644 index f9f9d90..000 --- a/sched_mc/Android.mk +++ /dev/null @@ -1,18 +0,0 @@ -include $(call all-subdir-makefiles) -LOCAL_PATH:= $(call my-dir) - -module_name = sched - -define $(module_name)_add_executable -include $(CLEAR_VARS) -LOCAL_MODULE_TAGS := optional -LOCAL_MODULE_CLASS := tests -LOCAL_MODULE := $1.sh -systemtarball: $1.sh -LOCAL_SRC_FILES := $1.sh -LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)/pm-qa/$(module_name)_mc -include $(BUILD_PREBUILT) -endef - -test_num := 01 02 03 04 -$(foreach item,$(test_num),$(eval $(call $(module_name)_add_executable, $(module_name)_$(item diff --git a/sched_mc/Makefile b/sched_mc/Makefile deleted file mode 100644 index a90620c..000 --- a/sched_mc/Makefile +++ /dev/null @@ -1,25 +0,0 @@ -# -# PM-QA validation test suite for the power management on Linux -# -# Copyright (C) 2011, Linaro Limited. -# -# 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -# -# Contributors: -# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation) -# - initial API and implementation -# - -include ../Test.mk \ No newline at end of file diff --git a/sched_mc/sched_01.sh b/sched_mc/sched_01.sh deleted file mode 100755 index d4414b6..000 --- a/sched_mc/sched_01.sh +++ /dev/null @@ -1,32 +0,0 @@ -#!/bin/bash -# -# PM-QA validation test suite for the power management on Linux -# -# Copyright (C) 2011, Linaro Limited. -# -# 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -# -# Contributors: -# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation) -# - initial API
