Re: [GIT PULL] cpufreq-interactive-gov-master-v1
On 12/19/2012 06:05 PM, Viresh Kumar wrote: On 5 December 2012 09:55, John Stultz wrote: So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like). Hi John, There are few updates of interactive governor available in AOSP 3.4 branch. Can you please include them? Sure thing, just merged them in and pushed them out. Let me know if you notice anything missing. thanks! -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] cpufreq-interactive-gov-master-v1
On 5 December 2012 09:55, John Stultz wrote: > So while I can try to update the linaro-android tree more frequently, > maintaining that tree is more of a background task. So when my other > commitments consume my attention, sometimes that update frequency is slower. > Also, given we're already 3 releases beyond the AOSP tree, keeping the two > branches in perfect sync is unlikely to happen (due to the higher chance of > collisions). So if folks notice there is some critical functionality that > is updated in the AOSP tree, when they let me know, I can be sure to merge > it in (like was done with this case - albeit slower then I'd like). Hi John, There are few updates of interactive governor available in AOSP 3.4 branch. Can you please include them? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: interactive: fix racy timer stopping
On Tue, Dec 18, 2012 at 8:46 PM, Nicolas Pitre wrote: > On Tue, 18 Dec 2012, Todd Poynor wrote: > >> I put this up on AOSP Gerrit at >> https://android-review.googlesource.com/#/c/48233/ with a minor change >> to the semaphore field name to be more descriptive and to identify it >> as a semaphore. >> >> After some out-of-band discussion it was agreed the race with the idle >> notifier definitely exists, but the race described with the timer >> function is unclear. As I understand it, del_timer_sync() spins >> waiting for the timer to stop running (and possibly rescheduling >> itself) and then deletes the timer. When try_to_del_timer_sync() >> returns successfully "the timer is not queued and the handler is not >> running on any CPU". Is there still a race here anyway? > > After re-reading the code, I do agree. > > What confused me is this comment for del_timer_sync(): > > * Synchronization rules: Callers must prevent restarting of the timer, > * otherwise this function is meaningless. It must not be called from > * interrupt contexts unless the timer is an irqsafe one. The caller must > * not hold locks which would prevent completion of the timer's > * handler. The timer's handler must not call add_timer_on(). [...] > > However, the timer handler is using mod_timer_pinned(), not > add_timer_on(). > > I stumbled upon the idle notifier race first, and initially my > understanding of the timer code wasn't very clear. I used the timer > self scheduling scenario to illustrate the race instead of the idle > notifier simply because it was simpler. OK, I'll fix up the commit description. Thanks -- Todd > > > Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
big.LITTLE MP status will resume in January
Development for big.LITTLE MP continues in a strong way, however as our efforts for big.LITTLE IKS ramp up to delivery, process and project management will focus on that project until the end of the year. As such, the next big.LITTLE MP status will be sent out in January. I will be happy to respond to any questions related to big.LITTLE MP through the normal channels. Apologies and thanks for your patience. -- David Zinman, 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: [RFC] bootwrapper: Add support for the TC1 and TC2 CoreTiles
On Tue, Dec 18, 2012 at 04:42:08PM +, Alexander Spyridakis wrote: > On 18 December 2012 12:10, Liviu Dudau > mailto:liviu.du...@arm.com>> wrote: > Hi Alexander, > > Could you explain with a bit more detail what's the intended usage > scenario for this code? > > If you have BootMonitor, it is already capable of booting the kernel. > > The major difference is that BootMonitor doesn't initialize Hyp mode and > without it we can't start KVM. > > Initially (back in the TC1 era), I tried to run linux-system.axf as is, but > BootMonitor wasn't (and still isn't I think) able to execute elf files with > multiple program headers. The solution for me at the time was to load the > kernel image separately and run a simplified version of the bootwrapper. Of > course this would only work for CPU0 as the rest of the cores are already set > to sleep by BootMonitor (contrary to FastModels). > > This patch tries to unify usage of the bootwrapper for both FastModels and > the Versatile Express board, without being intrusive to the FastModels code > path. Actually any changes to boot.S are bound for the board binary only. > > Regards. Hi Alexander, Thanks for the explanation. As for having an unified boot process, using UEFI it's more likely to lead to that rather than waiting on BootMon to support HYP mode. Regards, Liviu > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] Powertop: Fix script for android
On 19 December 2012 16:03, Chander Kashyap wrote:
> Following issues fixed:
> 1. Name of generated rcport file is powertop*.csv not PowerTop*.csv
> 2. sudo not available in android so dropped it.
> 3. ls -1 not supported in android ls command so changed it to plain ls.
>
> Signed-off-by: Chander Kashyap
> ---
> powertop/powertop_01.sh |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/powertop/powertop_01.sh b/powertop/powertop_01.sh
> index cf243f1..d2e78f2 100755
> --- a/powertop/powertop_01.sh
> +++ b/powertop/powertop_01.sh
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/bas
typo
> #
> # PM-QA validation test suite for the power management on Linux
> #
> @@ -33,14 +33,14 @@ run_powertop() {
> local report=csv
> local seconds=10
> local iterations=2
> -local report_name=PowerTOP*.csv
> +local report_name=powertop*.csv
>
> # remove old reports if exists
> rm -f $report_name
>
> # run powertop for $(iterations) in report generation mode
> start_time=`date +%s`
> -sudo $bin_path --$report --time=$seconds --iteration=$iterations
> +$bin_path --$report --time=$seconds --iteration=$iterations
> end_time=`date +%s`
>
> # check if powertop run for desired time
> @@ -50,7 +50,7 @@ run_powertop() {
> check "if powertop run for $expected_time sec" "test $actual_time -ge
> $expected_time"
>
> # check if $(iterations) number of reports are generated
> -check "if reports are generated" "test $(ls -1 $report_name | wc -l) -eq
> $iterations"
> +check "if reports are generated" "test $(ls $report_name | wc -l) -eq
> $iterations"
>
> return 0
> }
> --
> 1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] Powertop: Fix script for android
Following issues fixed:
1. Name of generated rcport file is powertop*.csv not PowerTop*.csv
2. sudo not available in android so dropped it.
3. ls -1 not supported in android ls command so changed it to plain ls.
Signed-off-by: Chander Kashyap
---
powertop/powertop_01.sh |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/powertop/powertop_01.sh b/powertop/powertop_01.sh
index cf243f1..d2e78f2 100755
--- a/powertop/powertop_01.sh
+++ b/powertop/powertop_01.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/bas
#
# PM-QA validation test suite for the power management on Linux
#
@@ -33,14 +33,14 @@ run_powertop() {
local report=csv
local seconds=10
local iterations=2
-local report_name=PowerTOP*.csv
+local report_name=powertop*.csv
# remove old reports if exists
rm -f $report_name
# run powertop for $(iterations) in report generation mode
start_time=`date +%s`
-sudo $bin_path --$report --time=$seconds --iteration=$iterations
+$bin_path --$report --time=$seconds --iteration=$iterations
end_time=`date +%s`
# check if powertop run for desired time
@@ -50,7 +50,7 @@ run_powertop() {
check "if powertop run for $expected_time sec" "test $actual_time -ge
$expected_time"
# check if $(iterations) number of reports are generated
-check "if reports are generated" "test $(ls -1 $report_name | wc -l) -eq
$iterations"
+check "if reports are generated" "test $(ls $report_name | wc -l) -eq
$iterations"
return 0
}
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
int64_t definition conflict on Aarch64
Hi,
The following code fails to build with OE Aarch64 toolchain with
current kernel headers. While ugly, the code is a reduced testcase
from fuse build failure (
https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse
code compiles on all other architectures. Before I send a workaround
for upstream, I'd like to know how we can end up with different
definitions for int64_t when that happens on no other architectures -
something wrong with the generic kernel headers?
Testcase:
#include
#define __s64 int64_t
#include
int main(int argc, char **argv)
{
int64_t x=4;
return x;
}
Failure:
/data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/aarch64-oe-linux/aarch64-oe-linux-gcc
-save-temps --sysroot=/data/oe/build/tmp-eglibc/sysroots/genericarmv8
-o test test.c
In file included from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/types.h:7:0,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/types.h:1,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/linux/types.h:4,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/sigcontext.h:19,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/bits/sigcontext.h:27,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/signal.h:338,
from test.c:4:
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/int-ll64.h:29:44:
error: conflicting types for 'int64_t'
In file included from test.c:2:0:
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/sys/types.h:197:13:
note: previous declaration of 'int64_t' was here
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: HMP patches v2
On 19/12/12 09:34, Viresh Kumar wrote: On 19 December 2012 14:53, Vincent Guittot wrote: Le 19 déc. 2012 07:34, "Viresh Kumar" a écrit : Can we resolve this issue now? I don't want anything during the release period this time. The new version of the patchset should solve the concerns of everybody Morten, Can you confirm or cross-check that? Branch is: sched-pack-small-tasks-v2 If I understand the new version of "sched: secure access to other CPU statistics" correctly, the effect of the patch is: Without the patch the cpu will appear to be busy if sum/period are not coherent (sum>period). The same is true with the patch except in the case where nr_running is 0. In this particular case the cpu will appear not to be busy. I assume there is good reason why this particular case is important? In any case the patch is fine by me. Morten -- 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: HMP patches v2
On 19 December 2012 14:53, Vincent Guittot wrote: > Le 19 déc. 2012 07:34, "Viresh Kumar" a écrit : >> Can we resolve this issue now? I don't want anything during the release >> period >> this time. > > The new version of the patchset should solve the concerns of everybody Morten, Can you confirm or cross-check that? Branch is: sched-pack-small-tasks-v2 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
HMP patches v2
Le 19 déc. 2012 07:34, "Viresh Kumar" a écrit : > > Morten/Vincent, > > On 6 December 2012 20:06, Viresh Kumar wrote: > > First of all i must admit, i haven't followed the discussion closely, as this > > part of kernel is still rocket science for me :) > > > > Secondly, what you said is correct Amit. But, i must say there has been a > > long time since the last time release happened and all this must have > > been sorted out in that time both from Linaro and ARM side. And i didn't > > saw any effort on that. Only when i came back to sort out issues in my > > tree, this issue is still highlighted. > > > > Now, getting so close to release and making a big change, that will eventually > > affect the core part we are working on is not a great idea. > > > > But we still have some time for a meaningful discussion to happen and > > one party to agree. Both can't be correct. I need to send the pull request > > by Monday and so whatever is required to be done, must be done by tomorrow > > Can we resolve this issue now? I don't want anything during the release period > this time. The new version of the patchset should solve the concerns of everybody > > -- > viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
