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
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
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
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
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
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