Re: [PATCH v4 1/3] devfreq: Core updates to support devices which can idle
On 8 October 2012 13:44, MyungJoo Ham myungjoo@samsung.com wrote: Prepare devfreq core framework to support devices which can idle. When device idleness is detected perhaps through runtime-pm, need some mechanism to suspend devfreq load monitoring and resume back when device is online. Present code continues monitoring unless device is removed from devfreq core. This patch introduces following design changes, - use per device work instead of global work to monitor device load. This enables suspend/resume of device devfreq and reduces monitoring code complexity. - decouple delayed work based load monitoring logic from core by introducing helpers functions to be used by governors. This provides flexibility for governors either to use delayed work based monitoring functions or to implement their own mechanism. - devfreq core interacts with governors via events to perform specific actions. These events include start/stop devfreq. This sets ground for adding suspend/resume events. The devfreq apis are not modified and are kept intact. Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org Thank you! Reviewed and Tested (at Exynos4210-Nuri). Acked-by: MyungJoo Ham myungjoo@samsung.com Rafael, Can this patchset be queued for v3.7? Thanks. --- Documentation/ABI/testing/sysfs-class-devfreq | 8 - drivers/devfreq/devfreq.c | 443 +++--- drivers/devfreq/governor.h| 11 + drivers/devfreq/governor_performance.c| 16 +- drivers/devfreq/governor_powersave.c | 16 +- drivers/devfreq/governor_simpleondemand.c | 24 ++ drivers/devfreq/governor_userspace.c | 23 +- include/linux/devfreq.h | 34 +- 8 files changed, 279 insertions(+), 296 deletions(-) -- Regards, Rajagopal ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Interesting(?) health failure
Hi all, I found an interesting health failure today on origen07 http://validation.linaro.org/lava-server/scheduler/job/35016/log_file When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a reboot, which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job). What then started alarm bells ringing was that I saw this: 1261680 bytes read reading uInitrd 1532597 bytes read reading board.dtb ** Unable to read board.dtb from mmc 0:5 ** So whatever the test image was, it was expecting a device tree blob, which I would have assumed would have to have been installed during deploy_linaro_image() being that if there is one it should just be part of the test boot deployment. So I looked at the log from the previous job: http://validation.linaro.org/lava-server/scheduler/job/34938/log_file#entry24 and sure enough, you'll see at that mark the same issue. So there are two things: 1) There's some twisted logic in the dispatcher that's making it do odd things if it starts off in u-boot 2) Do we have an issue with dtbs not being handled properly by lava, or is it just that the hwpack was incomplete? Thanks Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 1/3] devfreq: Core updates to support devices which can idle
2012. 10. 10. 오후 4:19에 Rajagopal Venkat rajagopal.ven...@linaro.org님이 작성: On 8 October 2012 13:44, MyungJoo Ham myungjoo@samsung.com wrote: Prepare devfreq core framework to support devices which can idle. When device idleness is detected perhaps through runtime-pm, need some mechanism to suspend devfreq load monitoring and resume back when device is online. Present code continues monitoring unless device is removed from devfreq core. This patch introduces following design changes, - use per device work instead of global work to monitor device load. This enables suspend/resume of device devfreq and reduces monitoring code complexity. - decouple delayed work based load monitoring logic from core by introducing helpers functions to be used by governors. This provides flexibility for governors either to use delayed work based monitoring functions or to implement their own mechanism. - devfreq core interacts with governors via events to perform specific actions. These events include start/stop devfreq. This sets ground for adding suspend/resume events. The devfreq apis are not modified and are kept intact. Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org Thank you! Reviewed and Tested (at Exynos4210-Nuri). Acked-by: MyungJoo Ham myungjoo@samsung.com Rafael, Can this patchset be queued for v3.7? Thanks. --- Documentation/ABI/testing/sysfs-class-devfreq | 8 - drivers/devfreq/devfreq.c | 443 +++--- drivers/devfreq/governor.h| 11 + drivers/devfreq/governor_performance.c| 16 +- drivers/devfreq/governor_powersave.c | 16 +- drivers/devfreq/governor_simpleondemand.c | 24 ++ drivers/devfreq/governor_userspace.c | 23 +- include/linux/devfreq.h | 34 +- 8 files changed, 279 insertions(+), 296 deletions(-) -- Regards, Rajagopal -- 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 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/10] ARM: sched: Use device-tree to provide fast/slow CPU list for HMP
On Thu, Oct 04, 2012 at 07:49:32AM +0100, Viresh Kumar wrote:
On 22 September 2012 00:02, morten.rasmus...@arm.com wrote:
From: Morten Rasmussen morten.rasmus...@arm.com
We can't rely on Kconfig options to set the fast and slow CPU lists for
HMP scheduling if we want a single kernel binary to support multiple
devices with different CPU topology. E.g. TC2 (ARM's Test-Chip-2
big.LITTLE system), Fast Models, or even non big.LITTLE devices.
This patch adds the function arch_get_fast_and_slow_cpus() to generate
the lists at run-time by parsing the CPU nodes in device-tree; it
assumes slow cores are A7s and everything else is fast. The function
still supports the old Kconfig options as this is useful for testing the
HMP scheduler on devices without big.LITTLE.
But this code is handling this case too at the end, with following logic:
+ cpumask_setall(fast);
+ cpumask_clear(slow);
Am i missing something?
The HMP setup can be defined using Kconfig or DT. If both fails, it will
set all cpus to be fast cpus and effectively disable SCHED_HMP. The
Kconfig option is kept to allow testing of alternative HMP setups
without having to change the DT or use DT at all which might be handy
for non-ARM platforms. I hope that answers you question.
This patch is reuse of a patch by Jon Medhurst t...@linaro.org with a
few bits left out.
Then probably he must be the author of this commit? Also a SOB is required
from him here.
I don't know what the correct procedure is for this sort of partial
patch reuse. Since I didn't know better, I adopted Tixy's own reference
style that he used in one of his patches which is an extension of a
previous patch by me. I will of course fix it to follow normal procedure
if there is one.
Signed-off-by: Morten Rasmussen morten.rasmus...@arm.com
---
arch/arm/Kconfig |4 ++-
arch/arm/kernel/topology.c | 69
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cb80846..f1271bc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1588,13 +1588,15 @@ config HMP_FAST_CPU_MASK
string HMP scheduler fast CPU mask
depends on SCHED_HMP
help
- Specify the cpuids of the fast CPUs in the system as a list
string,
+ Leave empty to use device tree information.
+ Specify the cpuids of the fast CPUs in the system as a list
string,
e.g. cpuid 0+1 should be specified as 0-1.
config HMP_SLOW_CPU_MASK
string HMP scheduler slow CPU mask
depends on SCHED_HMP
help
+ Leave empty to use device tree information.
Specify the cpuids of the slow CPUs in the system as a list
string,
e.g. cpuid 0+1 should be specified as 0-1.
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 26c12c6..7682e12 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -317,6 +317,75 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
+
+#ifdef CONFIG_SCHED_HMP
+
+static const char * const little_cores[] = {
+ arm,cortex-a7,
+ NULL,
+};
+
+static bool is_little_cpu(struct device_node *cn)
+{
+ const char * const *lc;
+ for (lc = little_cores; *lc; lc++)
+ if (of_device_is_compatible(cn, *lc))
+ return true;
+ return false;
+}
+
+void __init arch_get_fast_and_slow_cpus(struct cpumask *fast,
+ struct cpumask *slow)
+{
+ struct device_node *cn = NULL;
+ int cpu = 0;
+
+ cpumask_clear(fast);
+ cpumask_clear(slow);
+
+ /*
+* Use the config options if they are given. This helps testing
+* HMP scheduling on systems without a big.LITTLE architecture.
+*/
+ if (strlen(CONFIG_HMP_FAST_CPU_MASK)
strlen(CONFIG_HMP_SLOW_CPU_MASK)) {
+ if (cpulist_parse(CONFIG_HMP_FAST_CPU_MASK, fast))
+ WARN(1, Failed to parse HMP fast cpu mask!\n);
+ if (cpulist_parse(CONFIG_HMP_SLOW_CPU_MASK, slow))
+ WARN(1, Failed to parse HMP slow cpu mask!\n);
+ return;
+ }
+
+ /*
+* Else, parse device tree for little cores.
+*/
+ while ((cn = of_find_node_by_type(cn, cpu))) {
+
+ if (cpu = num_possible_cpus())
+ break;
+
+ if (is_little_cpu(cn))
+ cpumask_set_cpu(cpu, slow);
+ else
+ cpumask_set_cpu(cpu, fast);
+
+ cpu++;
+ }
+
+ if (!cpumask_empty(fast) !cpumask_empty(slow))
+ return;
+
Re: [RFC PATCH 06/10] ARM: sched: Use device-tree to provide fast/slow CPU list for HMP
On 10 October 2012 15:47, Morten Rasmussen morten.rasmus...@arm.com wrote: On Thu, Oct 04, 2012 at 07:49:32AM +0100, Viresh Kumar wrote: This patch is reuse of a patch by Jon Medhurst t...@linaro.org with a few bits left out. Then probably he must be the author of this commit? Also a SOB is required from him here. I don't know what the correct procedure is for this sort of partial patch reuse. Since I didn't know better, I adopted Tixy's own reference style that he used in one of his patches which is an extension of a previous patch by me. I will of course fix it to follow normal procedure if there is one. AFAIK, if you have used only some part of the earlier patch, then you just need to add an SOB of original author. But if you have picked most of the stuff from original patch, which i feel is the case here, you must have original author in author SOB + your SOB. It would be very easy to blame someone else here... :) I will fix it. :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 06/10] ARM: sched: Use device-tree to provide fast/slow CPU list for HMP
Hi Tixy,
Could you have a look at my code stealing patch below? Since it is
basically a trimmed version of one of your patches I would prefer to
put you as author and have your SOB on it. What is your opinion?
Thanks,
Morten
On Fri, Sep 21, 2012 at 07:32:21PM +0100, Morten Rasmussen wrote:
From: Morten Rasmussen morten.rasmus...@arm.com
We can't rely on Kconfig options to set the fast and slow CPU lists for
HMP scheduling if we want a single kernel binary to support multiple
devices with different CPU topology. E.g. TC2 (ARM's Test-Chip-2
big.LITTLE system), Fast Models, or even non big.LITTLE devices.
This patch adds the function arch_get_fast_and_slow_cpus() to generate
the lists at run-time by parsing the CPU nodes in device-tree; it
assumes slow cores are A7s and everything else is fast. The function
still supports the old Kconfig options as this is useful for testing the
HMP scheduler on devices without big.LITTLE.
This patch is reuse of a patch by Jon Medhurst t...@linaro.org with a
few bits left out.
Signed-off-by: Morten Rasmussen morten.rasmus...@arm.com
---
arch/arm/Kconfig |4 ++-
arch/arm/kernel/topology.c | 69
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cb80846..f1271bc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1588,13 +1588,15 @@ config HMP_FAST_CPU_MASK
string HMP scheduler fast CPU mask
depends on SCHED_HMP
help
- Specify the cpuids of the fast CPUs in the system as a list string,
+ Leave empty to use device tree information.
+ Specify the cpuids of the fast CPUs in the system as a list string,
e.g. cpuid 0+1 should be specified as 0-1.
config HMP_SLOW_CPU_MASK
string HMP scheduler slow CPU mask
depends on SCHED_HMP
help
+ Leave empty to use device tree information.
Specify the cpuids of the slow CPUs in the system as a list string,
e.g. cpuid 0+1 should be specified as 0-1.
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 26c12c6..7682e12 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -317,6 +317,75 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
+
+#ifdef CONFIG_SCHED_HMP
+
+static const char * const little_cores[] = {
+ arm,cortex-a7,
+ NULL,
+};
+
+static bool is_little_cpu(struct device_node *cn)
+{
+ const char * const *lc;
+ for (lc = little_cores; *lc; lc++)
+ if (of_device_is_compatible(cn, *lc))
+ return true;
+ return false;
+}
+
+void __init arch_get_fast_and_slow_cpus(struct cpumask *fast,
+ struct cpumask *slow)
+{
+ struct device_node *cn = NULL;
+ int cpu = 0;
+
+ cpumask_clear(fast);
+ cpumask_clear(slow);
+
+ /*
+ * Use the config options if they are given. This helps testing
+ * HMP scheduling on systems without a big.LITTLE architecture.
+ */
+ if (strlen(CONFIG_HMP_FAST_CPU_MASK)
strlen(CONFIG_HMP_SLOW_CPU_MASK)) {
+ if (cpulist_parse(CONFIG_HMP_FAST_CPU_MASK, fast))
+ WARN(1, Failed to parse HMP fast cpu mask!\n);
+ if (cpulist_parse(CONFIG_HMP_SLOW_CPU_MASK, slow))
+ WARN(1, Failed to parse HMP slow cpu mask!\n);
+ return;
+ }
+
+ /*
+ * Else, parse device tree for little cores.
+ */
+ while ((cn = of_find_node_by_type(cn, cpu))) {
+
+ if (cpu = num_possible_cpus())
+ break;
+
+ if (is_little_cpu(cn))
+ cpumask_set_cpu(cpu, slow);
+ else
+ cpumask_set_cpu(cpu, fast);
+
+ cpu++;
+ }
+
+ if (!cpumask_empty(fast) !cpumask_empty(slow))
+ return;
+
+ /*
+ * We didn't find both big and little cores so let's call all cores
+ * fast as this will keep the system running, with all cores being
+ * treated equal.
+ */
+ cpumask_setall(fast);
+ cpumask_clear(slow);
+}
+
+#endif /* CONFIG_SCHED_HMP */
+
+
/*
* init_cpu_topology is called at boot when only one cpu is running
* which prevent simultaneous write access to cpu_topology array
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 06/10] ARM: sched: Use device-tree to provide fast/slow CPU list for HMP
On Wed, 2012-10-10 at 12:04 +0100, Morten Rasmussen wrote:
Hi Tixy,
Could you have a look at my code stealing patch below? Since it is
basically a trimmed version of one of your patches I would prefer to
put you as author and have your SOB on it. What is your opinion?
Yes, I can agree with that opinion, (and my employer likes to count
their patch totals ;-) so please feel free to add:
From: Jon Medhurst t...@linaro.org
Signed-off-by: Jon Medhurst t...@linaro.org
Thanks
--
Tixy
Thanks,
Morten
On Fri, Sep 21, 2012 at 07:32:21PM +0100, Morten Rasmussen wrote:
From: Morten Rasmussen morten.rasmus...@arm.com
We can't rely on Kconfig options to set the fast and slow CPU lists for
HMP scheduling if we want a single kernel binary to support multiple
devices with different CPU topology. E.g. TC2 (ARM's Test-Chip-2
big.LITTLE system), Fast Models, or even non big.LITTLE devices.
This patch adds the function arch_get_fast_and_slow_cpus() to generate
the lists at run-time by parsing the CPU nodes in device-tree; it
assumes slow cores are A7s and everything else is fast. The function
still supports the old Kconfig options as this is useful for testing the
HMP scheduler on devices without big.LITTLE.
This patch is reuse of a patch by Jon Medhurst t...@linaro.org with a
few bits left out.
Signed-off-by: Morten Rasmussen morten.rasmus...@arm.com
---
arch/arm/Kconfig |4 ++-
arch/arm/kernel/topology.c | 69
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cb80846..f1271bc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1588,13 +1588,15 @@ config HMP_FAST_CPU_MASK
string HMP scheduler fast CPU mask
depends on SCHED_HMP
help
- Specify the cpuids of the fast CPUs in the system as a list
string,
+ Leave empty to use device tree information.
+ Specify the cpuids of the fast CPUs in the system as a list string,
e.g. cpuid 0+1 should be specified as 0-1.
config HMP_SLOW_CPU_MASK
string HMP scheduler slow CPU mask
depends on SCHED_HMP
help
+ Leave empty to use device tree information.
Specify the cpuids of the slow CPUs in the system as a list string,
e.g. cpuid 0+1 should be specified as 0-1.
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 26c12c6..7682e12 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -317,6 +317,75 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
+
+#ifdef CONFIG_SCHED_HMP
+
+static const char * const little_cores[] = {
+ arm,cortex-a7,
+ NULL,
+};
+
+static bool is_little_cpu(struct device_node *cn)
+{
+ const char * const *lc;
+ for (lc = little_cores; *lc; lc++)
+ if (of_device_is_compatible(cn, *lc))
+ return true;
+ return false;
+}
+
+void __init arch_get_fast_and_slow_cpus(struct cpumask *fast,
+ struct cpumask *slow)
+{
+ struct device_node *cn = NULL;
+ int cpu = 0;
+
+ cpumask_clear(fast);
+ cpumask_clear(slow);
+
+ /*
+* Use the config options if they are given. This helps testing
+* HMP scheduling on systems without a big.LITTLE architecture.
+*/
+ if (strlen(CONFIG_HMP_FAST_CPU_MASK)
strlen(CONFIG_HMP_SLOW_CPU_MASK)) {
+ if (cpulist_parse(CONFIG_HMP_FAST_CPU_MASK, fast))
+ WARN(1, Failed to parse HMP fast cpu mask!\n);
+ if (cpulist_parse(CONFIG_HMP_SLOW_CPU_MASK, slow))
+ WARN(1, Failed to parse HMP slow cpu mask!\n);
+ return;
+ }
+
+ /*
+* Else, parse device tree for little cores.
+*/
+ while ((cn = of_find_node_by_type(cn, cpu))) {
+
+ if (cpu = num_possible_cpus())
+ break;
+
+ if (is_little_cpu(cn))
+ cpumask_set_cpu(cpu, slow);
+ else
+ cpumask_set_cpu(cpu, fast);
+
+ cpu++;
+ }
+
+ if (!cpumask_empty(fast) !cpumask_empty(slow))
+ return;
+
+ /*
+* We didn't find both big and little cores so let's call all cores
+* fast as this will keep the system running, with all cores being
+* treated equal.
+*/
+ cpumask_setall(fast);
+ cpumask_clear(slow);
+}
+
+#endif /* CONFIG_SCHED_HMP */
+
+
/*
* init_cpu_topology is called at boot when only one cpu is running
* which prevent simultaneous write access to cpu_topology array
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq
Hi Viresh, On 08/10/12 14:58, viresh kumar wrote: Hi All, Sorry for asking one of the most basic question of cpufreq :( I couldn't get the difference between affected (policy-cpus) and related cpus (policy-related_cpus) in cpufreq... As per Documentation/code: affected_cpus(policy-cpus): - List of CPUs that require software coordination of frequency. - Processors part of affected_cpus share policy struct - Policy limits the frequencies that the processor can work with. related_cpus(policy-related_cpus): - List of CPUs that need some sort of frequency coordination, whether software or hardware. - Processors part of related_cpus share governer. Which document states this ? As per my understanding and if you see in cpufreq.c, related_cpus are used only when adding back the hotplugged cpu to get the governor. Elsewhere affected_cpus is used. Ideally it would be good if above statements is true. E.g. In SMP with 4 CPUs(with same OPPs), if 0-1 and 2-3 need h/w co-ordination, then: related_cpus: 0-1 and 2-3 affected_cpus: case#1: 0-1 and 2-3 if we want to have different policies case#2: 0-3 if we want to have same policy on all CPUS I believe this is not possible in current code. - Governer sets the rules, about when to change limits specified by policy. Correct? So, now comes the real question: - In which scenario's should we populate affected and related cpus? - Should related cpus will always be a superset of affected cpus? -- Viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq
On 10 October 2012 17:31, Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com wrote: On 08/10/12 14:58, viresh kumar wrote: affected_cpus(policy-cpus): - List of CPUs that require software coordination of frequency. - Processors part of affected_cpus share policy struct - Policy limits the frequencies that the processor can work with. related_cpus(policy-related_cpus): - List of CPUs that need some sort of frequency coordination, whether software or hardware. - Processors part of related_cpus share governer. Which document states this ? Code. As per my understanding and if you see in cpufreq.c, related_cpus are used only when adding back the hotplugged cpu to get the governor. Elsewhere affected_cpus is used. Probably yes. I was wrong. Ideally it would be good if above statements is true. E.g. In SMP with 4 CPUs(with same OPPs), if 0-1 and 2-3 need h/w co-ordination, then: related_cpus: 0-1 and 2-3 affected_cpus: case#1: 0-1 and 2-3 if we want to have different policies case#2: 0-3 if we want to have same policy on all CPUS I believe this is not possible in current code. I couldn't understand the difference b/w h/w and s/w coordination. What do we mean by them here. Following patch added related related_cpu stuff: commit e8628dd06d66f2e3965ec9742029b401d63434f1 Author: Darrick J. Wong djw...@us.ibm.com Date: Fri Apr 18 13:31:12 2008 -0700 [CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption. To fix this, create a related_cpus attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide a value, fall back to policy-cpus. Signed-off-by: Darrick J. Wong djw...@us.ibm.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Jones da...@redhat.com --- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 07/10] ARM: sched: Setup SCHED_HMP domains
On Thu, Oct 04, 2012 at 07:58:45AM +0100, Viresh Kumar wrote:
On 22 September 2012 00:02, morten.rasmus...@arm.com wrote:
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
+void __init arch_get_hmp_domains(struct list_head *hmp_domains_list)
+{
+ struct cpumask hmp_fast_cpu_mask;
+ struct cpumask hmp_slow_cpu_mask;
can be merged to single line.
+ struct hmp_domain *domain;
+
+ arch_get_fast_and_slow_cpus(hmp_fast_cpu_mask, hmp_slow_cpu_mask);
+
+ /*
+* Initialize hmp_domains
+* Must be ordered with respect to compute capacity.
+* Fastest domain at head of list.
+*/
+ domain = (struct hmp_domain *)
+ kmalloc(sizeof(struct hmp_domain), GFP_KERNEL);
should be:
domain = kmalloc(sizeof(*domain), GFP_KERNEL);
+ cpumask_copy(domain-cpus, hmp_slow_cpu_mask);
what if kmalloc failed?
+ list_add(domain-hmp_domains, hmp_domains_list);
+ domain = (struct hmp_domain *)
+ kmalloc(sizeof(struct hmp_domain), GFP_KERNEL);
would be better to kmalloc only once with size 2* sizeof(*domain)
+ cpumask_copy(domain-cpus, hmp_fast_cpu_mask);
+ list_add(domain-hmp_domains, hmp_domains_list);
Also would be better to create a macro for above two lines to remove
code redundancy.
Agree on all of the above.
Thanks,
Morten
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Interesting(?) health failure
Hi Dave, On 10/10/2012 11:35 AM, Dave Pigott wrote: Hi all, I found an interesting health failure today on origen07 http://validation.linaro.org/lava-server/scheduler/job/35016/log_file When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a reboot, which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job). What then started alarm bells ringing was that I saw this: 1261680 bytes read reading uInitrd 1532597 bytes read reading board.dtb ** Unable to read board.dtb from mmc 0:5 ** So whatever the test image was, it was expecting a device tree blob, which I would have assumed would have to have been installed during deploy_linaro_image() being that if there is one it should just be part of the test boot deployment. So I looked at the log from the previous job: http://validation.linaro.org/lava-server/scheduler/job/34938/log_file#entry24 and sure enough, you'll see at that mark the same issue. So there are two things: 1) There's some twisted logic in the dispatcher that's making it do odd things if it starts off in u-boot 2) Do we have an issue with dtbs not being handled properly by lava, or is it just that the hwpack was incomplete? Regarding the 2). No dtb in the hwpack. I've created a very similar bug for another ci project: https://bugs.launchpad.net/linaro-ci/+bug/1064686 Probably ubuntu packed kernels is the only project (view) in jenkins handling the dtb in the right way. Please note, that the dtb must be properly described in the hwpack, so that it could be picked up by LAVA / l-m-c. This is out of scope of the bug 1064686. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq
On 10/10/12 14:26, Viresh Kumar wrote: [...] I couldn't understand the difference b/w h/w and s/w coordination. What do we mean by them here. Following patch added related related_cpu stuff: commit e8628dd06d66f2e3965ec9742029b401d63434f1 Author: Darrick J. Wong djw...@us.ibm.com Date: Fri Apr 18 13:31:12 2008 -0700 [CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption. To fix this, create a related_cpus attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide a value, fall back to policy-cpus. Signed-off-by: Darrick J. Wong djw...@us.ibm.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Jones da...@redhat.com --- Here is my understanding on this patch. This change is closely related to ACPI cpufreq driver(used mostly on Intel cores). This change was introduced to keep track of the related cpus as returned by ACPI firmware along with affected cpus as imposed by SW. I don't understand the exact difference in Intel cores. I believe it's just for tracking and not used much in the driver. Regards, Sudeep ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq
On 10 October 2012 19:14, Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com wrote: Here is my understanding on this patch. This change is closely related to ACPI cpufreq driver(used mostly on Intel cores). This change was introduced to keep track of the related cpus as returned by ACPI firmware along with affected cpus as imposed by SW. I don't understand the exact difference in Intel cores. I believe it's just for tracking and not used much in the driver. Then i believe we shouldn't fill the related_cpus field for ARM cores. As anyway the show_related_cpus will pick affected cpus in that case. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Interesting(?) health failure
On 10/10/2012 08:56 AM, Andrey Konovalov wrote: Hi Dave, On 10/10/2012 11:35 AM, Dave Pigott wrote: Hi all, I found an interesting health failure today on origen07 http://validation.linaro.org/lava-server/scheduler/job/35016/log_file When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a reboot, which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job). I'm not sure we can trust anything that occurred in this job file after the deploy_linaro_image is finished with error. I think at this point the dispatcher is in an unknown state and doesn't know what it should be sending to the serial console. In this case, it still tried to do the boot_linaro_image action. However, we didn't successfully deploy an image, so anything going wrong there probably can't be trusted. I would have guessed it would have found the DTB file, but I'm not sure that's worth digging too far into. I think the real problem we see here is what you and I discussed on IRC earlier. There are certain actions in our job file, that if failed should be considered non-recoverable. ie: * if deploy_linaro_image fails, then boot_linaro_image can't run. * if boot_linaro_image fails, lava_test_install can't run * if lava_test_install fails - well that's tricky since it may have installed some of the test we need but not all. I'm wondering if we need to spend some time trying to improve how actions related to one other in code? What then started alarm bells ringing was that I saw this: 1261680 bytes read reading uInitrd 1532597 bytes read reading board.dtb ** Unable to read board.dtb from mmc 0:5 ** So whatever the test image was, it was expecting a device tree blob, which I would have assumed would have to have been installed during deploy_linaro_image() being that if there is one it should just be part of the test boot deployment. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
big.LITTLE MP status Oct 9, 2012
https://wiki.linaro.org/projects/big.LITTLE.MP Blueprint updates https://blueprints.launchpad.net/linaro-power-kernel/+spec/sched-cooperation-with-dvfs-and-idling - slow progress https://blueprints.launchpad.net/linaro-qa/+spec/task-placement-testing https://blueprints.launchpad.net/linaro-qa/+spec/sched-test-porting-to-android - Both still blocked due to the TC2 hardware not available to the QA engineer. https://blueprints.launchpad.net/linaro-qa/+spec/bl-agitator-simultaneous-switching - in progress https://blueprints.launchpad.net/linaro-qa/+spec/bl-hotplug-tests - Blocked on bL MP development work Roadmap Cards == No updates this week General Items == The agenda for the big.LITTLE mini summit at LCE has been posted: http://summit.linaro.org/lce12/2012-11-01/ Ryan has a fix for UEFI so that LAVA boards can be booted with cpufreq/cpuidle enabled. Work is being done to get this deployed on LAVA. Issues == The TC2 hardware is still not in the hands of the Linaro QA engineer, it is currently hung up in customs. Linaro is attempting to expedite delivery. Little progress since last week. Testing infrastructure deployment has been progressing and we anticipate testing to begin on both TC2 and RTSM platforms shortly. The issues holding up execution are bootwrapper support for RTSM and hardware delivery for TC2. The project plan is at https://docs.google.com/a/linaro.org/document/d/1XI9FaEd6dYfCEDezboF7gWtrTOmOrShUVoDOy1hr-5I/edit# -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ANN: people.linaro.org going down for 30 min, Thursday at 19:00UTC
Hi All, There's a scheduled downtime for 30 min, tomorrow (Thursday) at 19:00UTC. We plan to increase the disk space available on people.linaro.org. Thanks. Cheers, -- Fathi Boudra Linaro Release Manager | LAVA Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Interesting(?) health failure
Andy Doan andy.d...@linaro.org writes: On 10/10/2012 08:56 AM, Andrey Konovalov wrote: Hi Dave, On 10/10/2012 11:35 AM, Dave Pigott wrote: Hi all, I found an interesting health failure today on origen07 http://validation.linaro.org/lava-server/scheduler/job/35016/log_file When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a reboot, which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job). I'm not sure we can trust anything that occurred in this job file after the deploy_linaro_image is finished with error. I think at this point the dispatcher is in an unknown state and doesn't know what it should be sending to the serial console. In this case, it still tried to do the boot_linaro_image action. However, we didn't successfully deploy an image, so anything going wrong there probably can't be trusted. I would have guessed it would have found the DTB file, but I'm not sure that's worth digging too far into. I think the real problem we see here is what you and I discussed on IRC earlier. There are certain actions in our job file, that if failed should be considered non-recoverable. ie: * if deploy_linaro_image fails, then boot_linaro_image can't run. * if boot_linaro_image fails, lava_test_install can't run * if lava_test_install fails - well that's tricky since it may have installed some of the test we need but not all. I'm wondering if we need to spend some time trying to improve how actions related to one other in code? Yes please. I don't know if we want to do something generic, or just ensure deployment failures raise CriticalError -- which IIUC means no further actions will be attempted. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Interesting(?) health failure
On 10/10/2012 04:17 PM, Michael Hudson-Doyle wrote: Andy Doan andy.d...@linaro.org writes: On 10/10/2012 08:56 AM, Andrey Konovalov wrote: Hi Dave, On 10/10/2012 11:35 AM, Dave Pigott wrote: Hi all, I found an interesting health failure today on origen07 http://validation.linaro.org/lava-server/scheduler/job/35016/log_file When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a reboot, which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job). I'm not sure we can trust anything that occurred in this job file after the deploy_linaro_image is finished with error. I think at this point the dispatcher is in an unknown state and doesn't know what it should be sending to the serial console. In this case, it still tried to do the boot_linaro_image action. However, we didn't successfully deploy an image, so anything going wrong there probably can't be trusted. I would have guessed it would have found the DTB file, but I'm not sure that's worth digging too far into. I think the real problem we see here is what you and I discussed on IRC earlier. There are certain actions in our job file, that if failed should be considered non-recoverable. ie: * if deploy_linaro_image fails, then boot_linaro_image can't run. * if boot_linaro_image fails, lava_test_install can't run * if lava_test_install fails - well that's tricky since it may have installed some of the test we need but not all. I'm wondering if we need to spend some time trying to improve how actions related to one other in code? Yes please. I don't know if we want to do something generic, or just ensure deployment failures raise CriticalError -- which IIUC means no further actions will be attempted. CriticalError should at least fix the immediate problem. Dave - you wanna take a stab at that for now, and we can do something more elaborate in the future? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 4/4] cpuidle - sysfs : move declaration in the sysfs file
The structure cpuidle_state_kobj is not used anywhere except
in the sysfs.c file. The definition of this function is not
needed in the cpuidle header file.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
drivers/cpuidle/sysfs.c |7 +++
include/linux/cpuidle.h |7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index c25e26e..c756ba4 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -297,6 +297,13 @@ static struct attribute *cpuidle_state_default_attrs[] = {
NULL
};
+struct cpuidle_state_kobj {
+ struct cpuidle_state *state;
+ struct cpuidle_state_usage *state_usage;
+ struct completion kobj_unregister;
+ struct kobject kobj;
+};
+
#define kobj_to_state_obj(k) container_of(k, struct cpuidle_state_kobj, kobj)
#define kobj_to_state(k) (kobj_to_state_obj(k)-state)
#define kobj_to_state_usage(k) (kobj_to_state_obj(k)-state_usage)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 279b1ea..7daf0e3 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -82,13 +82,6 @@ cpuidle_set_statedata(struct cpuidle_state_usage *st_usage,
void *data)
st_usage-driver_data = data;
}
-struct cpuidle_state_kobj {
- struct cpuidle_state *state;
- struct cpuidle_state_usage *state_usage;
- struct completion kobj_unregister;
- struct kobject kobj;
-};
-
struct cpuidle_device {
unsigned intregistered:1;
unsigned intenabled:1;
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/4] cpuidle - sysfs : change function parameter
The function needs the cpuidle_device which is initially passed to the
caller.
The current code gets the struct device from the struct cpuidle_device,
pass it the cpuidle_add_sysfs function. This function calls
per_cpu(cpuidle_devices, cpu) to get the cpuidle_device.
This patch pass the cpuidle_device instead and simplify the code.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
drivers/cpuidle/cpuidle.c |8 +++-
drivers/cpuidle/cpuidle.h |6 ++
drivers/cpuidle/sysfs.c | 12 +++-
3 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index e28f6ea..07c6637 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -394,7 +394,6 @@ EXPORT_SYMBOL_GPL(cpuidle_disable_device);
static int __cpuidle_register_device(struct cpuidle_device *dev)
{
int ret;
- struct device *cpu_dev = get_cpu_device((unsigned long)dev-cpu);
struct cpuidle_driver *cpuidle_driver = cpuidle_get_driver();
if (!try_module_get(cpuidle_driver-owner))
@@ -404,7 +403,7 @@ static int __cpuidle_register_device(struct cpuidle_device
*dev)
per_cpu(cpuidle_devices, dev-cpu) = dev;
list_add(dev-device_list, cpuidle_detected_devices);
- ret = cpuidle_add_sysfs(cpu_dev);
+ ret = cpuidle_add_sysfs(dev);
if (ret)
goto err_sysfs;
@@ -416,7 +415,7 @@ static int __cpuidle_register_device(struct cpuidle_device
*dev)
return 0;
err_coupled:
- cpuidle_remove_sysfs(cpu_dev);
+ cpuidle_remove_sysfs(dev);
wait_for_completion(dev-kobj_unregister);
err_sysfs:
list_del(dev-device_list);
@@ -460,7 +459,6 @@ EXPORT_SYMBOL_GPL(cpuidle_register_device);
*/
void cpuidle_unregister_device(struct cpuidle_device *dev)
{
- struct device *cpu_dev = get_cpu_device((unsigned long)dev-cpu);
struct cpuidle_driver *cpuidle_driver = cpuidle_get_driver();
if (dev-registered == 0)
@@ -470,7 +468,7 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
cpuidle_disable_device(dev);
- cpuidle_remove_sysfs(cpu_dev);
+ cpuidle_remove_sysfs(dev);
list_del(dev-device_list);
wait_for_completion(dev-kobj_unregister);
per_cpu(cpuidle_devices, dev-cpu) = NULL;
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index 76e7f69..a5bbd1c 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -5,8 +5,6 @@
#ifndef __DRIVER_CPUIDLE_H
#define __DRIVER_CPUIDLE_H
-#include linux/device.h
-
/* For internal use only */
extern struct cpuidle_governor *cpuidle_curr_governor;
extern struct list_head cpuidle_governors;
@@ -29,8 +27,8 @@ extern int cpuidle_add_interface(struct device *dev);
extern void cpuidle_remove_interface(struct device *dev);
extern int cpuidle_add_state_sysfs(struct cpuidle_device *device);
extern void cpuidle_remove_state_sysfs(struct cpuidle_device *device);
-extern int cpuidle_add_sysfs(struct device *dev);
-extern void cpuidle_remove_sysfs(struct device *dev);
+extern int cpuidle_add_sysfs(struct cpuidle_device *dev);
+extern void cpuidle_remove_sysfs(struct cpuidle_device *dev);
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 5f809e3..84e6285 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -408,13 +408,11 @@ void cpuidle_remove_state_sysfs(struct cpuidle_device
*device)
* cpuidle_add_sysfs - creates a sysfs instance for the target device
* @dev: the target device
*/
-int cpuidle_add_sysfs(struct device *cpu_dev)
+int cpuidle_add_sysfs(struct cpuidle_device *dev)
{
- int cpu = cpu_dev-id;
- struct cpuidle_device *dev;
+ struct device *cpu_dev = get_cpu_device((unsigned long)dev-cpu);
int error;
- dev = per_cpu(cpuidle_devices, cpu);
error = kobject_init_and_add(dev-kobj, ktype_cpuidle, cpu_dev-kobj,
cpuidle);
if (!error)
@@ -426,11 +424,7 @@ int cpuidle_add_sysfs(struct device *cpu_dev)
* cpuidle_remove_sysfs - deletes a sysfs instance on the target device
* @dev: the target device
*/
-void cpuidle_remove_sysfs(struct device *cpu_dev)
+void cpuidle_remove_sysfs(struct cpuidle_device *dev)
{
- int cpu = cpu_dev-id;
- struct cpuidle_device *dev;
-
- dev = per_cpu(cpuidle_devices, cpu);
kobject_put(dev-kobj);
}
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/4] cpuidle - sysfs : move kobj initialization in the syfs file
Move the kobj initialization and completion in the sysfs.c
and encapsulate the code more.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
drivers/cpuidle/cpuidle.c |4
drivers/cpuidle/sysfs.c |7 +--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 07c6637..7cf8388 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -399,8 +399,6 @@ static int __cpuidle_register_device(struct cpuidle_device
*dev)
if (!try_module_get(cpuidle_driver-owner))
return -EINVAL;
- init_completion(dev-kobj_unregister);
-
per_cpu(cpuidle_devices, dev-cpu) = dev;
list_add(dev-device_list, cpuidle_detected_devices);
ret = cpuidle_add_sysfs(dev);
@@ -416,7 +414,6 @@ static int __cpuidle_register_device(struct cpuidle_device
*dev)
err_coupled:
cpuidle_remove_sysfs(dev);
- wait_for_completion(dev-kobj_unregister);
err_sysfs:
list_del(dev-device_list);
per_cpu(cpuidle_devices, dev-cpu) = NULL;
@@ -470,7 +467,6 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
cpuidle_remove_sysfs(dev);
list_del(dev-device_list);
- wait_for_completion(dev-kobj_unregister);
per_cpu(cpuidle_devices, dev-cpu) = NULL;
cpuidle_coupled_unregister_device(dev);
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 84e6285..ed87399 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -374,8 +374,8 @@ int cpuidle_add_state_sysfs(struct cpuidle_device *device)
kobj-state_usage = device-states_usage[i];
init_completion(kobj-kobj_unregister);
- ret = kobject_init_and_add(kobj-kobj, ktype_state_cpuidle,
device-kobj,
- state%d, i);
+ ret = kobject_init_and_add(kobj-kobj, ktype_state_cpuidle,
+ device-kobj, state%d, i);
if (ret) {
kfree(kobj);
goto error_state;
@@ -413,6 +413,8 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
struct device *cpu_dev = get_cpu_device((unsigned long)dev-cpu);
int error;
+ init_completion(dev-kobj_unregister);
+
error = kobject_init_and_add(dev-kobj, ktype_cpuidle, cpu_dev-kobj,
cpuidle);
if (!error)
@@ -427,4 +429,5 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
void cpuidle_remove_sysfs(struct cpuidle_device *dev)
{
kobject_put(dev-kobj);
+ wait_for_completion(dev-kobj_unregister);
}
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 1/3] devfreq: Core updates to support devices which can idle
On Wednesday 10 of October 2012 12:49:33 Rajagopal Venkat wrote: On 8 October 2012 13:44, MyungJoo Ham myungjoo@samsung.com wrote: Prepare devfreq core framework to support devices which can idle. When device idleness is detected perhaps through runtime-pm, need some mechanism to suspend devfreq load monitoring and resume back when device is online. Present code continues monitoring unless device is removed from devfreq core. This patch introduces following design changes, - use per device work instead of global work to monitor device load. This enables suspend/resume of device devfreq and reduces monitoring code complexity. - decouple delayed work based load monitoring logic from core by introducing helpers functions to be used by governors. This provides flexibility for governors either to use delayed work based monitoring functions or to implement their own mechanism. - devfreq core interacts with governors via events to perform specific actions. These events include start/stop devfreq. This sets ground for adding suspend/resume events. The devfreq apis are not modified and are kept intact. Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org Thank you! Reviewed and Tested (at Exynos4210-Nuri). Acked-by: MyungJoo Ham myungjoo@samsung.com Rafael, Can this patchset be queued for v3.7? No, but it can be queued for v3.8. I'll do that tomorrow, if time permits. All non-fix things I'd had queued up for v3.7 were merged already. Thanks, Rafael --- Documentation/ABI/testing/sysfs-class-devfreq | 8 - drivers/devfreq/devfreq.c | 443 +++--- drivers/devfreq/governor.h| 11 + drivers/devfreq/governor_performance.c| 16 +- drivers/devfreq/governor_powersave.c | 16 +- drivers/devfreq/governor_simpleondemand.c | 24 ++ drivers/devfreq/governor_userspace.c | 23 +- include/linux/devfreq.h | 34 +- 8 files changed, 279 insertions(+), 296 deletions(-) -- 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
