linaro-dev November 2011

linaro-dev@lists.linaro.org

122 participants
130 discussions

[ACTIVITY] Multimedia WG weekly status report - wk46.2011 (20111107-20111111)

by Ilias Biris

Detailed status report - with working links: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Week 46 meeting notes: = Highlights = - Speex is back in the radar following requests coming from Android to provide a NEON optimised version. Deliverables arranged for 11.11 and 11.12. - libpng: NEON auto detection is now implemented at a local patch which will go into the Ubuntu LEB for 11.11. - libjpeg-turbo: moving forward with the actions at Connect. The first list of actions are reflected in the blueprints targeted for 11.11, such as updating libjpeg-turbo packaging to include libjpeg8 support, and collecting tjbench performance information - Alsa UCM for PA: the work aims to provide a more natural natural fit of alsa UCM concepts to Pulseaudio core concepts. The work continued post-LC with a look at the contributed upstream patches (intel-origin) which seem to be partly driven from a need to handle policy and also partly originating at the jack detection discussion and patches upstream. The investigation there is ongoing, but a list of findings are put together in the MMWG UCM for PA analysis page. But at least for 11.11 a release containing the patches Wei has been putting together which do the mapping in a more PA agreeable way will be made available. - UCM for Android phase 1 has started and will be hopefully at a good shape for the 11.12 release - End2End testing: the basic case of end2end testing for audio will be ready for 11.12 - From UMM side: + Debug and tracing patch for CMA has been contributed thread on linaro-mm-sig) + Following the dri2video on xf86-video-nouveau reference implementation for dri2video effectively employing the UMM work that has been going on. Most of the dri2video stuff is implemented plus a simple test app in libdri2. The nouveau reference prototype seems to have reached a good point to allow sending patches after some cleanup. This will be officially ready during 11.12 Questions, comments, other feedback are welcome. -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 10 months

Linaro Kernel November 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our October 2011 development snapshot: linux-linaro-3.1-2011.11-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/linux-linaro-3.… The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.11-0 This kernel includes the following changes from the 2011.10 kernel: - The v3.1.1 stable kernel - LPAE support from Catalin Marinas - Samsung cpuidle work from Amit Kachhap - sched_mc optimization from Vincent Guittot - Fix for mmap greater than 2GB from Rob Herring A full change log against the 2011.09 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/CHANGELOG-linux… High Priority Known Issues: - None at this time This month's release is about a week early due to the upcoming Thanksgiving holidays in the US. If we find any major issues in the next few days, we will spin a new tarball. Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 10 months

important oneiric daily snapshot change

by Tom Gall

Hi All, As a result of bug https://bugs.launchpad.net/linaro-ubuntu/+bug/890185, it was decided to enable a default password on images going forward. The released snapshots now use the password "linaro" for the linaro account. Auto login behavior for the serial cons as well as the graphical cons via lightdm for those images that use it should be otherwise unchanged. -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 10 months

Re: [android-building] Re: ICS is coming to AOSP

by Zach Pfeffer

On 14 November 2011 20:01, Jean-Baptiste Queru <jbq(a)android.com> wrote: > I've just pushed the source for the PandaBoard kernel: branch > android-omap-panda-3.0 in the kernel/omap project. I expect that's the > one you might be most interested in since it can be run on hardware > right away. Thanks! > Maguro (i.e. Galaxy Nexus) is next on my list. > > JBQ > > On Mon, Nov 14, 2011 at 5:20 PM, Ezekeel <notezekeel(a)googlemail.com> wrote: >> Thank you very much. Sadly there are some companies out there that do not >> take the GPL seriously and release the source whenever they see fit (which >> might be never). Fortunately judging from previous experience Google is not >> one of them. >> I am just really excited about having a new kernel to toy around with and >> with the sources released I can start porting my kernel for ICS. >> >> -- >> You received this message because you are subscribed to the "Android >> Building" mailing list. >> To post to this group, send email to android-building(a)googlegroups.com >> To unsubscribe from this group, send email to >> android-building+unsubscribe(a)googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-building?hl=en >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Software Engineer, Android Open-Source Project, Google. > > Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning. > > -- > You received this message because you are subscribed to the "Android Building" mailing list. > To post to this group, send email to android-building(a)googlegroups.com > To unsubscribe from this group, send email to > android-building+unsubscribe(a)googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-building?hl=en > -- 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

13 years, 10 months

dependencies between actions in the dispatcher

by Michael Hudson-Doyle

Recently I've been thinking about the dispatcher a bit (as other mails should have indicated) and I've gotten to think about dependencies between actions. If you don't already know, a dispatcher job file mostly consists of a list of actions to execute, for example: "actions": [ { "command": "deploy_linaro_image", "parameters": {"rootfs": "...", "hwpack": "..."} }, { "command": "lava_test_install", "parameters": {"tests": ["stream", "ltp"]} }, { "command": "boot_linaro_image" }, { "command": "lava_test_run", "parameters": {"test_name": "stream"} }, { "command": "lava_test_run", "parameters": {"test_name": "ltp"} }, { "command": "submit_results", "parameters": { "server": "http://localhost/lava-server/RPC2/", "stream": "/anonymous/test/" } } ] I hope what the actions do is reasonably clear from their names. What is easy-ish for us, but probably rather harder for a computer program to do is to see the data dependencies between the different actions. boot_linaro_image makes no sense if deploy_linaro_image failed. Running tests with lava_test_run doesn't make sense if the test failed to install (or if boot_linaro_image failed). But the lava_test_run's are independent, even if the stream test hangs we could still run the ltp tests. And we should always submit the results, that's a kind of special case (and I'm not sure submit results should really be an action). It seems like the way we (aim to, at least) handle this isn't too bad: basically any action can veto the running of any more actions (apart from the special case of submit_results). But there's more than control flow going on here -- there is data flow too. The reason I'm writing this mail is that I'm working on testing images in qemu[1]. If we want to use a similar layout of the job files (and I think using the same commands even will be possible), then we'll have an action that builds an image and another that starts up qemu. The action that starts up qemu needs to know where the previous action is! And of course I've been a bit sneaky here, because there's another, very important kind of data that needs to move around: the test results. Currently we assume that all the test results end up in a particular directory (either on the device (for ubuntu-based tests) or on the host (android-based tests)). This feels a bit grotty to me, and will need to change for tests run under qemu and possibly for the multi-system tests that were discussed at the connect. There is an object in the dispatcher -- the context -- that encapsulates the state that persists through the run, so this is probably where the data should live -- we could have a dictionary attached to the context and then deploy_linaro_image for a qemu client type could stuff the path into this and the boot_linaro_image action for a qemu client could read this path (and complain appropriately if its not there). Additionally we could have a list of 'result locations' (could be filesystem paths on the host, or locations on the linaro image) and the submit results step could read from here to gather together the results. This feels like it will work, but is still a bit implicit -- it's still not obvious that boot_linaro_image depends on something deploy_linaro_image does -- but maybe this is information that should be maintained outside in the job file, maybe in a JSON schema for job files? Apologies for the second brain dump today. I think these are the changes I want to make: 1) Change submit results to not be an action. 2) Add a result_locations list and action_data dictionary to LavaContext. My half-thought through idea is that actions will use the action name as a prefix, e.g. deploy_linaro_image for a qemu client might set 'deploy_linaro_image.qemu_img_path' in this dict. 3) Change the lava-test and lava-android-test to store into result_locations and the submit step to read from there. 4) Use action data to have deploy_linaro_image and boot_linaro_image (and maybe lava_test_install and lava_test_run) talk to each other. What do you guys think? Cheers, mwh [1] testing in qemu is perhaps not incredibly useful for us, but doing this forces me to confront some of the issues with testing images with in a fast model, which is something we really want to do, as we can get access to the fast model of the cortex-a15 long before we'll get access to hardware

13 years, 10 months

Freeze date for the Linaro 11.11 kernel release

by Nicolas Pitre

We are considering freezing the 11.11 kernel this next Monday (Nov 14) in order to release it on Wednesday (Nov 16), so it is out there before the US Thanksgiving holiday. If anyone would like to see their patches included in the Linaro kernel for this month, please consider submitting them ASAP. As discussed in Orlando, we are also considering a shift towards using the latest tagged release from Torvalds' mainline tree. This process is not fully in place yet, so the regular Linaro release based on the latest stable upstream release will still occur for this month. Nicolas

13 years, 10 months

Re: LAVA validation status

by Paul Sokolovsky

Hello Dave, On Fri, 11 Nov 2011 10:36:45 +0000 Dave Pigott <dave.pigott(a)linaro.org> wrote: [] > look and feel!), we're asking that you hold off submitting jobs to > LAVA until we give the go-ahead. "Hold-off" as in "please don't submit jobs now - they disrupt us", or "if you submit now, be prepared to not get expected results"? > > I'll e-mail later to let you know when we are fully operational again. > > Many thanks > > Dave Pigott > Validation Engineer > T: +44 1223 45 00 24 | M +44 7940 45 93 44 > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > -- Best Regards, Paul 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

13 years, 10 months

Re: Need testing on other machines

by David Gilbert

Hi, Thanks to those who tested the test program I sent out a few weeks ago. Thanks to dmart for pointing me at the kernel patch that fixes the futex problem that this test uncovered; see https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/884676 Dave

13 years, 10 months

[RFC PATCH v2 0/9] ARM: cpu topology Cortex-A9

by Vincent Guittot

The sched_mc feature has been originally designed to improve power consumption of multi-package system and several architecture functions are available to tune the topology and the scheduler's parameters when scheduler rebuilds the sched_domain hierarchy (change the sched_mc_power_savings level). This patches improve the power consumption of dual and quad cortex-A9 when the sched_mc_power_savings is set to 2. The following patches' policy is to accept up to 4 threads (can be configured) in the run queue of a core before starting to load balance if cpu runs at low frequencies but to accept only 1 thread for high frequencies, which is the normal behaviour. The goal is to use only one core in light load situation and all cores in heavy load situation Patches [1-2] modify the ARM cpu topology according to sched_mc_power_savings value and Cortex id. Patch [3] enables ARCH_POWER feature of the scheduler. Patch [4] adds arch_scale_freq_power function for ARM platform. Patches [5-6] modify the cpu_power of CA-9 according to sched_mc_power_savings' level and core frequency. The main goal is to increase the capacity of a core when using low cpu frequency in order to pull tasks on this core. Note that this behaviour is not really advised but it can be seen as an intermediate step between the use of cpu hotplug (which is not a power saving feature) and a new load balancer which will take into account low load situation on dual core. Patch [7] ensures that cpu0 is used in priority when only one CPU is running. Patch [8] adds some debugfs interface for test purpose. Patch [9] ensures that the cpu_power will be updated periodically. TODO list: -remove useless start of ilb when the core has capacity. -add a method (DT, sysfs, ...) to set threshold for using 1 or all cpus for CA-9 v2: *Modify the method to update cpu_power *There are fewer patches than v1 because some issues are fixed by patches that has been pushed for 3.2. *These patches has been tested on snowball and vexpress boards. *Performance results are similar to v1 v1: http://permalink.gmane.org/gmane.linux.linaro.devel/8087 Vincent

13 years, 10 months

[RFC PATCH v2 09/09] sched: Ensure cpu_power periodic update

by Vincent Guittot

With a lot of small task, the softirq sched is nearly never called when no_hz is enable. Te load_balance is mainly called with the newly_idle mode which doesn't update the cpu_power. Add a next_update field which ensure a maximum update period when there is short activity Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- include/linux/sched.h | 1 + kernel/sched_fair.c | 24 ++++++++++++++++-------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 41d0237..8610921 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -901,6 +901,7 @@ struct sched_group_power { * single CPU. */ unsigned int power, power_orig; + unsigned long next_update; }; struct sched_group { diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c index bc8ee99..320b7a0 100644 --- a/kernel/sched_fair.c +++ b/kernel/sched_fair.c @@ -91,6 +91,8 @@ unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL; static const struct sched_class fair_sched_class; +static unsigned long __read_mostly max_load_balance_interval = HZ/10; + /************************************************************** * CFS operations on generic schedulable entities: */ @@ -2667,6 +2669,11 @@ static void update_group_power(struct sched_domain *sd, int cpu) struct sched_domain *child = sd->child; struct sched_group *group, *sdg = sd->groups; unsigned long power; + unsigned long interval; + + interval = msecs_to_jiffies(sd->balance_interval); + interval = clamp(interval, 1UL, max_load_balance_interval); + sdg->sgp->next_update = jiffies + interval; if (!child) { update_cpu_power(sd, cpu); @@ -2774,12 +2781,15 @@ static inline void update_sg_lb_stats(struct sched_domain *sd, * domains. In the newly idle case, we will allow all the cpu's * to do the newly idle load balance. */ - if (idle != CPU_NEWLY_IDLE && local_group) { - if (balance_cpu != this_cpu) { - *balance = 0; - return; - } - update_group_power(sd, this_cpu); + if (local_group) { + if (idle != CPU_NEWLY_IDLE) { + if (balance_cpu != this_cpu) { + *balance = 0; + return; + } + update_group_power(sd, this_cpu); + } else if (time_after_eq(jiffies, group->sgp->next_update)) + update_group_power(sd, this_cpu); } /* Adjust by relative CPU power of the group */ @@ -3879,8 +3889,6 @@ void select_nohz_load_balancer(int stop_tick) static DEFINE_SPINLOCK(balancing); -static unsigned long __read_mostly max_load_balance_interval = HZ/10; - /* * Scale the max load_balance interval with the number of CPUs in the system. * This trades load-balance latency on larger machines for less cross talk. -- 1.7.4.1

13 years, 10 months

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev November 2011