linaro-kernel July 2013

linaro-kernel@lists.linaro.org

73 participants
90 discussions

[Question] The Secure Monitor Code For PSCI

by Leo Yan

hi, Now ARM has defined PSCI for Trustzone; So where we can get monitor code or trustzone's s/w on TC2 for the reference? when we go through TC2 and ARM64's code, they have already supported PSCI yet for the smp boot operations and low power modes, so it will be clear for us if we can see two portions' code to get clear the whole flow. Thx in advance. -- Thx, Leo Yan

10 years, 9 months

[PATCH] regulator: core: Add missing stub for regulator_get_exclusive()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Signed-off-by: Mark Brown <broonie(a)linaro.org> --- include/linux/regulator/consumer.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 3610df8..3b9b4da 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -217,6 +217,12 @@ devm_regulator_get(struct device *dev, const char *id) return NULL; } +static inline struct regulator *__must_check +devm_regulator_get_exclusive(struct device *dev, const char *id) +{ + return NULL; +} + static inline void regulator_put(struct regulator *regulator) { } -- 1.8.3.2

10 years, 9 months

[PATCH 01/11] spi: Provide core support for runtime PM during transfers

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Most SPI drivers that implement runtime PM support use identical code to do so: they acquire a runtime PM lock in prepare_transfer_hardware() and then they release it in unprepare_transfer_hardware(). The variations in this are mostly missing error checking and the choice to use autosuspend. Since these runtime PM calls are normally the only thing in the prepare and unprepare callbacks and the autosuspend API transparently does the right thing on devices with autosuspend disabled factor all of this out into the core with a flag to enable the behaviour. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/spi/spi.c | 16 ++++++++++++++++ include/linux/spi/spi.h | 4 ++++ 2 files changed, 20 insertions(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 46c3f56..61f71b9 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -553,6 +553,10 @@ static void spi_pump_messages(struct kthread_work *work) master->unprepare_transfer_hardware(master)) dev_err(&master->dev, "failed to unprepare transfer hardware\n"); + if (master->auto_runtime_pm) { + pm_runtime_mark_last_busy(master->dev.parent); + pm_runtime_put_autosuspend(master->dev.parent); + } return; } @@ -572,11 +576,23 @@ static void spi_pump_messages(struct kthread_work *work) master->busy = true; spin_unlock_irqrestore(&master->queue_lock, flags); + if (!was_busy && master->auto_runtime_pm) { + ret = pm_runtime_get_sync(master->dev.parent); + if (ret < 0) { + dev_err(&master->dev, "Failed to power device: %d\n", + ret); + return; + } + } + if (!was_busy && master->prepare_transfer_hardware) { ret = master->prepare_transfer_hardware(master); if (ret) { dev_err(&master->dev, "failed to prepare transfer hardware\n"); + + if (master->auto_runtime_pm) + pm_runtime_put(master->dev.parent); return; } } diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index be40c97..d73059a 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -256,6 +256,8 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * @busy: message pump is busy * @running: message pump is running * @rt: whether this queue is set to run as a realtime task + * @auto_runtime_pm: the core should ensure a runtime PM reference is held + * while the hardware is prepared * @prepare_transfer_hardware: a message will soon arrive from the queue * so the subsystem requests the driver to prepare the transfer hardware * by issuing this call @@ -380,11 +382,13 @@ struct spi_master { bool busy; bool running; bool rt; + bool auto_runtime_pm; int (*prepare_transfer_hardware)(struct spi_master *master); int (*transfer_one_message)(struct spi_master *master, struct spi_message *mesg); int (*unprepare_transfer_hardware)(struct spi_master *master); + /* gpio chip select */ int *cs_gpios; }; -- 1.8.3.2

10 years, 9 months

[PATCH 1/3] cpu topology: remove stale arch_provides_topology_pointers and define_siblings_show_map/list()

by Hanjun Guo

arch_provides_topology_pointers was introduced in commit 23ca4bba3 (x86: cleanup early per cpu variables/accesses v4) to indicate pointers to the topology cpumask_t maps are valid to avoid copying data on to/off of the stack. But later in commit fbd59a8d (cpumask: Use topology_core_cpumask()/ topology_thread_cpumask()), the pointers to the topology struct cpumask maps are always valid. After that commit, the only difference is that there is a redundant "unsigned int cpu = dev->id;" if arch_provides_topology_pointers defined, but dev->id is type 'u32' which devolves to 'unsigned int' on all supported arches. So this arch_provides_topology_pointers define is pointless and only cause obfuscation now, remove it. Tested on x86 machine, topology information in sys/devices/system/cpu/ cpuX/topology/ is the same after appling this patch set. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/base/topology.c | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 2f5919e..94ffee3 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -62,25 +62,6 @@ static ssize_t show_cpumap(int type, const struct cpumask *mask, char *buf) } #endif -#ifdef arch_provides_topology_pointers -#define define_siblings_show_map(name) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(0, topology_##name(cpu), buf); \ -} - -#define define_siblings_show_list(name) \ -static ssize_t show_##name##_list(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(1, topology_##name(cpu), buf); \ -} - -#else #define define_siblings_show_map(name) \ static ssize_t show_##name(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -95,7 +76,6 @@ static ssize_t show_##name##_list(struct device *dev, \ { \ return show_cpumap(1, topology_##name(dev->id), buf); \ } -#endif #define define_siblings_show_func(name) \ define_siblings_show_map(name); define_siblings_show_list(name) -- 1.7.9.5

10 years, 9 months

[PATCH 0/1] ARM: atomic64: fix endian-ness in atomic.h

by Victor Kamensky

Fixes atomic64_xxx functions endian-ness isussues as it was discussed on http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185898.html Patch itself follows in separate email. This cover letter describes what testing has been done Tested on pandaboard for both cases: LE and BE, CONFIG_GENERIC_ATOMIC64 was forcefully disabled. In BE case it was tested on top of Ben's other BE patches covered by (updates for be8 patch series). The following tests passed: 1) CONFIG_ATOMIC64_SELFTEST 2) The following module produced identical output for both LE, BE, and GENERIC_ATOMIC64 #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/atomic.h> atomic64_t a = {0}; #define STEP 0x40000000 void atomic64_add_test1 (void) { atomic64_add(STEP, &a); } void test_atomic64_add(void) { int i; printk("atomic64_add\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_add_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } void atomic64_sub_test1 (void) { atomic64_sub(STEP, &a); } void test_atomic64_sub(void) { int i; printk("atomic64_sub\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { atomic64_sub_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } u64 atomic64_add_return_test1 (void) { return atomic64_add_return(STEP, &a); } void test_atomic64_add_return(void) { int i; u64 ret; printk("atomic64_add_return\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { ret = atomic64_add_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } u64 atomic64_sub_return_test1 (void) { return atomic64_sub_return(STEP, &a); } void test_atomic64_sub_return(void) { int i; u64 ret; printk("atomic64_sub_return\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { ret = atomic64_sub_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } void atomic64_dec_if_positive_test1 (void) { atomic64_dec_if_positive(&a); } void test1_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test1\n"); atomic64_set(&a, 0x100000003); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void test2_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test2\n"); atomic64_set(&a, 0x3); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void atomic64_add_unless_test1(long long u) { atomic64_add_unless(&a, STEP, u); } void test_atomic64_add_unless(void) { int i; u64 prev; printk("atomic64_add_unless\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { prev = a.counter; atomic64_add_unless_test1(prev); printk("i = %2d: no change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); atomic64_add_unless_test1(prev - 1); printk("i = %2d: change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); } } int init_module (void) { test_atomic64_add(); test_atomic64_sub(); test_atomic64_add_return(); test_atomic64_sub_return(); test1_atomic64_dec_if_positive(); test2_atomic64_dec_if_positive(); test_atomic64_add_unless(); return 0; } void cleanup_module(void) { } MODULE_LICENSE("GPL"); Thanks, Victor Victor Kamensky (1): ARM: atomic64: fix endian-ness in atomic.h arch/arm/include/asm/atomic.h | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) -- 1.8.1.4

10 years, 9 months

RE: Arndale power management

by Comaschi, F.

Yes of course! Sorry for that ;) Best, Francesco ________________________________________ From: Mike Turquette [mturquette(a)linaro.org] Sent: Thursday, July 25, 2013 7:36 PM To: Comaschi, F. Subject: Re: Arndale power management Francesco, Can you reply to the list with your response? Please do not remove the list when responding. Regards, Mike On Wed, Jul 24, 2013 at 11:11 PM, Comaschi, F. <fcomaschi(a)tue.nl> wrote: > Dear Mike, > > thank you very much for your reply! > > the hack that you suggest is indeed what I have done so far just for testing. However, I was thinking, if we have some knowledge about the specific application that we are running, from a functional point of view (e.g., we are scanning a scene through a camera and we see that there's no movement, therefore we decide to lower the frequency), wouldn't it be useful to exploit this knowledge in order to implement our own DVFS policy in a more proactive way, rather than recurring to the available governors which I think are working in a more reactive way? > In that case, how would you suggest to interface with the OS from inside my application? Shall I make some "calls" to specific API's, or maybe writing my own governor? > > Thanks in advance for your attention! > > Best, > > Francesco > ________________________________________ > From: Mike Turquette [mturquette(a)linaro.org] > Sent: Thursday, July 25, 2013 3:58 AM > To: Viresh Kumar; Comaschi, F. > Cc: Lukasz Majewski; Lists linaro-kernel; cpufreq(a)vger.kernel.org; Chander Kashyap; Linux PM List > Subject: Re: Arndale power management > > Quoting Viresh Kumar (2013-07-15 23:43:03) >> Adding few more lists so that others can also help.. >> >> On 15 July 2013 20:00, Comaschi, F. <fcomaschi(a)tue.nl> wrote: >> > Dear Viresh, >> > >> > I am Francesco Comaschi, a researcher at Eindhoven University of Technology. My research group is interested in implementing custom power management policies on ARM-based platform (at the moment we are using an Arndale 5250 board featuring Exynos5 dual). We would like to make use of DVFS and to be able to measure power consumption on the board. >> >> Ok. >> >> > First of all, congratulations for the work that you and the other guys form the power management team are doing within the Linaro community, I always follow your progress, and so far you have been the only reliable source of information for everything I have been doing on the board. >> >> Thanks :) >> >> > If you do not mind, I would like to ask you a few questions: >> > 1) Is there a way to measure the board power consumption via software? I have read here: http://blogs.arm.com/software-enablement/925-linux-hwmon-power-management-a… that it is possible with the ARM Versatile boards, through the hwmon framework and lm_sensors. However, when I run lm_sensors on the Arndale board, no sensors were found. Do you know about any other possible ways to measure power in software? Maybe it is possible to communicate with the on-board PMIC? Maybe there are some registers where information about the power/voltage provided to the processor and the other components is available? >> >> On ARM Versatile express boards and the coretiles that come with it, >> we have sensors which are probed through hwmon framework in >> Linux. So, we have hardware IPs present on board which let us >> get some power figures per cluster for big LITTLE. >> >> I am not sure if Exynos have any such things on it. >> >> @Chander: Are you aware of any such features? >> >> > 2) Recently I have read Andy Green’s presentation “How to measure SoC power”. However, by measuring power on the PMIC input side through the ARM Energy Probe, probably I won't be able to see the effect of DVFS. Do you have any suggestions on how to measure the effect of DVFS, even through hardware measurements? >> >> You need probes on the voltage regulator which is feed the cores... >> But again, that is very much hardware specific. And I haven't worked >> on Exynos at all :) >> >> > 3) More in general, I do not know which is the best way to implement custom policies of DVFS. >> >> I didn't get you here. Are you talking about tuning of governors here? >> >> > Is it possible, maybe through appropriate API's, to access the cpu_idle and the cpu_freq framework from inside my application? Shall I work directly with the drivers of the PMIC? Is it possible to set the voltage directly from inside my application? > > Are you trying to create a DVFS policy from a userspace application? > Lots of people hack together something using the CPUfreq "userspace" > governor and writing to: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > > This is not something that should be shipped on a product but is useful > for learning and prototyping. It only affects the CPU and will not help > you craft DVFS policies on other peripherals/devices. > > Regards, > Mike > >> >> Something on the board must provide this to kernel. Kernel can't >> get it by itself. >> >> _______________________________________________ >> linaro-kernel mailing list >> linaro-kernel(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-kernel

10 years, 9 months

[RFC][PATCH 0/9] sched: Power scheduler design proposal

by Morten Rasmussen

Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described <http://permalink.gmane.org/gmane.linux.kernel/1508480>. The patch set introduces a cpu capacity managing 'power scheduler' which lives by the side of the existing (process) scheduler. Its role is to monitor the system load and decide which cpus that should be available to the process scheduler. Long term the power scheduler is intended to replace the currently distributed uncoordinated power management policies and will interface a unified platform specific power driver obtain power topology information and handle idle and P-states. The power driver interface should be made flexible enough to support multiple platforms including Intel and ARM. This prototype supports very simple task packing and adds cpufreq wrapper governor that allows the power scheduler to drive P-state selection. The prototype policy is absolutely untuned, but this will be addressed in the future. Scalability improvements, such as avoid iterating over all cpus, will also be addressed in the future. Thanks, Morten Morten Rasmussen (9): sched: Introduce power scheduler sched: Redirect update_cpu_power to sched/power.c sched: Make select_idle_sibling() skip cpu with a cpu_power of 1 sched: Make periodic load-balance disregard cpus with a cpu_power of 1 sched: Make idle_balance() skip cpus with a cpu_power of 1 sched: power: add power_domain data structure sched: power: Add power driver interface sched: power: Add initial frequency scaling support to power scheduler sched: power: cpufreq: Initial schedpower cpufreq governor arch/arm/Kconfig | 2 + drivers/cpufreq/Kconfig | 8 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_schedpower.c | 119 +++++++++++++ include/linux/sched/power.h | 29 ++++ kernel/Kconfig.power | 3 + kernel/sched/Makefile | 1 + kernel/sched/fair.c | 43 +++-- kernel/sched/power.c | 307 ++++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 24 +++ 10 files changed, 525 insertions(+), 12 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_schedpower.c create mode 100644 include/linux/sched/power.h create mode 100644 kernel/Kconfig.power create mode 100644 kernel/sched/power.c -- 1.7.9.5

10 years, 9 months

Re: Arndale power management

by Viresh Kumar

Adding few more lists so that others can also help.. On 15 July 2013 20:00, Comaschi, F. <fcomaschi(a)tue.nl> wrote: > Dear Viresh, > > I am Francesco Comaschi, a researcher at Eindhoven University of Technology. My research group is interested in implementing custom power management policies on ARM-based platform (at the moment we are using an Arndale 5250 board featuring Exynos5 dual). We would like to make use of DVFS and to be able to measure power consumption on the board. Ok. > First of all, congratulations for the work that you and the other guys form the power management team are doing within the Linaro community, I always follow your progress, and so far you have been the only reliable source of information for everything I have been doing on the board. Thanks :) > If you do not mind, I would like to ask you a few questions: > 1) Is there a way to measure the board power consumption via software? I have read here: http://blogs.arm.com/software-enablement/925-linux-hwmon-power-management-a… that it is possible with the ARM Versatile boards, through the hwmon framework and lm_sensors. However, when I run lm_sensors on the Arndale board, no sensors were found. Do you know about any other possible ways to measure power in software? Maybe it is possible to communicate with the on-board PMIC? Maybe there are some registers where information about the power/voltage provided to the processor and the other components is available? On ARM Versatile express boards and the coretiles that come with it, we have sensors which are probed through hwmon framework in Linux. So, we have hardware IPs present on board which let us get some power figures per cluster for big LITTLE. I am not sure if Exynos have any such things on it. @Chander: Are you aware of any such features? > 2) Recently I have read Andy Green’s presentation “How to measure SoC power”. However, by measuring power on the PMIC input side through the ARM Energy Probe, probably I won't be able to see the effect of DVFS. Do you have any suggestions on how to measure the effect of DVFS, even through hardware measurements? You need probes on the voltage regulator which is feed the cores... But again, that is very much hardware specific. And I haven't worked on Exynos at all :) > 3) More in general, I do not know which is the best way to implement custom policies of DVFS. I didn't get you here. Are you talking about tuning of governors here? > Is it possible, maybe through appropriate API's, to access the cpu_idle and the cpu_freq framework from inside my application? Shall I work directly with the drivers of the PMIC? Is it possible to set the voltage directly from inside my application? Something on the board must provide this to kernel. Kernel can't get it by itself.

10 years, 9 months

[PATCH 1/2] extcon: gpio: Use power efficient workqueue for debounce

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> The debounce timeout is generally quite long and the work not performance critical so allow the scheduler to run the work anywhere rather than in the normal per-CPU workqueue. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/extcon/extcon-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 02bec32..f874c30 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -56,7 +56,7 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id) { struct gpio_extcon_data *extcon_data = dev_id; - schedule_delayed_work(&extcon_data->work, + queue_delayed_work(system_power_efficient_wq, &extcon_data->work, extcon_data->debounce_jiffies); return IRQ_HANDLED; } -- 1.8.3.2

10 years, 9 months

[PATCH 0/6] USB: OHCI: more bus glues as separate modules

by Manjunath Goudar

These patches are for separating the SOC On-Chip ohci host controller from ohci-hcd host code into its own driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.12. V2: In patch 5/6 and 6/6: -Set non-standard fields in hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. In patch 1/6 to 4/6 -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. V3: In patch 5/6 and 6/6: -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. In patch 5/6: -The ohci_restart() function is not required in current scenario, only discarding connection state of integrated transceivers is sufficient, for this directly handling ohci->hc_control. In patch 2/6 : -rewritten if (config->otg || config->rwc) block statements into two separate 'if blocks' to handle below scenarios 1. config->otg set scenario. 2. if any of these (config->otg, config->rwc) are set, this scenario should be handled only after ohci_setup() In patch 1/6 and 4/6: No change. V4: In patch 1/6 and 4/6: No change. In patch 2/6 : -usb_remove_hcd() function is required a valid clock that is what omap_ohci_clock_power(0) is called after hcd shutdown. In patch 3/6 : -V3 modification revert back, only ohci->regs setting write() function has been removed because ohci->regs doesn't get set until usb_add_hcd. In patch 5/6 : - Removed extra space after "tristate". - Removed extra space between function name and '(' characters. - MODULE_ALIAS line moved to last statement of ohci-at91 file. In patch 6/6 : - Removed extra space before the '='. - Moved /* forward definitions */ line before the declarations of functions. Manjunath Goudar (6): USB: OHCI: make ohci-exynos a separate driver USB: OHCI: make ohci-omap a separate driver USB: OHCI: make ohci-omap3 a separate driver USB: OHCI: make ohci-spear a separate driver USB: OHCI: make ohci-at91 a separate driver USB: OHCI: make ohci-s3c2410 a separate driver drivers/usb/host/Kconfig | 30 ++++++- drivers/usb/host/Makefile | 6 ++ drivers/usb/host/ohci-at91.c | 153 ++++++++++++++++------------------- drivers/usb/host/ohci-exynos.c | 167 ++++++++++++++++----------------------- drivers/usb/host/ohci-hcd.c | 108 ------------------------- drivers/usb/host/ohci-omap.c | 156 +++++++++++++----------------------- drivers/usb/host/ohci-omap3.c | 118 +++++++++------------------ drivers/usb/host/ohci-s3c2410.c | 128 +++++++++++++----------------- drivers/usb/host/ohci-spear.c | 140 +++++++++++++------------------- 9 files changed, 374 insertions(+), 632 deletions(-) -- 1.7.9.5

10 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel July 2013