linaro-dev December 2011

linaro-dev@lists.linaro.org

139 participants
148 discussions

[Activity] Power Management WG Weekly Status report for week ending 2011-12-16

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report & meeting minutes for the Power Management working group for the week ending 2011-12-16 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-12-15 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-12-14 == Summary == (For details, see the Weekly Status Report and Meeting Minutes ) * Power Management initial sessions for next Linaro Connect lcq1-12 has been set, please see: http://summit.ubuntu.com/lcq1-12/track/linaro-power-management/ * New Common Clock patches have been submitted, including support for OMAP4. * Sched_mc patches are now available on android LEB * Submitted v2 of common cpuidle driver. * Added a generic processor cooling devices(non ACPI based, for ACPI already exists) Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 4 months

[ACTIVITY] OCTO weekly status report - wk49.2011 (20111205-20111209)

by Ilias Biris

Status report: https://wiki.linaro.org/OfficeofCTO/WeeklyReport Last weekly meeting minutes: https://wiki.linaro.org/OfficeofCTO/2011-12-13 Highlights: = ARMHF = - Debian: 67 % of the archive built (https://buildd.debian.org/stats/graph-week-big.png), chasing/fixing up ~140-180 build failures now. Estimated to need a week or two more - Ubuntu - the email from Mathias Klose (thread in linaro-dev: http://lists.linaro.org/pipermail/linaro-dev/2011-December/009242.html) describes well the status for Ubuntu armhf build. Emphasis on the issues which Matthias raised: compilers not completely built yet packaging mentioning armel only not armhf hardfloat issues needing porting work = ARM Server = - Preparing server WG presentation to mgmt team - will start filling out some meta-blueprints for the initial work, concentrating on the kernel parts - Finished and discussing the first version of Server WG roadmap with updated mandate and PMWG bits - Starting to look into the newly released ACPI v5 specification, with the interest to write a whitepaper on ACPI recommendations Questions/comments? -- 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, 4 months

[PATCH v3] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init

by Rajendra Nayak

An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT' to identify such devices/hwmods. When the device/hwmod is requested to be enabled (the first time) by its driver/user, nothing except the mux-enable and a state change to '_HWMOD_STATE_ENABLED' is needed. The mux data is board specific and is unavailable during initial enable() of the device, done by the framework as part of setup(). A good example of a such a device is an UART used as debug console. The UART module needs to be kept enabled through the boot, until the UART driver takes control of it, for debug prints to appear on the console. Acked-by: Kevin Hilman <khilman(a)ti.com> Acked-by: Benoit Cousson <b-cousson(a)ti.com> Signed-off-by: Rajendra Nayak <rnayak(a)ti.com> --- arch/arm/mach-omap2/omap_hwmod.c | 23 ++++++++++++++++++++++- arch/arm/plat-omap/include/plat/omap_hwmod.h | 6 ++++++ 2 files changed, 28 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 6b3088d..166a42d 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1441,6 +1441,25 @@ static int _enable(struct omap_hwmod *oh) pr_debug("omap_hwmod: %s: enabling\n", oh->name); + /* + * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left + * in enabled state at init. + * Now that someone is really trying to enable them, + * just update the state. + */ + if (oh->_state == _HWMOD_STATE_ENABLED_AT_INIT) { + /* + * If the caller has mux data populated, do the mux'ing + * which wouldn't have been done as part of the _enable() + * done during setup. + */ + if (oh->mux) + omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED); + + oh->_state = _HWMOD_STATE_ENABLED; + return 0; + } + if (oh->_state != _HWMOD_STATE_INITIALIZED && oh->_state != _HWMOD_STATE_IDLE && oh->_state != _HWMOD_STATE_DISABLED) { @@ -1744,8 +1763,10 @@ static int _setup(struct omap_hwmod *oh, void *data) * it should be set by the core code as a runtime flag during startup */ if ((oh->flags & HWMOD_INIT_NO_IDLE) && - (postsetup_state == _HWMOD_STATE_IDLE)) + (postsetup_state == _HWMOD_STATE_IDLE)) { + oh->_state = _HWMOD_STATE_ENABLED_AT_INIT; postsetup_state = _HWMOD_STATE_ENABLED; + } if (postsetup_state == _HWMOD_STATE_IDLE) _idle(oh); diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 8b372ed..2bd3929 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -436,6 +436,12 @@ struct omap_hwmod_omap4_prcm { #define _HWMOD_STATE_ENABLED 4 #define _HWMOD_STATE_IDLE 5 #define _HWMOD_STATE_DISABLED 6 +/* + * This state signifies the hwmod was left enabled + * after init, by the framework, because of the + * 'HWMOD_INIT_NO_IDLE' flag. + */ +#define _HWMOD_STATE_ENABLED_AT_INIT 7 /** * struct omap_hwmod_class - the type of an IP block -- 1.7.1

13 years, 4 months

[RFC V1 1/4] cpufreq: add arm soc generic cpufreq driver

by Richard Zhao

It support single core and multi-core ARM SoCs. But it assume all cores share the same frequency and voltage. Signed-off-by: Richard Zhao <richard.zhao(a)linaro.org> --- drivers/cpufreq/Kconfig.arm | 8 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/arm-cpufreq.c | 260 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 drivers/cpufreq/arm-cpufreq.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 72a0044..a0f7d35 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -2,6 +2,14 @@ # ARM CPU Frequency scaling drivers # +config ARM_GENERIC_CPUFREQ + bool "ARM generic" + help + This adds ARM generic CPUFreq driver. It assumes all + cores of the SoC share the same clock and voltage. + + If in doubt, say N. + config ARM_S3C64XX_CPUFREQ bool "Samsung S3C64XX" depends on CPU_S3C6410 diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index ce75fcb..6ccf02d 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o ################################################################################## # ARM SoC drivers +obj-$(CONFIG_ARM_GENERIC_CPUFREQ) += arm-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += db8500-cpufreq.o obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o diff --git a/drivers/cpufreq/arm-cpufreq.c b/drivers/cpufreq/arm-cpufreq.c new file mode 100644 index 0000000..fd9759f --- /dev/null +++ b/drivers/cpufreq/arm-cpufreq.c @@ -0,0 +1,260 @@ +/* + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved. + */ + +/* + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +#include <linux/module.h> +#include <linux/cpufreq.h> +#include <linux/clk.h> +#include <linux/err.h> +#include <linux/slab.h> +#include <linux/of.h> +#include <asm/cpu.h> +#include <mach/hardware.h> +#include <mach/clock.h> + +static u32 *cpu_freqs; +static u32 *cpu_volts; +static u32 trans_latency; +static int cpu_op_nr; + +static int cpu_freq_khz_min; +static int cpu_freq_khz_max; + +static struct clk *cpu_clk; +static struct cpufreq_frequency_table *arm_freq_table; + +static int set_cpu_freq(int freq) +{ + int ret = 0; + int org_cpu_rate; + + org_cpu_rate = clk_get_rate(cpu_clk); + if (org_cpu_rate == freq) + return ret; + + ret = clk_set_rate(cpu_clk, freq); + if (ret != 0) { + printk(KERN_DEBUG "cannot set CPU clock rate\n"); + return ret; + } + + return ret; +} + +static int arm_verify_speed(struct cpufreq_policy *policy) +{ + return cpufreq_frequency_table_verify(policy, arm_freq_table); +} + +static unsigned int arm_get_speed(unsigned int cpu) +{ + return clk_get_rate(cpu_clk) / 1000; +} + +static int arm_set_target(struct cpufreq_policy *policy, + unsigned int target_freq, unsigned int relation) +{ + struct cpufreq_freqs freqs; + int freq_Hz, cpu; + int ret = 0; + unsigned int index; + + cpufreq_frequency_table_target(policy, arm_freq_table, + target_freq, relation, &index); + freq_Hz = arm_freq_table[index].frequency * 1000; + + freqs.old = clk_get_rate(cpu_clk) / 1000; + freqs.new = clk_round_rate(cpu_clk, freq_Hz); + freqs.new = (freqs.new ? freqs.new : freq_Hz) / 1000; + freqs.flags = 0; + + if (freqs.old == freqs.new) + return 0; + + for_each_possible_cpu(cpu) { + freqs.cpu = cpu; + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE); + } + + ret = set_cpu_freq(freq_Hz); + +#ifdef CONFIG_SMP + /* loops_per_jiffy is not updated by the cpufreq core for SMP systems. + * So update it for all CPUs. + */ + for_each_possible_cpu(cpu) + per_cpu(cpu_data, cpu).loops_per_jiffy = + cpufreq_scale(per_cpu(cpu_data, cpu).loops_per_jiffy, + freqs.old, freqs.new); +#endif + + for_each_possible_cpu(cpu) { + freqs.cpu = cpu; + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE); + } + + return ret; +} + +static int arm_cpufreq_init(struct cpufreq_policy *policy) +{ + int ret; + + printk(KERN_INFO "ARM CPU frequency driver\n"); + + if (policy->cpu >= num_possible_cpus()) + return -EINVAL; + + policy->cur = clk_get_rate(cpu_clk) / 1000; + policy->min = policy->cpuinfo.min_freq = cpu_freq_khz_min; + policy->max = policy->cpuinfo.max_freq = cpu_freq_khz_max; + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY; + cpumask_setall(policy->cpus); + /* Manual states, that PLL stabilizes in two CLK32 periods */ + policy->cpuinfo.transition_latency = trans_latency; + + ret = cpufreq_frequency_table_cpuinfo(policy, arm_freq_table); + + if (ret < 0) { + printk(KERN_ERR "%s: failed to register i.MXC CPUfreq with error code %d\n", + __func__, ret); + return ret; + } + + cpufreq_frequency_table_get_attr(arm_freq_table, policy->cpu); + return 0; +} + +static int arm_cpufreq_exit(struct cpufreq_policy *policy) +{ + cpufreq_frequency_table_put_attr(policy->cpu); + + set_cpu_freq(cpu_freq_khz_max * 1000); + return 0; +} + +static struct cpufreq_driver arm_cpufreq_driver = { + .flags = CPUFREQ_STICKY, + .verify = arm_verify_speed, + .target = arm_set_target, + .get = arm_get_speed, + .init = arm_cpufreq_init, + .exit = arm_cpufreq_exit, + .name = "arm", +}; + +static int __devinit arm_cpufreq_driver_init(void) +{ + struct device_node *cpu0; + const struct property *pp; + int i, ret; + + cpu0 = of_find_node_by_path("/cpus/cpu@0"); + if (!cpu0) + return -ENODEV; + + pp = of_find_property(cpu0, "cpu_freqs", NULL); + if (!pp) { + ret = -ENODEV; + goto put_node; + } + cpu_op_nr = pp->length / sizeof(u32); + if (!cpu_op_nr) { + ret = -ENODEV; + goto put_node; + } + ret = -ENOMEM; + cpu_freqs = kzalloc(sizeof(*cpu_freqs) * cpu_op_nr, GFP_KERNEL); + if (!cpu_freqs) + goto put_node; + of_property_read_u32_array(cpu0, "cpu_freqs", cpu_freqs, cpu_op_nr); + + pp = of_find_property(cpu0, "cpu_volts", NULL); + if (pp) { + if (cpu_op_nr == pp->length / sizeof(u32)) { + cpu_volts = kzalloc(sizeof(*cpu_freqs) * cpu_op_nr, + GFP_KERNEL); + if (!cpu_volts) + goto free_cpu_freqs; + of_property_read_u32_array(cpu0, "cpu_volts", + cpu_freqs, cpu_op_nr); + } else + printk(KERN_WARNING "cpufreq: invalid cpu_volts!\n"); + } + + if (of_property_read_u32(cpu0, "trans_latency", &trans_latency)) + trans_latency = CPUFREQ_ETERNAL; + + cpu_freq_khz_min = cpu_freqs[0] / 1000; + cpu_freq_khz_max = cpu_freqs[0] / 1000; + + arm_freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) + * (cpu_op_nr + 1), GFP_KERNEL); + if (!arm_freq_table) + goto free_cpu_volts; + + for (i = 0; i < cpu_op_nr; i++) { + arm_freq_table[i].index = i; + arm_freq_table[i].frequency = cpu_freqs[i] / 1000; + if ((cpu_freqs[i] / 1000) < cpu_freq_khz_min) + cpu_freq_khz_min = cpu_freqs[i] / 1000; + if ((cpu_freqs[i] / 1000) > cpu_freq_khz_max) + cpu_freq_khz_max = cpu_freqs[i] / 1000; + } + + arm_freq_table[i].index = i; + arm_freq_table[i].frequency = CPUFREQ_TABLE_END; + + cpu_clk = clk_get(NULL, "cpu"); + if (IS_ERR(cpu_clk)) { + printk(KERN_ERR "%s: failed to get cpu clock\n", __func__); + ret = PTR_ERR(cpu_clk); + goto free_freq_table; + } + + ret = cpufreq_register_driver(&arm_cpufreq_driver); + if (ret) + goto clock_put; + + of_node_put(cpu0); + + return 0; + +clock_put: + clk_put(cpu_clk); +free_freq_table: + kfree(arm_freq_table); +free_cpu_volts: + kfree(cpu_volts); +free_cpu_freqs: + kfree(cpu_freqs); +put_node: + of_node_put(cpu0); + + return ret; +} + +static void arm_cpufreq_driver_exit(void) +{ + cpufreq_unregister_driver(&arm_cpufreq_driver); + kfree(cpu_freqs); + kfree(cpu_volts); + kfree(arm_freq_table); + clk_put(cpu_clk); +} + +module_init(arm_cpufreq_driver_init); +module_exit(arm_cpufreq_driver_exit); + +MODULE_AUTHOR("Freescale Semiconductor Inc. Richard Zhao <richard.zhao(a)freescale.com>"); +MODULE_DESCRIPTION("ARM SoC generic CPUFreq driver"); +MODULE_LICENSE("GPL"); -- 1.7.5.4

13 years, 4 months

Linaro Kernel December 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our December 2011 development snapshot: linux-linaro-3.1-2011.12-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.12/+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.12-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.1.5 stable kernel - Inital thermal framework support (Amit Kacchap) - Updates to ARM perf support (Will Deacon) - Improvements to ARM OOM killer support (Kautuk Consul) A full change log against the 2011.11 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.12/+download/CHANGELOG-linux… High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 4 months

perf fixes not present in Linaro kernel

by Will Deacon

Hi Nicolas, It seems as though some of my perf patches have ended up in the Linaro kernel source but the fixes that I've pushed during the -rc haven't made it: https://bugs.launchpad.net/linaro-landing-team-freescale/+bug/893653 https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/843628 Rather than me point each landing team at the patches, would you be able to cherry-pick the fixes from mainline please? They are: bce34d14 ("ARM: perf: initialise used_mask for fake PMU during validation") e5a21327 ("ARM: perf: check that we have a platform device when reserving PMU") 6bd05409 ("ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs") Hopefully that way all of the landing teams will receive the patches via the main Linaro kernel tree. Cheers, Will

13 years, 4 months

Jenkins LAVA hook

by Zach Pfeffer

Frans, Paul Sokolovsky has some details about an issue we're running into passing builds to LAVA from android-build with our new proprietary binaries? Paul would you tell Frans about it? -- 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, 4 months

Re: "struct user" conflicts on arm

by Wookey

This subject came up on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00025.html And it seems like the sort of architectural issue linaro should take an interest in fixing to avoid making people's lives difficult when building on arm. Is it on anyone's list already? In short: A C app that defines a struct 'user' and uses wait.h or signal.h will find a clash with the system struct of the same name, which should only be needed for GDB (when built on/for arm). On other arches this is not pulled in by default so the problem doesn't arise. We can 1) Change every app in the world that defines a 'struct user' 2) Stop these headers getting brought in when not actually needed (it's a relatively recent change that brings it in) 3) Change the name in glibc/GDB to something less likely to clash disclaimer: I know nothing at all about this except what I just read in that thread. Please refer to the thread for details. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

13 years, 4 months

first rebuild of precise pangolin, including armhf

by Matthias Klose

This week, a kind of rebuild for precise pangolin in the disguise of the armhf bootstrap did end. The build did expose some ARM unspecific build failures; please use the information from the armhf build logs to address these build failures. Please use the ftbfs pages to gather more information: - http://qa.ubuntuwire.com/ftbfs/ (not yet showing armhf) This mostly shows failures introduced by syncs from Debian unstable (Debian didn't yet file bug reports after introducing the -Werror=format-security default). - http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html Shows armhf and armel build failures. Look at build failures which appear on armhf but not armel. These are likely build failures for other architectures as well. There are some generic issues found in more than one package: - default CFLAGS/CXXFLAGS include -Werror=format-security. Fixes are easy; don't stop fixing the first occurrence, but complete a local build. - Gnome pkgconfig files dropping -lm from Libs, and other packages not explicitly linking with -lm (resulting in symbols like "sqrt" and "pow" not found). - libreadline-dev dropping build dependency on libncurses-dev, and libncurses introducing a new libtinfo library. ARM (hf) specific issues include - compilers not yet built on armhf (gnat, fpc, ocamlopt), or not yet having the correct defaults (clang). - packaging mentioning armel only, but not armhf; usually needs fixes in both the control and rules files. http://people.canonical.com/~adconrad/universe-armel-armhf_differences might help with these although it includes all the packages build depending on gnat and fpc. - hard float issues, needing porting work. known ones are libreoffice, ocamlopt and fpc, but there will be more ... The armhf precise archive is installable with debootstrap(1) in a chroot on any armel Ubuntu/Linaro release. Thanks to Adam Conrad for driving the bootstrap, to Loic Minier for fixing ARM issues on the fly, to the Losa's for keeping the build farm alive, and many others. Matthias

13 years, 4 months

[ACTIVITY] Multimedia WG weekly report - wk49.2011 (2011120 - 20111209)

by Ilias Biris

Detailed dashboard: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-12-13 Highlights: - Moving on with the release for realvideo end-to-end audio testing (basic prototype), speex, UCM (initialize ucm testcase to make sure ucm4pa works properly, loaded pulseaudio patches) - Found a way to work around lava-test proxy issue: cma lava-test submitted to test the only one snowball in board farm - Started working with gstplayer (gstreamer playbin2 based) for xbmc (xorg on i.mx boards is really slow, xbmc package for the LEB is very slow as well) - Started working on the api differences post for tinyalsa vs alsa-lib - Continued pushing patches for omapdrm (dri2video work) for the 3.3 merge window Issues: - Bug #893402 is impeding progress in end-to-end audio testing (only a prototype is available for desktop - pandaboard is not functional). We're working on the bug - CMA lava-test is very long (around 2 hours) and there is only one snowball on test farm, so it will takes long to debug/fix it - Related to xbmc effort: there's SLOW xorg (no hw accel) on i.mx53 with linaro image and will probably be missing also for 11.12. Biggest problem is xbmc dvdplayer - a replacement for dvdplayer that uses gst demuxer and decoders would work much better. The work for xbmc is now moving to 12.01 with this gstreamer-related blueprint Risks -It is possible to delay the Huffman optimisations for LJT work planned for 11.12 to complete in 12.01 instead - It is possible to move Speex LAVA benchmarking to 12.01 - Since CMA lava-test is very long (around 2 hours) and there is only one snowball on test farm, the CMA testing blueprint could be put on hold. This is not a huge impediment - since we can already execute the CMA lava-test with local method -- 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, 4 months

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev December 2011