Android Build Downtime
Hello everyone, the Infrastructure team is going to perform a small update of Android Build frontend today at 12UTC. The deployment shouldn't take more than 10 minutes. Only the frontend will be affected. If the downtime will cause you significant problems, please get in touch with us. Thanks. -- Milo Casagrande Infrastructure Engineer 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: HMP patches v2
On Wed, Dec 05, 2012 at 05:27:53AM +, Viresh Kumar wrote: > On 17 November 2012 00:02, Liviu Dudau wrote: > > Here are the latest patches for HMP tunables to be included in the MP > > branch for the 12.11 > > release. They depend on Vincent Guittot's patches that you have on -exp-v12 > > branch which > > we need included in the PULL request. Testing shows that they improve power > > consumption for HMP. > > Hi Liviu, > > There are two branches present currently for sched-pack-small-task: > - sched-pack-small-tasks-v1-fixed: Original one from Vincent + 2 fixes > - sched-pack-small-tasks-v1-arm: One fix reverted for now + patches from >this mail thread. > > I don't really want to keep the fix from Vincent reverted. Can we please test > again, the -fixed branch, and check which patches are still required ? > > -- > viresh > Hi Viresh, The revert request came at Morten's suggestion. He has comments on the code and technical reasons why he believes that the approach is not the best one as well as some scenarios where possible race conditions can occur. Morten, what is the latest update in this area. I'm not sure I have followed your discussion with Vincent on the subject. Regards, Liviu -- | 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: HMP patches v2
On 5 December 2012 16:28, Liviu Dudau wrote: > The revert request came at Morten's suggestion. He has comments on the code > and technical reasons > why he believes that the approach is not the best one as well as some > scenarios where possible race > conditions can occur. > > Morten, what is the latest update in this area. I'm not sure I have followed > your discussion with > Vincent on the subject. Just to make it more clear.. There are two reverts now. Please look at the latest tree/branches. Vincent has provided another fixup patch after which he commented we no longer need Mortens fix. I have reverted that too, for the moment to keep things same as the last release. Can Morten test with latest patches from Vincent (from his branch) ? And provide fixups again ? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
New layout for OpenEmbedded layers
Hello Now at Linaro we have two layers for our OpenEmbedded work: - meta-aarch64 - meta-linaro First one contains everything we need to get AArch64 booted in fastmodels: toolchain, kernel and few recipes which needed changes to build for AArch64. I am working on merging those changes into main OpenEmbedded layers. Second one is gcc-linaro from Toolchain WG and some recipes and changes from Platform team. Those who do OE builds with our toolchain have some components changed due to our metadata (like Busybox with dpkg-deb) and I decided to fix it. Today I pushed "new-layout" branch of meta-linaro repository. It contains all Linaro layers: - meta-aarch64 - meta-linaro - meta-linaro-toolchain First one was merged from meta-aarch64 repository and moved to own directory. Third one contains only toolchain bits. Second one has all that left. I have to do some test builds with this layout and once they will confirm that it works I will change all CI builds. This will also deprecate meta-aarch64 repository - it will not have any updates and will be dropped in ~month. Opinions? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: HMP patches v2
On 05/12/12 11:01, Viresh Kumar wrote:
On 5 December 2012 16:28, Liviu Dudau wrote:
The revert request came at Morten's suggestion. He has comments on the code and
technical reasons
why he believes that the approach is not the best one as well as some scenarios
where possible race
conditions can occur.
Morten, what is the latest update in this area. I'm not sure I have followed
your discussion with
Vincent on the subject.
Just to make it more clear.. There are two reverts now. Please look
at the latest tree/branches. Vincent has provided another fixup patch
after which he commented we no longer need Mortens fix.
I have reverted that too, for the moment to keep things same as the
last release. Can Morten test with latest patches from Vincent (from his
branch) ? And provide fixups again ?
Hi,
I tested Vincent's fix ("sched: pack small tasks: fix update packing
domain") for the buddy selection some weeks ago and confirmed that it
works. So my quick fixes are no longer necessary.
The issues around the reverted "sched: secure access to other CPU
statistics" have not yet been resolved. I don't think that we should
re-enable it until we are clear about what it is doing.
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 5 December 2012 16:58, Morten Rasmussen wrote:
> I tested Vincent's fix ("sched: pack small tasks: fix update packing
> domain") for the buddy selection some weeks ago and confirmed that it
> works. So my quick fixes are no longer necessary.
>
> The issues around the reverted "sched: secure access to other CPU
> statistics" have not yet been resolved. I don't think that we should
> re-enable it until we are clear about what it is doing.
There are four patches i am carrying from ARM
4a29297 ARM: TC2: Re-enable SD_SHARE_POWERLINE
a1924a4 sched: SD_SHARE_POWERLINE buddy selection fix
39b0e77 Revert "sched: secure access to other CPU statistics"
eed72c8 Revert "sched: pack small tasks: fix update packing domain"
You want me to drop eed72c8 and a1924a4 ? Correct.
--
viresh
___
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
05.12.2012 08:32, Viresh Kumar пишет: 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). That might be enough, i suppose. Are you saying that cpufreq-interactive-gov would not be needed in this case? Thus excluding the case when someone wants the interactive governor, but without the rest of the android code. (I thought it was one of the reasons to have a separate cpufreq-interactive-gov topic vs more frequent updates to the existing android topic) However, if you're maintaining your own tree anyway, why not have Andrey pull your tree in addition to the current linaro-android-3.x-*rebase branch? Since they are both contain a common subset, the merge will likely be quite easy. Not quite right. At least the android topic is the rebase, so these topics are quite different from git's perspective. I've tried merging Viresh's topic into llct containing the Anton's version of the android topic. There were 2 conflicting files. One file was 3 commits ahead of the llct, and it would be much more easier to cherry pick those commits into llct than trying to associate the combined diff with the 3 commits. As for the 2nd file, it was just one additional commit in the Viresh's branch, but it wasn't the topmost commit in that branch for some reason. That is such merge needs some manual work, and I don't feel comfortable doing such merges w/o good knowledge of android or the governor at least. Also there may be conflict resolutions or fixes done when creating or updating the android topic, and they can be omitted by occasion when merging cpufreq-interactive-gov-master into llct. The things would be pretty trivial, if cpufreq-interactive-gov-master were based on the android topic. But cpufreq-interactive-gov-master is intended to be used without the android topic as well, right? This means outside the linux-linaro kernel trees btw. That way Andrey's tree will have a better chance of having the latest changes. Does that seem ok? That was the initial idea, but there were concerns from Tixy and Andrey on that. @Andrey: Do you want to comment again? imho the conflicts when merging cpufreq-interactive-gov-master into llct require interactive governor tests in the CI loop. Especially if we want cpufreq-interactive-gov-master to be updated frequently. How difficult would it be to maintain a special version of the cpufreq-interactive-gov topic for llct: cpufreq-interactive-gov-master rebased onto the most recent android topic? E.g. cpufreq-interactive-gov-linux-linaro? Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: HMP patches v2
On 05/12/12 11:35, Viresh Kumar wrote:
On 5 December 2012 16:58, Morten Rasmussen wrote:
I tested Vincent's fix ("sched: pack small tasks: fix update packing
domain") for the buddy selection some weeks ago and confirmed that it
works. So my quick fixes are no longer necessary.
The issues around the reverted "sched: secure access to other CPU
statistics" have not yet been resolved. I don't think that we should
re-enable it until we are clear about what it is doing.
There are four patches i am carrying from ARM
4a29297 ARM: TC2: Re-enable SD_SHARE_POWERLINE
a1924a4 sched: SD_SHARE_POWERLINE buddy selection fix
39b0e77 Revert "sched: secure access to other CPU statistics"
eed72c8 Revert "sched: pack small tasks: fix update packing domain"
You want me to drop eed72c8 and a1924a4 ? Correct.
Yes.
Morten
--
viresh
-- 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: [GIT PULL] cpufreq-interactive-gov-master-v1
On 5 December 2012 17:09, Andrey Konovalov wrote: > Are you saying that cpufreq-interactive-gov would not be needed in this > case? Thus excluding the case when someone wants the interactive governor, > but without the rest of the android code. (I thought it was one of the > reasons to have a separate cpufreq-interactive-gov topic vs more frequent > updates to the existing android topic) We wanted it for ubuntu and Android. And when we use linux-linaro release, we have android code built into the kernel. So, we don't really need these patches for something else, Unless somebody is using an older version of linux-linaro release, and in that case he must update his stuff manually. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: HMP patches v2
On 5 December 2012 17:10, Morten Rasmussen wrote: >> You want me to drop eed72c8 and a1924a4 ? Correct. > > Yes. Done. Updated my repo with v13. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bisected regression: mmc: omap_hsmmc: remove private DMA API implementation prevents Pandaboard ES to boot
Hi, On 12/04/2012 05:51 PM, Andy Green wrote: On 05/12/12 08:51, the mail apparently from Juri Lelli included: Hi all, in the process of testing scheduler patches on a Pandaboard ES, I found a possible regression regarding OMAP mmc. The system is a Pandaboard ES (OMAP4460 ES1.1) running Linaro 12.10 (GNU/Linux 3.4.0-2-linaro-lt-omap armv7l). The problem is that the system remains stuck at boot time trying to mount the root device. This is what I got via git bisect from Linux 3.5 and Linux 3.7-rc7: 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 is the first bad commit commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 Author: Russell King Date: Fri Apr 13 12:27:37 2012 +0100 mmc: omap_hsmmc: remove private DMA API implementation Remove the private DMA API implementation from omap_hsmmc, making it use entirely the DMA engine API. Tested-by: Tony Lindgren Tested-by: Venkatraman S Signed-off-by: Russell King :04 04 03cff4d68cc92ea652ef8e0c6ac74af804bc9f00 a9763c6b364bfc66b5fcd4cada7315befcbd62e8 Mdrivers Here instead the two boot traces, before (all OK) and after the bad commit. Hi - I'd suggest some caution pointing the finger on that one. We experienced a similar problem earlier in the year bringing up OMAP5 chips, there is a race somewhere that gives these symptoms we were unable to pin down despite spending a lot of time on it. Yes, I wasn't blaming anyone, just telling that something changed for me at that point in the way my board boots (or not :). Changing the configuration according to what Robert Nelson suggested solves the problem. BTW, do you think writing down this experience somewhere (Linaro wiki?) would help other people? Thank you both for your help. Best Regards, - Juri ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH v1] Allow frequency stats when cpuidle is not enabled
On (12/04/12 11:37), Rajagopal Venkat wrote:
> Powertop fails to display frequency stats when cpuidle subsystem
> is not enabled. Fix it.
>
> Signed-off-by: Rajagopal Venkat
> ---
looks good to me, thanks.
-ss
> src/cpu/cpu.h | 7 ++-
> src/cpu/cpu_linux.cpp | 36 +++-
> 2 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h
> index 4480b11..781e33c 100644
> --- a/src/cpu/cpu.h
> +++ b/src/cpu/cpu.h
> @@ -159,7 +159,12 @@ extern vector all_cpus;
> class cpu_linux: public abstract_cpu
> {
>
> - voidaccount_freq(uint64_t frequency, uint64_t duration);
> + voidaccount_freq(uint64_t frequency, uint64_t duration);
> + voidparse_pstates_start(void);
> + voidparse_cstates_start(void);
> + voidparse_pstates_end(void);
> + voidparse_cstates_end(void);
> +
> public:
> virtual voidmeasurement_start(void);
> virtual voidmeasurement_end(void);
> diff --git a/src/cpu/cpu_linux.cpp b/src/cpu/cpu_linux.cpp
> index d6caf45..e7a3d37 100644
> --- a/src/cpu/cpu_linux.cpp
> +++ b/src/cpu/cpu_linux.cpp
> @@ -47,17 +47,13 @@ static int is_turbo(uint64_t freq, uint64_t max, uint64_t
> maxmo)
> return 1;
> }
>
> -void cpu_linux::measurement_start(void)
> +void cpu_linux::parse_cstates_start(void)
> {
> ifstream file;
> -
> DIR *dir;
> struct dirent *entry;
> char filename[256];
> int len;
> - unsigned int i;
> -
> - abstract_cpu::measurement_start();
>
> len = sprintf(filename, "/sys/devices/system/cpu/cpu%i/cpuidle",
> number);
>
> @@ -111,9 +107,16 @@ void cpu_linux::measurement_start(void)
>
> }
> closedir(dir);
> +}
>
> - last_stamp = 0;
>
> +void cpu_linux::parse_pstates_start(void)
> +{
> + ifstream file;
> + char filename[256];
> + unsigned int i;
> +
> + last_stamp = 0;
> for (i = 0; i < children.size(); i++)
> if (children[i])
> children[i]->wiggle();
> @@ -136,8 +139,14 @@ void cpu_linux::measurement_start(void)
> account_freq(0, 0);
> }
>
> +void cpu_linux::measurement_start(void)
> +{
> + abstract_cpu::measurement_start();
> + parse_cstates_start();
> + parse_pstates_start();
> +}
>
> -void cpu_linux::measurement_end(void)
> +void cpu_linux::parse_cstates_end(void)
> {
> DIR *dir;
> struct dirent *entry;
> @@ -187,6 +196,12 @@ void cpu_linux::measurement_end(void)
>
> }
> closedir(dir);
> +}
> +
> +void cpu_linux::parse_pstates_end(void)
> +{
> + char filename[256];
> + ifstream file;
>
> sprintf(filename,
> "/sys/devices/system/cpu/cpu%i/cpufreq/stats/time_in_state", number);
>
> @@ -216,12 +231,15 @@ void cpu_linux::measurement_end(void)
> }
> file.close();
> }
> +}
>
> -
> +void cpu_linux::measurement_end(void)
> +{
> + parse_cstates_end();
> + parse_pstates_end();
> abstract_cpu::measurement_end();
> }
>
> -
> char * cpu_linux::fill_cstate_line(int line_nr, char *buffer, const char
> *separator)
> {
> unsigned int i;
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
