linaro-dev October 2012

linaro-dev@lists.linaro.org

76 participants
108 discussions

by viresh kumar

Hi Pawel, Is there a way to skip the motherboard BIOS too? I know there is a way to autoboot from bootmon, which is well described here: https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy But, i am looking for something, which can even run the "reboot" command on BIOS. -- viresh

12 years, 2 months

Re: Re: [PATCH v4 0/3] devfreq: Add support for devices which can idle

by MyungJoo Ham

> On 4 October 2012 18:06, MyungJoo Ham <myungjoo.ham(a)samsung.com> wrote: > >> This patchset updates devfreq core to add support for devices > >> which can idle. When device idleness is detected perhaps > >> through runtime-pm, need some mechanism to suspend devfreq > >> load monitoring and resume when device is back online. > >> > >> patch 1 introduce core design changes - per device work, decouple > >> delayed work from core and event based interaction. > >> patch 2 add devfreq suspend and resume apis. > >> patch 3 add new sysfs attribute for governor predicted next target > >> frequency and callback for current device frequency. > >> > >> The existing devfreq apis are kept intact. Two new apis > >> devfreq_suspend_device() and devfreq_resume_device() are > >> added to support suspend/resume of device devfreq. > > > > Could you please tell me which version you have rebased? > > > > It seems that the patchset has issues on applying over 3.6. > > (tried at a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) > > These patches are rebased against Linus tree. > > The 203b42f7317494ae5e5efc7be6fb7f29c927f102 commit, which > renames INIT_DELAYED_WORK_DEFERRABLE to > INIT_DEFERRABLE_WORK could be the reason for patchset > not applying over 3.6. Ok, I'll try and test over Linus' latest. > > > > > > >> > >> Changes since v1: > >> - revised locking mechanism > >> - added kerneldoc comments for load monitoring helper functions > >> - fixed minor review comments > >> > >> Changes since v2: > >> - added new helper function for polling interval update > >> - handled work suspend/resume contention between devfreq driver > >> and sysfs > >> > >> Changes since v3: > >> - added additonal checks in suspend/resume to avoid invalid usage of apis > >> - added check in devfreq_monitor_start, not to start monitoring when > >> polling_ms is set to zero. > >> > >> -- > >> Rajagopal Venkat (3): > >> devfreq: Core updates to support devices which can idle > >> devfreq: Add suspend and resume apis > >> devfreq: Add current freq callback in device profile > >> > >> Documentation/ABI/testing/sysfs-class-devfreq | 15 +- > >> drivers/devfreq/devfreq.c | 481 ++++++++++++-------------- > >> drivers/devfreq/governor.h | 13 + > >> drivers/devfreq/governor_performance.c | 16 +- > >> drivers/devfreq/governor_powersave.c | 16 +- > >> drivers/devfreq/governor_simpleondemand.c | 33 ++ > >> drivers/devfreq/governor_userspace.c | 23 +- > >> include/linux/devfreq.h | 49 +-- > >> 8 files changed, 353 insertions(+), 293 deletions(-) > >> > >> -- > >> 1.7.11.3 > >> > >> > >> > >> > >> > >> > >> > >> > > > > -- > Regards, > Rajagopal > > > > > > >

12 years, 2 months

Re: [PATCH v4 0/3] devfreq: Add support for devices which can idle

by MyungJoo Ham

> This patchset updates devfreq core to add support for devices > which can idle. When device idleness is detected perhaps > through runtime-pm, need some mechanism to suspend devfreq > load monitoring and resume when device is back online. > > patch 1 introduce core design changes - per device work, decouple > delayed work from core and event based interaction. > patch 2 add devfreq suspend and resume apis. > patch 3 add new sysfs attribute for governor predicted next target > frequency and callback for current device frequency. > > The existing devfreq apis are kept intact. Two new apis > devfreq_suspend_device() and devfreq_resume_device() are > added to support suspend/resume of device devfreq. Could you please tell me which version you have rebased? It seems that the patchset has issues on applying over 3.6. (tried at a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) > > Changes since v1: > - revised locking mechanism > - added kerneldoc comments for load monitoring helper functions > - fixed minor review comments > > Changes since v2: > - added new helper function for polling interval update > - handled work suspend/resume contention between devfreq driver > and sysfs > > Changes since v3: > - added additonal checks in suspend/resume to avoid invalid usage of apis > - added check in devfreq_monitor_start, not to start monitoring when > polling_ms is set to zero. > > -- > Rajagopal Venkat (3): > devfreq: Core updates to support devices which can idle > devfreq: Add suspend and resume apis > devfreq: Add current freq callback in device profile > > Documentation/ABI/testing/sysfs-class-devfreq | 15 +- > drivers/devfreq/devfreq.c | 481 ++++++++++++-------------- > drivers/devfreq/governor.h | 13 + > drivers/devfreq/governor_performance.c | 16 +- > drivers/devfreq/governor_powersave.c | 16 +- > drivers/devfreq/governor_simpleondemand.c | 33 ++ > drivers/devfreq/governor_userspace.c | 23 +- > include/linux/devfreq.h | 49 +-- > 8 files changed, 353 insertions(+), 293 deletions(-) > > -- > 1.7.11.3 > > > > > > > >

12 years, 2 months

Kernel 3.6 build bug with Linaro 4.7 toolchains

by Tim Bird

When I try to build the Linux kernel version 3.6 with the gcc-4.7 nightly build Linaro toolchains, $ arm-eabi-gcc --version arm-eabi-gcc (Linaro GCC 4.7-2012.09-1~dev) 4.7.2 20120910 (prerelease) $ arm-eabi-as --version GNU assembler (Linux/GNU Binutils) 2.23.51.0.3.20120918 I get a compiler error (actually, assembler error): AS arch/arm/lib/copy_from_user.o /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S: Assembler messages: /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r3,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:118: Error: selected processor does not support ARM mode `ldralt r3,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:119: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:120: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:121: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:122: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:123: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:124: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:173: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4' make[2]: *** [arch/arm/lib/copy_from_user.o] Error 1 make[1]: *** [arch/arm/lib] Error 2 make[1]: *** Waiting for unfinished jobs.... This appears to be related to the following bug report for binutils: http://sourceware.org/ml/binutils/2012-09/msg00128.html I'm compiling the kernel for PandaBoard Any ideas for work-arounds or fixes for this? Note that the ldralt instruction doesn't actually appear in copy_template.S (maybe it's coming from a macro?) -- Tim ============================= Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment =============================

12 years, 2 months

[GIT PULL]: big LITTLE MP v9

by Viresh Kumar

Hi Andrey, Please PULL b.L MP V9 branch from my tree. Updates: ----------- - Based on v3.6 - Stats: - Total Patches: 63 - New Patches: 0 - Merged Patches: 3 - f319da0 sched: Fix load avg vs cpu-hotplug - 641f145 hwmon: (coretemp) Use get_online_cpus to avoid races involving CPU hotplug - 1ec3ddf hwmon: (via-cputemp) Use get_online_cpus to avoid races involving CPU hotplug - Dropped Patches: 0 NOTE: Below pull request is generated against v3.6 instead of linux-linaro. ------------------------8<------------------------------------------------ The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-v9 for you to fetch changes up to 619245dc532b1d1b59cd414ae4d87e9b3ae42c65: Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v2', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1', 'rcu-hotplug-v1', 'arm-multi_pmu_v1', 'scheduler-misc-v1' and 'config-fragments' into big-LITTLE-MP-v9 (2012-10-03 16:29:42 +0530) ---------------------------------------------------------------- Axel Lin (1): ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c Ben Segall (1): sched: maintain per-rq runnable averages Jon Hunter (1): ARM: PMU: Add runtime PM Support Jon Medhurst (5): configs: Initial core configs configs: Make CONFIG_MODULES part of linaro-base configs: Replace CONFIG_PERF_COUNTERS with CONFIG_PERF_EVENTS configs: android: Enable FB_EARLYSUSPEND configs: android: Enable CONFIG_INPUT_UINPUT to get aidb working Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Morten Rasmussen (10): sched: entity load-tracking load_avg_ratio sched: Task placement for heterogeneous systems based on task load-tracking sched: Forced task migration on heterogeneous systems sched: Introduce priority-based task migration filter ARM: Add HMP scheduling support for ARM architecture ARM: sched: Use device-tree to provide fast/slow CPU list for HMP ARM: sched: Setup SCHED_HMP domains sched: Add ftrace events for entity load-tracking sched: Add HMP task migration ftrace event sched: SCHED_HMP multi-domain task migration control Paul E. McKenney (4): rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread hotplug: Fix UP bug in smpboot hotplug code rcu: Remove _rcu_barrier() dependency on __stop_machine() rcu: Disallow callback registry on offline CPUs Paul Turner (15): sched: track the runnable average on a per-task entitiy basis sched: aggregate load contributed by task entities on parenting cfs_rq sched: maintain the load contribution of blocked entities sched: add an rq migration call-back to sched_class sched: account for blocked load waking back up sched: aggregate total task_group load sched: compute load contribution by a group entity sched: normalize tg load contributions against runnable time sched: maintain runnable averages across throttled periods sched: replace update_shares weight distribution with per-entity computation sched: refactor update_shares_cpu() -> update_blocked_avgs() sched: update_cfs_shares at period edge sched: make __update_entity_runnable_avg() fast sched: implement usage tracking sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking Ricardo Salveti de Araujo (7): configs: moving previous ubuntu.conf as ubuntu-minimal and creating a full ubuntu one configs: ubuntu: be compatible with the enforce script configs: ubuntu: disabling CODA_FS, seems to be broken atm configs: ubuntu: disabling CGROUPS as default configs: ubuntu: updating configs for 3.5 configs: ubuntu: disabling CONFIG_MTD_NAND_NANDSIM=m, breaking build config: ubuntu: ATH6KL should be platform dependent Silas Boyd-Wickizer (4): Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Sudeep KarkadaNagesha (9): ARM: pmu: remove arm_pmu_type enumeration ARM: perf: move irq registration into pmu implementation ARM: perf: allocation of cpu_pmu at init time ARM: perf: change multiple arm_pmu function parameters to struct perf_event ARM: perf: rework on armv7_pmnc_counter_valid ARM: perf: define per-cpu arm_pmu instead of a single global pointer ARM: perf: register the init functions with the bindings ARM: perf: add support for per-cluster/multiple PMUs ARM: perf: save/restore pmu registers in pm notifier Thomas Gleixner (6): rcu: Yield simpler kthread: Implement park/unpark facility smpboot: Provide infrastructure for percpu hotplug threads softirq: Use hotplug thread infrastructure watchdog: Use hotplug thread infrastructure infiniband: ehca: Use hotplug thread infrastructure Tushar Behera (1): linaro/configs: ubuntu: Disable support for generic OHCI platform driver Vincent Guittot (2): sched: cpu_power: enable ARCH_POWER sched: Fix nohz_idle_balance() Viresh Kumar (4): configs: Add config fragments for big LITTLE MP linaro/configs: Update big LITTLE MP fragment for task placement work config-frag/big-LITTLE: Use device-tree to provide fast/slow CPU list for HMP Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v2', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1', 'rcu-hotplug-v1', 'arm-multi_pmu_v1', 'scheduler-misc-v1' and 'config-fragments' into big-LITTLE-MP-v9 Will Deacon (6): ARM: perf: add devicetree bindings for 11MPcore, A5, A7 and A15 PMUs ARM: pmu: remove unused reservation mechanism ARM: perf: remove mysterious compiler barrier ARM: perf: probe devicetree in preference to current CPU ARM: perf: prepare for moving CPU PMU code into separate file ARM: perf: move CPU-specific PMU handling code into separate file

12 years, 2 months

[RFC PATCH] bootwrapper: Add --secure option to boot the kernel in the Secure world

by Dave Martin

Currently, the bootwrapper switches unconditionally to NS Hyp mode, which prevents successful execution of a kernel which expects to start in the Secure world. This patch adds a --secure command-line option to enable Secure world booting. NS HYP remains the default. Signed-off-by: Dave Martin <dave.martin(a)linaro.org> --- Note that this is just an RFC -- I've not tested it yet. With some additional CCI and CPU reset related hacks, I hope to get the in-kernel switcher kernel booting with this. boot.S | 36 ++++++++++++++++++++++++++++-------- boot.h | 29 +++++++++++++++++++++++++++++ semi_loader.c | 11 +++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) create mode 100644 boot.h diff --git a/boot.S b/boot.S index 727119a..64cd0fa 100644 --- a/boot.S +++ b/boot.S @@ -7,18 +7,28 @@ * found in the LICENSE.txt file. */ +#include "boot.h" + .syntax unified .arch_extension sec .arch_extension virt .text -.macro enter_hyp - @ We assume we're entered in Secure Supervisor mode. To - @ get to Hyp mode we have to pass through Monitor mode - @ and NS-Supervisor mode. Note that there is no way to - @ return to the Secure world once we've done this. - @ +.macro enter_kernel_state @ This will trash r10 and r11. + @ We assume we're entered in Secure Supervisor mode. + + @ If requested, stay in Secure SVC to enter the kernel: + + ldr r10, =kernel_boot_mode + ldr r10, [r10] + cmp r10, #BOOT_MODE_S_SVC + beq 1f + + @ Otherwise: to get to Hyp mode we have to pass through Monitor + @ mode and NS-Supervisor mode. Note that there is no way to + @ return to the Secure world once we've done this. + ldr r10, =vectors mcr p15, 0, r10, c12, c0, 1 @ Monitor vector base address @ Switch to monitor mode, which will set up the HVBAR and @@ -26,7 +36,9 @@ smc #0 @ Now we're in NS-SVC, make a Hyp call to get into Hyp mode hvc #0 + @ We will end up here in NS-Hyp. +1: .endm .align 5 @@ -128,7 +140,7 @@ start: @ @ Secondary CPUs (following the RealView SMP booting protocol) @ - enter_hyp + enter_kernel_state ldr r1, =fs_start - 0x100 adr r2, 1f @@ -198,7 +210,7 @@ __boot_kernel: stmfd sp!, {r1-r3} ldmia sp, {r0-r3} - enter_hyp + enter_kernel_state bx r4 .type __boot_kernel, %function @@ -214,3 +226,11 @@ kernel_cmd: .asciz KCMD #endif kernel_cmd_end: + + +.bss +.align 2 + +.globl kernel_boot_mode +kernel_boot_mode: + .skip 4 @ defaults to BOOT_MODE_NS_HYP (0) diff --git a/boot.h b/boot.h new file mode 100644 index 0000000..b80227e --- /dev/null +++ b/boot.h @@ -0,0 +1,29 @@ +/* + * Copyright (c) 2012 Linaro Limited + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * 3. Neither the name of Linaro Limited nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + */ + +#ifndef BOOT_H +#define BOOT_H + +#define BOOT_MODE_NS_HYP 0 +#define BOOT_MODE_S_SVC 1 + +#ifndef __ASSEMBLER__ +extern int kernel_boot_mode; +#endif /* ! __ASSEMBLER__ */ + +#endif /* BOOT_H */ diff --git a/semi_loader.c b/semi_loader.c index cbe911c..ef927e7 100644 --- a/semi_loader.c +++ b/semi_loader.c @@ -17,6 +17,7 @@ */ #include <string.h> +#include "boot.h" #include "libfdt.h" #include "semihosting.h" #include "semi_loader.h" @@ -49,6 +50,7 @@ static void _print_info(char const **strings) #define CMDLINE_NOINITRD "--no-initrd" #define CMDLINE_DTB "--dtb" #define CMDLINE_FDT "--fdt" /* deprecated */ +#define CMDLINE_SECURE "--secure" #define CMDLINE_REST "-- " static void _usage_fatal(void) @@ -378,6 +380,7 @@ static char *fdt_arg = (void *)0; static char *dtb_arg = (void *)0; static char *cmdline_arg = (void *)0; static char *noinitrd_arg = (void *)0; +static char *secure_arg = (void *)0; static const struct { char const *option_string; @@ -389,6 +392,7 @@ static const struct { { CMDLINE_NOINITRD, &noinitrd_arg, OPT_BOOL }, { CMDLINE_FDT, &fdt_arg, OPT_ARG }, { CMDLINE_DTB, &dtb_arg, OPT_ARG }, + { CMDLINE_SECURE, &secure_arg, OPT_BOOL }, { CMDLINE_REST, &cmdline_arg, OPT_REST }, }; @@ -476,6 +480,13 @@ args_done: dtb_arg = fdt_arg; } + info("Kernel will be booted in "); + if(secure_arg) { + kernel_boot_mode = BOOT_MODE_S_SVC; + info("Secure SVC mode.\n"); + } else + info("HYP mode.\n"); + /* * Now, proceed to load images and set up ATAGs. * For simplicity, ATAGs are generated even if there is a DTB -- 1.7.4.1

12 years, 2 months

big.LITTLE MP status Oct 2, 2012

by David Zinman

https://wiki.linaro.org/projects/big.LITTLE.MP Blueprint updates ================ https://blueprints.launchpad.net/linaro-power-kernel/+spec/cpuidle-add-cpu-… - moved to 12.10 cycle in order to add acceptance item for upstream acceptance https://blueprints.launchpad.net/linaro-power-kernel/+spec/big.little.mp-ho… - Moved to 12.10, some items could not be completed for the cycle. https://blueprints.launchpad.net/linaro-qa/+spec/task-placement-testing https://blueprints.launchpad.net/linaro-qa/+spec/sched-test-porting-to-andr… - Both blocked due to the TC2 hardware not available to the QA engineer. Roadmap Cards ============== No updates this week General Items ============== TC2 QA Status: no new tests have been completed for this cycle as of yet. Private QA builds containing test code are available. These builds give an added value to Linaro members in that they contain code for more complete testing. For access to the build please contact david.zinman(a)linaro.org or anmar.oueja(a)linaro.org Version 9 of Linaro big.LITTLE MP branch has been released. Full details at: http://lists.linaro.org/pipermail/linaro-dev/2012-October/013845.html Vincent is currently conducting power consumption measurements on TC2 board with an Ubuntu image. An Android image will be also used in the future. Hotplug changes for v3.7 have been submitted upstream for review. Corresponding hotplug tests are being drafted by Naresh in QA. Issues ====== The TC2 hardware is still not in the hands of the Linaro QA engineer, it is currently hung up in customs. Linaro is attempting to expedite delivery. The project plan is at https://docs.google.com/a/linaro.org/document/d/1XI9FaEd6dYfCEDezboF7gWtrTO… -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs

12 years, 2 months

[PATCH 0/3] bootwrapper: Add support for big.LITTLE models

by Jon Medhurst (Tixy)

This mostly boils down to initialising the Cache Coherent Interconnect (CCI). We do this by looking in the device-tree for a CCI node, that way the same semihosting bootwrapper binary can be used on both the big.LITTLE models and on the A15 models which don't have a CCI. [PATCH 1/3] bootwrapper: Allow for multiple clusters in boot CPU [PATCH 2/3] bootwrapper: Factor out parsing of fdt #address-cells [PATCH 3/3] bootwrapper: Initialise CCI device if found in the fdt boot.S | 2 +- semi_loader.c | 104 +++++++++++++++++++++++++++++++++++++++++----------- 2 files changed, 84 insertions(+), 22 deletions(-)

12 years, 2 months

[RFC] timer: Migrate running timer

by Viresh Kumar

Hi Thomas, I haven't tested it much till now. I am sending this patch just to check if the initial idea looks fine to you guys or not. Till now, we weren't migrating a running timer because with migration del_timer_sync() can't detect that the timer's handler yet has not finished. Now, when can we actually to reach to the code (inside __mod_timer()) where base->running_timer == timer ? i.e. We are trying to migrate current timer I can see only following case: - Timer re-armed itself. i.e. Currently we are running interrupt handler of a timer and it rearmed itself from there. At this time user might have called del_timer_sync() or not. If not, then there is no harm in re-arming the timer? Now, when somebody tries to delete a timer, obviously he doesn't want to run it any more for now. So, why should we ever re-arm a timer, which is scheduled for deletion? This patch tries to fix "migration of running timer", assuming above theory is correct :) So, now when we get a call to del_timer_sync(), we will mark it scheduled for deletion in an additional variable. This would be checked whenever we try to modify/arm it again. If it was currently scheduled for deletion, we must not modify/arm it. And so, whenever we reach to the situation where: base->running_timer == timer We are sure, nobody is waiting in del_timer_sync(). We will clear this flag as soon as the timer is deleted, so that it can be started again after deleting it successfully. Waiting for initial comments on it. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- include/linux/timer.h | 1 + kernel/timer.c | 58 +++++++++++++++++++++++++++++---------------------- 2 files changed, 34 insertions(+), 25 deletions(-) diff --git a/include/linux/timer.h b/include/linux/timer.h index 8c5a197..ea36ce9 100644 --- a/include/linux/timer.h +++ b/include/linux/timer.h @@ -22,6 +22,7 @@ struct timer_list { unsigned long data; int slack; + int sched_del; #ifdef CONFIG_TIMER_STATS int start_pid; diff --git a/kernel/timer.c b/kernel/timer.c index 1cf8a91..536e7a3 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -620,6 +620,7 @@ static void do_init_timer(struct timer_list *timer, unsigned int flags, timer->entry.next = NULL; timer->base = (void *)((unsigned long)base | flags); timer->slack = -1; + timer->sched_del = 0; #ifdef CONFIG_TIMER_STATS timer->start_site = NULL; timer->start_pid = -1; @@ -727,38 +728,35 @@ __mod_timer(struct timer_list *timer, unsigned long expires, base = lock_timer_base(timer, &flags); + if (timer->sched_del) { + /* Don't schedule it again, as it is getting deleted */ + ret = -EBUSY; + goto out_unlock; + } + ret = detach_if_pending(timer, base, false); if (!ret && pending_only) goto out_unlock; debug_activate(timer, expires); - /* - * Should we try to migrate timer? - * However we can't change timer's base while it is running, otherwise - * del_timer_sync() can't detect that the timer's handler yet has not - * finished. This also guarantees that the timer is serialized wrt - * itself. - */ - if (likely(base->running_timer != timer)) { #if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP) - if (!pinned && get_sysctl_timer_migration()) - cpu = get_nohz_timer_target(); - else - cpu = smp_processor_id(); -#else + if (!pinned && get_sysctl_timer_migration()) + cpu = get_nohz_timer_target(); + else cpu = smp_processor_id(); +#else + cpu = smp_processor_id(); #endif - new_base = per_cpu(tvec_bases, cpu); - - if (base != new_base) { - /* See the comment in lock_timer_base() */ - timer_set_base(timer, NULL); - spin_unlock(&base->lock); - base = new_base; - spin_lock(&base->lock); - timer_set_base(timer, base); - } + new_base = per_cpu(tvec_bases, cpu); + + if (base != new_base) { + /* See the comment in lock_timer_base() */ + timer_set_base(timer, NULL); + spin_unlock(&base->lock); + base = new_base; + spin_lock(&base->lock); + timer_set_base(timer, base); } timer->expires = expires; @@ -1037,9 +1035,11 @@ EXPORT_SYMBOL(try_to_del_timer_sync); */ int del_timer_sync(struct timer_list *timer) { -#ifdef CONFIG_LOCKDEP + struct tvec_base *base; unsigned long flags; +#ifdef CONFIG_LOCKDEP + /* * If lockdep gives a backtrace here, please reference * the synchronization rules above. @@ -1049,6 +1049,12 @@ int del_timer_sync(struct timer_list *timer) lock_map_release(&timer->lockdep_map); local_irq_restore(flags); #endif + + /* Timer is scheduled for deletion, don't let it re-arm itself */ + base = lock_timer_base(timer, &flags); + timer->sched_del = 1; + spin_unlock_irqrestore(&base->lock, flags); + /* * don't use it in hardirq context, because it * could lead to deadlock. @@ -1056,8 +1062,10 @@ int del_timer_sync(struct timer_list *timer) WARN_ON(in_irq() && !tbase_get_irqsafe(timer->base)); for (;;) { int ret = try_to_del_timer_sync(timer); - if (ret >= 0) + if (ret >= 0) { + timer->sched_del = 0; return ret; + } cpu_relax(); } } -- 1.7.12.rc2.18.g61b472e

12 years, 2 months

Re: Re: [PATCH v3 1/3] devfreq: Core updates to support devices which can idle

by MyungJoo Ham

> On 27 September 2012 13:50, MyungJoo Ham <myungjoo.ham(a)samsung.com> wrote: > >> Prepare devfreq core framework to support devices which > >> can idle. When device idleness is detected perhaps through > >> runtime-pm, need some mechanism to suspend devfreq load > >> monitoring and resume back when device is online. Present > >> code continues monitoring unless device is removed from > >> devfreq core. > >> > >> This patch introduces following design changes, > >> > >> - use per device work instead of global work to monitor device > >> load. This enables suspend/resume of device devfreq and > >> reduces monitoring code complexity. > >> - decouple delayed work based load monitoring logic from core > >> by introducing helpers functions to be used by governors. This > >> provides flexibility for governors either to use delayed work > >> based monitoring functions or to implement their own mechanism. > >> - devfreq core interacts with governors via events to perform > >> specific actions. These events include start/stop devfreq. > >> This sets ground for adding suspend/resume events. > >> > >> The devfreq apis are not modified and are kept intact. > >> > >> Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org> > > > > Hello, > > > > > > I'll do more through review tomorrow (sorry, I was occuppied by > > something other than Linux tasks for a while again); however, > > there are two concerns in this patch. > > > > 1. (minor but may bothersome in some rare but not-ignorable cases) > > Serialization issue between suspend/resume > > functions; this may happen with some failure or interrupts while entering STR or > > unexpected usage of the API at drivers. > > Regarding the invalid usage of suspend/resume apis, we can have > additional checks > something like, > > void devfreq_monitor_suspend(struct devfreq *devfreq) > { > ..... > if (devfreq->stop_polling) > return; > ...... > } > > void devfreq_monitor_resume(struct devfreq *devfreq) > { > ..... > if (!devfreq->stop_polling) > return; > ...... > } > > > > > For example, if devfreq_monitor_suspend() and devfreq_montir_resume() are called > > almost simultaneously, we may execute 1) locked part of suspend, 2) locked part of > > resume, 3) cancel_delayed_work_sync of suspend. > > > > Then, we may have stop_polling = false w/ cancel_delayed_work_sync() in effect. > > > > Let's not assume that suspend() and resume() may called almost simultaneously, > > especially in subsystem core code. (sorry, I missed "not be" between "may" and "called" here) > > > > These devfreq_monitor_suspend() and devfreq_monitor_resume() functions are > executed when device idleness is detected. Perhaps, > - using runtime-pm: the runtime_suspend() and runtime_resume() are mutually > exclusive and is guaranteed not to run in parallel. > - driver may have its own mechanism: in my opinion, driver should ensure > suspend/resume are sequential even for it to know its devfreq status. > > Assuming even if above sequence occurs, I don't see any problem having > stop_polling = false w/ cancel_delayed_work_sync() in effect. Since the suspend > is the last one to complete, monitoring will not continue. Why don't you simply extend the mutex-locked context? I.e., + mutex_lock(&devfreq->lock); + devfreq->stop_polling = true; + mutex_unlock(&devfreq->lock); + cancel_delayed_work_sync(&devfreq->work); --> + mutex_lock(&devfreq->lock); + devfreq->stop_polling = true; + cancel_delayed_work_sync(&devfreq->work); + mutex_unlock(&devfreq->lock); This serializes data-update and the execution based on the data-update, resolving any inconsistency issues with the queue-status and devfreq variable. It doesn't have a heavy overhead to extend it and we have the probably of inconsistency due to serialization issues. > > > > > 2. What if polling_ms = 0 w/ active governors (such as ondemand)? > > > > Users may declare the initial polling_ms = 0 w/ simple-ondemand in order to > > pause sampling at boot-time and start sampling at run-time some time later. > > > > It appears that this patch will start forcibly at boot-time in such a case. > > Yes. This is a valid case which can be handled by > > void devfreq_monitor_start(struct devfreq *devfreq) > { > INIT_DELAYED_WORK_DEFERRABLE(&devfreq->work, devfreq_monitor); > + if (devfreq->profile->polling_ms) > queue_delayed_work(devfreq_wq, &devfreq->work, > msecs_to_jiffies(devfreq->profile->polling_ms)); > } Please add the checking statement to every queue_delayed_work() statement: resume and interval-update functions. Cheers! MyungJoo

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev October 2012