linaro-dev January 2013

linaro-dev@lists.linaro.org

82 participants
82 discussions

by Rob Clark

Btw, not sure if any of you have seen the 0-day kbuild setup that intel has.. https://lists.01.org/mailman/listinfo/kbuild runs various builds for different archs on every commit with different configs, randconfig, etc. And various checks with sparse, smatch, etc. Seems kinda useful, and would be a worthwhile goal to get arm arch to the point of "it just compiles and boots" like x86 is, vs arm which has a lot higher tendency to be broken if you don't have the right kernel config, etc. I guess on x86, they boot test all the kernels too on VMs. Perhaps we could go one better with something tied in to lava? BR, -R

12 years, 3 months

New LAVA filter features: API and result comparison

by Michael Hudson-Doyle

Hi all, A while ago the LAVA team added support for "filters" (as briefly described in http://article.gmane.org/gmane.linux.linaro.devel/13043). A few days ago, we deployed two enhancements to this feature: 1. The first is an API to access filter results. This is documented at: https://validation.linaro.org/lava-server/api/help/#dashboard.get_filter_re… https://validation.linaro.org/lava-server/api/help/#dashboard.get_filter_re… The idea is that this will allow LAVA's users to process the data in LAVA however they like (graphs or notifications based on complicated criteria) without having to get the LAVA team to implement features for them. 2. The second is the ability to compare filter results in the web UI. Find a filter, such as: https://validation.linaro.org/lava-server/dashboard/filters/~mwhudson/pmqa-… click "compare builds", click two builds and click the link that appears to see a comparison such as: https://validation.linaro.org/lava-server/dashboard/filters/~mwhudson/pmqa-… We hope these features improve your experience with LAVA. Let us know of any problems you have with them! Cheers, mwh

12 years, 3 months

[ANNOUNCE] linux-linaro kernel schedule for 13.01

by Andrey Konovalov

Greetings, The current 13.01 schedule has been published on wiki: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule Initial versions of llct and ll trees has been pushed to g.l.o, kernel/linux-linaro-tracking.git yesterday. The 13.01 release would be v3.8-rc4 based (tentative). Some changes vs 12.12: * new topic in ll for better Snowball support. Currently this is device tree, serial console, emmc, ethernet. * the perf-android patch(es) would be a separate ll topic. Thanks, Andrey

12 years, 3 months

[PATCH] arm64: vexpress: Select ARCH_REQUIRE_GPIOLIB for PLAT_VEXPRESS

by Jon Medhurst (Tixy)

Patch 25c92a37a (arm64: Always select ARM_AMBA and GENERIC_GPIO) expects platforms to have GPIO so we need to make sure vexpress always has this by selecting ARCH_REQUIRE_GPIOLIB. Without this change drivers like MMC fail to compile due to missing gpio definitions like: In file included from include/linux/gpio.h:48:0, from drivers/mmc/core/slot-gpio.c:12: include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep': include/asm-generic/gpio.h:235:2: error: implicit declaration of function '__gpio_get_value' Signed-off-by: Jon Medhurst <tixy(a)linaro.org> --- Hi Catalin, not sure if this is the correct fix, but it works and matches 32-bit vexpress. arch/arm64/platforms/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/platforms/Kconfig b/arch/arm64/platforms/Kconfig index d2fc931..26d1d14 100644 --- a/arch/arm64/platforms/Kconfig +++ b/arch/arm64/platforms/Kconfig @@ -1,6 +1,6 @@ config PLAT_VEXPRESS bool "ARMv8 software model (Versatile Express)" - select ARCH_WANT_OPTIONAL_GPIOLIB + select ARCH_REQUIRE_GPIOLIB select ARM_AMBA select CLKDEV_LOOKUP select ARM_GIC -- 1.7.10.4

12 years, 3 months

Question regarding broadcast timer/cpuidle and /proc/interrupts

by Daniel Lezcano

Hi All, I have a question regarding the behavior of cpuidle on pandaboard. 1. cpuidle is enabled 2. The deep idle states seem to be reach for i in $(find /sys/devices/system/cpu -name "usage"); do echo "$i : $(cat $i)"; done /sys/devices/system/cpu/cpu0/cpuidle/state0/usage : 7049 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage : 1341 /sys/devices/system/cpu/cpu1/cpuidle/state0/usage : 6318 /sys/devices/system/cpu/cpu1/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu1/cpuidle/state2/usage : 1341 3. Regarding the cpuidle driver code : the "state1" and "state2" are coupled states where the broadcast timer is used instead of the local timer. I assume this is because they go down when we reach these idle states. 4. The content of /proc/interrupts shows no broadcast timer used at all. ... IPI1: 0 0 Timer broadcast interrupts ... Shouldn't be the broadcast timer used sometimes ? or did I miss something ? Thanks. -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

12 years, 3 months

[PATCH] clk: allow reparenting of a clock to the orphan list

by Rajagopal Venkat

Allow reparenting of a clock(multiple and single parent) to the orphan list when new parent clock is NULL. Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org> --- drivers/clk/clk.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index e964994..5c9277a 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1102,7 +1102,7 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent) struct dentry *new_parent_d; #endif - if (!clk || !new_parent) + if (!clk) return; hlist_del(&clk->child_node); @@ -1140,11 +1140,14 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent) { struct clk *old_parent; unsigned long flags; - int ret = -EINVAL; - u8 i; + int ret = 0; + u8 i = 0; old_parent = clk->parent; + if (clk->num_parents == 1 || !parent) + goto migrate; + if (!clk->parents) clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents), GFP_KERNEL); @@ -1165,11 +1168,13 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent) } if (i == clk->num_parents) { + ret = -EINVAL; pr_debug("%s: clock %s is not a possible parent of clock %s\n", __func__, parent->name, clk->name); goto out; } +migrate: /* migrate prepare and enable */ if (clk->prepare_count) __clk_prepare(parent); @@ -1181,7 +1186,8 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent) spin_unlock_irqrestore(&enable_lock, flags); /* change clock input source */ - ret = clk->ops->set_parent(clk->hw, i); + if (clk->ops->set_parent) + ret = clk->ops->set_parent(clk->hw, i); /* clean up old prepare and enable */ spin_lock_irqsave(&enable_lock, flags); @@ -1215,7 +1221,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent) if (!clk || !clk->ops) return -EINVAL; - if (!clk->ops->set_parent) + if (clk->num_parents > 1 && !clk->ops->set_parent) return -ENOSYS; /* prevent racing with updates to the clock topology */ @@ -1226,7 +1232,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent) /* propagate PRE_RATE_CHANGE notifications */ if (clk->notifier_count) - ret = __clk_speculate_rates(clk, parent->rate); + ret = __clk_speculate_rates(clk, parent ? parent->rate : 0); /* abort if a driver objects */ if (ret == NOTIFY_STOP) -- 1.7.10.4

12 years, 3 months

[PATCH] clk: remove unreachable code

by Rajagopal Venkat

while reparenting a clock, NULL check is done for clock in consideration and its new parent. So re-check is not required. If done, else part becomes unreachable. Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org> --- drivers/clk/clk.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 251e45d..f896584 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1048,10 +1048,7 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent) hlist_del(&clk->child_node); - if (new_parent) - hlist_add_head(&clk->child_node, &new_parent->children); - else - hlist_add_head(&clk->child_node, &clk_orphan_list); + hlist_add_head(&clk->child_node, &new_parent->children); #ifdef CONFIG_COMMON_CLK_DEBUG if (!inited) -- 1.7.10.4

12 years, 3 months

[PATCH 1/5] ARM: exynos: factor out the idle states

by Daniel Lezcano

The states are defined in the driver. We can get rid of the intermediate cpuidle states initialization and the memcpy by directly initializing the driver states. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- arch/arm/mach-exynos/cpuidle.c | 45 +++++++++++++++------------------------- 1 file changed, 17 insertions(+), 28 deletions(-) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c index 0509241..f8dd1cd 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -40,24 +40,25 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev, struct cpuidle_driver *drv, int index); -static struct cpuidle_state exynos4_cpuidle_set[] __initdata = { - [0] = ARM_CPUIDLE_WFI_STATE, - [1] = { - .enter = exynos4_enter_lowpower, - .exit_latency = 300, - .target_residency = 100000, - .flags = CPUIDLE_FLAG_TIME_VALID, - .name = "C1", - .desc = "ARM power down", - }, -}; - static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device); static struct cpuidle_driver exynos4_idle_driver = { .name = "exynos4_idle", .owner = THIS_MODULE, .en_core_tk_irqen = 1, + .states = { + [0] = ARM_CPUIDLE_WFI_STATE, + [1] = { + .enter = exynos4_enter_lowpower, + .exit_latency = 300, + .target_residency = 100000, + .flags = CPUIDLE_FLAG_TIME_VALID, + .name = "C1", + .desc = "ARM power down", + }, + }, + .state_count = 2, + .safe_state_index = 0, }; /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */ @@ -192,33 +193,21 @@ static void __init exynos5_core_down_clk(void) static int __init exynos4_init_cpuidle(void) { - int i, max_cpuidle_state, cpu_id; + int cpu_id; struct cpuidle_device *device; - struct cpuidle_driver *drv = &exynos4_idle_driver; if (soc_is_exynos5250()) exynos5_core_down_clk(); - /* Setup cpuidle driver */ - drv->state_count = (sizeof(exynos4_cpuidle_set) / - sizeof(struct cpuidle_state)); - max_cpuidle_state = drv->state_count; - for (i = 0; i < max_cpuidle_state; i++) { - memcpy(&drv->states[i], &exynos4_cpuidle_set[i], - sizeof(struct cpuidle_state)); - } - drv->safe_state_index = 0; cpuidle_register_driver(&exynos4_idle_driver); for_each_cpu(cpu_id, cpu_online_mask) { device = &per_cpu(exynos4_cpuidle_device, cpu_id); device->cpu = cpu_id; - if (cpu_id == 0) - device->state_count = (sizeof(exynos4_cpuidle_set) / - sizeof(struct cpuidle_state)); - else - device->state_count = 1; /* Support IDLE only */ + /* Support IDLE only */ + if (cpu_id != 0) + device->state_count = 1; if (cpuidle_register_device(device)) { printk(KERN_ERR "CPUidle register device failed\n,"); -- 1.7.9.5

12 years, 3 months

Test Result Summary of Calendar Week 3, 2013 for Linux Linaro ubuntu Quantal.

by Botao Sun

Calendar Week 2, 2013: Here is test result summary for Linux Linaro ubuntu Quantal image on following boards: 1) ARM Versatile Express A9; 2) Samsung Origen; 3) TI Panda 4430; 4) TI Panda 4460; 5) ST Ericsson Snowball. Synopsis: Snowball booting failed with kernel panic; Device Tree is only supported on Samsung Origen, and no Internet connection on Samsung Origen board. 1. ARM Versatile Express A9 + Linux Linaro Quantal (Column G): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV… It keeps exactly same status as last test result: only "Halt" & "Device Tree" test failed, all other features work well. 2. Samsung Origen + Linux Linaro Quantal (Column G): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowN… It keeps exactly same status as last test result. The Internet connection is still unavailable. 3. TI Panda 4430 + Linux Linaro Quantal (Column G): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… It keeps exactly same status as last test result: Device Tree directory is empty, and there are some power management test cases failed. All other features are OK. 4. TI Panda 4460 + Linux Linaro Quantal (Column G): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… It keeps exactly same status as last test result: everything works well except Device Tree - the directory is empty, same as TI Panda 4430. 5. ST Ericsson Snowball + Linux Linaro Quantal (Column G): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFJ4X… Board booted failed with Kernel Panic. For the previous week test summary (Calendar week 2), please refer to attachment. Thank you. Best Regards Botao Sun

12 years, 3 months

RE: [PATCH] Genericise CPUIdle for ARM big.LITTLE

by Nicolas Pitre

On Wed, 16 Jan 2013, Mark Hambleton wrote: > > > > > +obj-$(CONFIG_BIG_LITTLE) += arm_big_little.o > > > > There is nothing big.LITTLE specific in all of this, so arm_idle.c would > > > >be better. > > > > > > I figured that because the current version calls into the big.little platform power framework (bL_entry.c) and makes calls into that framework that this wasn't totally generic and is dependant > > > upon that code. The version of the cpuidle driver won't build unless that code is built in, so I still think this is more appropriate naming, I could call it bL_* but I suspect someone will object to that > > upstream because of the mixed case. > > > > Well, calling it big.LITTLE, bL or whatever else describing a big and a > > LITTLE is wrong IMHO because it makes people think this a driver for > > big.LITTLE ARM platforms. And it is not, if we ever manage to make it > > generic. > > You are missing the point, this driver is dependent on the big.little > framework that is being upstreamed by Nicolas / Dave, so it is > big.little specific (specific to the big.little framework). When a > truly generic version is available this one could be removed. The b.L framework is not really b.L specific. As such I'll try to rename it before it gets merged. Somehow, finding a good name isn't trivial. > > I fail to understand why we want to make this code generic NOW, ARM > > kernel is not ready for that and to be honest I do not see why it has > > to be done now. > > Because we are about to take a copy of this code and make some tiny > modifications to it to make it run on our platform, and this seemed a > better solution (I suspect a few others are about to do the same, like > they used to do with platsmp and all that other good stuff that > Nicolas / Dave have been cleaning up). > > Basically, if you guys really aren't interested in a step towards less > code lurking in mach-vexpress we can carry patches to make things > work, just seemed like an easy enough win... To be honest, your patch is a good thing. The driver definitely has to move out of mach-vexpress. It is just not the fish we are (I am) frying at the moment. But I think Tixy could just pick it up into the ARM »LT tree for now. Obviously, the driver will evolve over time. That may as well happen in its proper location. Nicolas

12 years, 3 months

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev January 2013