Calendar Week 41: Here is test result summary for Linaro ubuntu image on
following boards:
1) ARM Versatile Express A9;
2) Samsung Origen;
3) TI Panda Board 4430;
4) TI Panda Board 4460.
Synopsis: No change on feature status for vexpress A9 & Samsung Origen
boards. Both HDMI & DVI-D back to work on Panda 4430 & 4460. For SD card
flashing, now command "dd" backs to work on all images.
1. vexpress A9 + ubuntu (Column AD):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV…
Features' status is exactly same as previous week.
2. Origen + ubuntu (Column Y):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowN…
Features' status is exactly same as previous week.
3. Panda 4430 + ubuntu (Column AA):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ…
Audio over HDMI doesn't work, and this causes no sound can be heard when
using "rhythmbox" to play music. Bluetooth now let system crashes again,
after pairing process. Also, system crashes during the Power Management
test "lava-test run pwrmgmt", with log output flushing in serial console.
4. Panda 4460 + ubuntu (Column Y):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ…
The test result on Panda 4460 is quite different with Panda 4430. On TI
Panda 4460 board, Audio over HDMI works well, Bluetooth headset works well,
and Power Management test works well. Even suspend / resume starts to work,
although many error log output flushes in serial console.
For the previous week (Calendar week 40) summary, please refer to
attachment.
Thank you.
Best Regards
Botao Sun
Hi Andrey,
I was just thinking, it would be good if we have another config fragment in
linaro/ to enable kernel debug config options like: CONFIG_DEBUG_INFO.
What do you think?
--
viresh
This patch introduces os save and restore mechanism for v7.1 debug and
self-hosted debuggers.
It enables the os to save DBGDSCR before powerdown and restore it when power
is restored.
The clearing of the os lock in the restore function kick-starts the debug
logic again.
The os save and restore routines are hooked into the CPU PM event notifier
chain. CPU PM events are used to save and restore per-cpu context when a
single CPU is preparing to enter or has exited a low power state.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
---
Hi Viresh,
this patch is for the upcoming Linaro release.
Tested on TC2 big.LITTLE testchip (cpuidle, on both A7 and A15 clusters).
The patch is against 8f18a4e pdsw-ci:29418/kernel, branch
origin/linaro-lt-integration-linaro-vexpress.
Review comment from Liviu fixed.
arch/arm/kernel/hw_breakpoint.c | 57 +++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 281bf33..eed4d0c 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -28,6 +28,7 @@
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>
#include <linux/smp.h>
+#include <linux/cpu_pm.h>
#include <asm/cacheflush.h>
#include <asm/cputype.h>
@@ -42,6 +43,11 @@ static DEFINE_PER_CPU(struct perf_event *, bp_on_reg[ARM_MAX_BRP]);
/* Watchpoint currently in use for each WRP. */
static DEFINE_PER_CPU(struct perf_event *, wp_on_reg[ARM_MAX_WRP]);
+#ifdef CONFIG_CPU_PM
+/* Storage for OS Save and Restore. */
+static DEFINE_PER_CPU(u32, cpu_dscr);
+#endif
+
/* Number of BRP/WRP registers on this CPU. */
static int core_num_brps;
static int core_num_wrps;
@@ -990,6 +996,55 @@ static struct notifier_block __cpuinitdata dbg_reset_nb = {
.notifier_call = dbg_reset_notify,
};
+#ifdef CONFIG_CPU_PM
+static void os_save(int cpu)
+{
+ /* Set OS Lock. */
+ asm volatile("mcr p14, 0, %0, c1, c0, 4" : : "r" (0xC5ACCE55));
+ isb();
+
+ /* Save DSCRext. */
+ ARM_DBG_READ(c2, 2, per_cpu(cpu_dscr, cpu));
+}
+
+static void os_restore(int cpu)
+{
+ /* Restore DSCRext. */
+ ARM_DBG_WRITE(c2, 2, per_cpu(cpu_dscr, cpu));
+
+ /* Clear OS Lock. */
+ asm volatile("mcr p14, 0, %0, c1, c0, 4" : : "r" (0));
+ isb();
+}
+
+static int dbg_cpu_pm_notify(struct notifier_block *self, unsigned long action,
+ void *v)
+{
+ int cpu = smp_processor_id();
+
+ if (action == CPU_PM_ENTER)
+ os_save(cpu);
+ else if (action == CPU_PM_EXIT)
+ os_restore(cpu);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __cpuinitdata dbg_cpu_pm_nb = {
+ .notifier_call = dbg_cpu_pm_notify,
+};
+
+static void __init pm_init(void)
+{
+ if (get_debug_arch() == ARM_DEBUG_ARCH_V7_1)
+ cpu_pm_register_notifier(&dbg_cpu_pm_nb);
+}
+#else
+static inline void pm_init(void)
+{
+}
+#endif
+
static int __init arch_hw_breakpoint_init(void)
{
u32 dscr;
@@ -1048,6 +1103,8 @@ static int __init arch_hw_breakpoint_init(void)
/* Register hotplug notifier. */
register_cpu_notifier(&dbg_reset_nb);
+
+ pm_init();
return 0;
}
arch_initcall(arch_hw_breakpoint_init);
--
1.7.9.5
The discussion about having different cpus on the system with
different latencies bring us to a first attemp by adding a
pointer in the cpuidle_device to the states array.
But as Rafael suggested, it would make more sense to create a
driver per cpu [1].
This patch adds support for multiple cpuidle drivers.
It creates a per cpu cpuidle driver pointer.
In order to not break the different drivers, the function cpuidle_register_driver
assign for each cpu, the driver.
The multiple driver support is optional and if it is not set, the cpuide driver
core code remains the same (except some code reorganisation).
I did the following tests compiled, booted, tested without/with CONFIG_CPU_IDLE,
with/without CONFIG_CPU_IDLE_MULTIPLE_DRIVERS.
Tested on Core2 Duo T9500 with acpi_idle [and intel_idle]
Tested on ARM Dual Cortex-A9 U8500 (aka Snowball)
[1] http://www.spinics.net/lists/linux-acpi/msg37921.html
Daniel Lezcano (4):
cpuidle : move driver's refcount to cpuidle
cpuidle : move driver checking within the lock section
cpuidle - prepare the driver core to be multi drivers aware
cpuidle - support multiple drivers
drivers/cpuidle/Kconfig | 9 ++
drivers/cpuidle/cpuidle.c | 24 ++++--
drivers/cpuidle/driver.c | 194 ++++++++++++++++++++++++++++++++++++++-------
drivers/cpuidle/sysfs.c | 50 +++++++++---
include/linux/cpuidle.h | 9 ++-
5 files changed, 238 insertions(+), 48 deletions(-)
--
1.7.5.4
Hi,
We are potentially interested in contributing to the alsa UCM for Android initiative.
Is there still some activities around that?
Thanks
Regards,
Sebastien
[cid:image001.png@01CDA7CF.6B9F6710]
Sebastien Le Duc | Tel: +33 476 58 54 14 | Mobile: +33 684 43 07 00
APE | Audio Technical Leader
ST online: www.st.com<http://www.st.com/> | Follow us on twitter: @st_world<http://twitter.com/#!/ST_World>
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be <=15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get = vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = "cpufreq_vexpress",
+ .name = "vexpress-bL",
.attr = vexpress_cpufreq_attr,
};
--
1.7.12.rc2.18.g61b472e
Hi all,
I found an interesting health failure today on origen07
http://validation.linaro.org/lava-server/scheduler/job/35016/log_file
When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a "reboot", which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job).
What then started alarm bells ringing was that I saw this:
1261680 bytes read
reading uInitrd
1532597 bytes read
reading board.dtb
** Unable to read "board.dtb" from mmc 0:5 **
So whatever the test image was, it was expecting a device tree blob, which I would have assumed would have to have been installed during deploy_linaro_image() being that if there is one it should just be part of the test boot deployment.
So I looked at the log from the previous job:
http://validation.linaro.org/lava-server/scheduler/job/34938/log_file#entry…
and sure enough, you'll see at that mark the same issue.
So there are two things:
1) There's some twisted logic in the dispatcher that's making it do odd things if it starts off in u-boot
2) Do we have an issue with dtbs not being handled properly by lava, or is it just that the hwpack was incomplete?
Thanks
Dave
Hi All,
There's a scheduled downtime for 30 min, tomorrow (Thursday) at 19:00UTC.
We plan to increase the disk space available on people.linaro.org.
Thanks.
Cheers,
--
Fathi Boudra
Linaro Release Manager | LAVA Project Manager
Linaro.org | Open source software for ARM SoCs