linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Notes from kernel / u-boot release process 2010/08/27

by Loïc Minier

Hey! 10 days ago, I met with John and Nicolas and with the help of Steve we discussed how an "upstreamish" release process for u-boot-linaro and linux-linaro would look like. I'm sorry for sending the notes out to late, please find them below. Thanks == Attendees == Nicolas John Steve Loic == Minutes == * Releases every month * Release announcement on linaro-announce@ * Would we release both -next and -stable? even if no change was done? * Probably an upstream stable release every week or so * Between releases, merge upstream stable updates as they show up; before release, verify that we have the latest stable release * John wonders whether we need the Ubuntu changes? * AppArmor went upstream * aufs isn't used in Linaro * but we might want to be the upstream for the Ubuntu ARM team, so it makes sense to have the Ubuntu changes in our Ubuntu packages * We don't really need to test the Ubuntu changes in our dailies; simpler to just build daily zImages * We should include Ubuntu patches in ubuntu, but not in daily builds * What's the kernel PPA for? Is it for staging and testing, or an overlay? * The .debs are kind of specific to Ubuntu and distros in general, and we already integrate with Ubuntu * Should we produce .debs in a PPA or something before doing a kernel release, or just before upload to Ubuntu? * Kernel team is producing vanilla .debs, would be possible to do the same? * How would we test a new kernel, .deb is simpler than modules.tgz, zImage with hardcoded modules is easier to test though * Nicolas would prefer testing zImage; easier this way * Configs would differ though, and might regress either way * Linaro KCWG and Linaro .debs would use different configs * We're doing releases for users, and they mostly expect .debs, but also .rpms * Conclusion: * Daily zImage with everything compiled in, no need to worry about modules * Daily .deb builds that have modules split out, but no Ubuntu patches * Monthly release of the above * Monthly integration of that tree into Linaro Platform if possible * linux-linaro-next + linaro-linaro-stable, same thing Can add stuff progressively, starting without zImage Align a monthly release with the 6-monthly release, e.g. kernel release at the same time as platform release for 10.11 * u-boot: same thing, except we don't have Ubuntu configs and we don't have the modules problem; could even do a single daily built * Nicolas would ensure that we have builds for linux trees, and John for u-boot, and each of them would post to the tracker * Then send Call for testing to people with the hardware, report bugs, and if we have everything tested, release it * How do we test? * u-boot? * just loading a kernel probably * perhaps recovery procedure: make sure we have a way to load a kernel from an external source * loading a kernel from SD (for platforms which have it) * loading a kernel from the network * could test network * linux? * boots * display output * network * SD R/W * USB: storage at least * NAND: shows up in /proc/mtd if supported * user platforms should push for other test cases like audio if needed on some boards * what rootfs to test on? * for now use our minimal image, or the installed system * future: a small initramfs with static busybox ACTION slangasek to talk to ppearse and tgall to see how we could do that * John: The current configs are way too large, we need to have something smaller for Linaro * Needs at least to support everything on the board * Need some template for the common kernel config parts ACTION jcrigby to discuss with Frederik ideas about default/common configs ACTION nico to create a minimal config using the kernel system ACTION lool to send Ubuntu kernel checker over email ACTION lool document release process on the wiki -- Loïc Minier

14 years, 3 months

Notes on Android call 2010/09/07

by Loïc Minier

Hi == Attendees == * Scott Bambrough * Loïc Minier * Yves Vandervennet == Minutes == * build and provide a downloadable Android toolchain * base it on our toolchain as soon as possible * provide a Linaro Android distribution, with a set of git trees for Android components * should use the Google trees when we don't modify them * could use either a set of mirrored trees, or only host modified trees, not sure which option is best; the former allows changing the base URL from the start (at the time of repo init), the latter would mean changing the URL at the time of repo sync * need a build infrastructure * need a way for people using the Linaro output to replicate the build infrastructure for daily builds, Hudson would probably do * wont be able to watch multiple git repos with hudson * need a kernel tree * want a consolidated linux-linaro-android tree, just like linux-linaro * should track at least the Android kernel tree * can't target Android development tree because it's not public * do we want to rebase on newer linux kernels, i.e. newer than Android provides? * main use case would be the devicetree stuff; that one is really easy to backport, so might not be a good idea to move Android forward * Freescale's needs are mostly on the multimedia side, with the OpenCore framework in particular, since it seems like a poor fit for hardware accelerators * mostly interested in basing on a regular Android build, and trying to swap OpenCore with something else, or integrate existing stuff into OpenCore * are there some needs with current architecture which need to complete * SMP safety of bionic library; might be a good topic * hard-float? NEON? is this well supported in Android? probably just in isolated places, in isolated libraries * dalvik would probably break with hard-float * what kind of licensing constraints should we operated under? * Freescale didn't get any pushback on GPL stuff from OEMs so far; at least not on u-boot * are there needs to extend the Android architecture to cover new type of hardware in upcoming SoCs? e.g. new type of hardware accelerators or something like that? * apparently, not that much in the pipe; everything seems covered by Android already * are TSCMs interested mostly looking at phones or tablets? * mostly tables and not phones in the case of Freescale * what's more important? improving the runtime or improving the development experience and services? * a faster build would be nice; that is, compilation is really slow * the overall process is too long between the time where people start cloning and the time they have builds * could improve source code overlays * could provide pre-built Android parts * could provide infrastructure to fork source trees into multiple projects and do fast server-side builds * not clear how the development experience would look like with remote builds; would help in download and build time, but might be clumsy * can use adb with local builds to push modified files directly * which devices do we need to cover? * beagleboard -- would probably work in QEMU * google nexus one * should probably cover vexpress and imx51 babbage * should we do intel builds? might not be a good idea for an ARM group :-) Freescale didn't need to do any Intel builds at least * main advantage is that they work on more hardware and so support more devices etc. * should enable more people to build for their devices rather than doing it all ourselves * strong desire to see the Android kernel patches upstreamed * performance is probably the biggest thing which vendors care about, not infrastructure or features; in particular boot time and power management and execution speed * middleware * web browser * accelerated rendering: leveraging the GPU for page rendering * telephony * graphics stack * should probably explore with other vendors and TSCMs, especially company selling *phones* with android * improving the Android architecture is more of a topic for later Cheers, -- Loïc Minier

14 years, 3 months

XML-RPC authentication options for the validation dashboard

by Zygmunt Krynicki

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello guys. I'd like to ask for your advice in for implementing authentication mechanism for the XML-RPC interface to the dashboard. I believe this problem has two aspects: user needs and client program needs. I was about to implement HTTP Digest authentication that will authorize the user against the Django user database. James pointed out that we should discuss this topic more. I'd like to know what you think. What users need to have. ======================== I think that for our internal use cases a best option would be launchpad integration. We don't mind using launchpad, we already have accounts there. We could use oauth for authentication. I'm not an expect on oauth so I'm not sure what kind of impact it has on the API itself, if any (do we need to pass some special argument to each call?). I suspect it has a negotiation phase where the client and oauth provider exchange some messages after which the client can authenticate by providing some extra header in each request. In any way that's one option. For a centralized installation this would be pretty good. For ad-hoc installations it could be difficult to setup but I'm just guessing here. Other options are (off the top of my head): - - Basic/Digest HTTP authentication. Digest is pretty good (or so wikipedia tells me) and has a very nice property of not requiring any changes to the API. User identity is provided as out-of-band HTTP header. - - Custom authentication via special XML-RPC methods and some user/pass/token/whatever arguments. This is IMHO pretty ugly as it affects the interface. The upside is that we can build any authentication options we like. - - No authentication at all. All XML-RPC interfaces are public and anyone may call them. Surprisingly this is not such a bad option. Since all request would be anonymous all the users would be allowed to do is upload data to public "directories". All other interaction would have to be performed via the website or the administration panel. What clients need to implement. =============================== So this is about everyone who has to interact with the API, currently that's just dashboard itself (we have a command-line client that can use each exposed method) and of course abrek. While I don't mind changing the API or security method to make it better we need to consider that each client will have to adapt as well. Worse, if one client has to interact with two servers it may be required to discover/negotiate supported authentication before we can even connect. Thanks Zygmunt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMgnSeAAoJEKkR4hQBRI+lvRUIAKs90kr/238PoltUbb+ET5ti qnEgQA0UYR1ocykxlL+8gkNhDLroQuSE6HpFBlVXZb2kLc1wqb5ggK0XpwViuzwo qr7aZ2HfkL6gMBQNhdW1OOSK7RxI1Z731vG6dFAo3UTCX737lCitYW6ipkqA//h3 slbIn5Voh43cbBKneRZvpIeHJbd6oKW4HKLeEVAzheuprXtjvhyXkg1qjUVH3V+Y FHRp7V1fVAYvTlObhVVW2j95OEyVJK+7dbdpmwQ/8vai2WiDXdDlqJqpO2PuZNuy mu8C0gBdZsP+ZYB2AER5RKbhZIPISf2l1fmwem79yVaxstFmHU+/KwO7AeWCR3I= =h4TW -----END PGP SIGNATURE-----

14 years, 3 months

Notes & Actions: Linaro graphics/multimedia - Aug 30, 2010 and Sep 06, 2010

by Alexandros Frantzis

Hi, notes and actions from our Monday graphics and multimedia cross-vendor call are available on the wiki: + https://wiki.linaro.org/Platform/UserPlatforms/2010-08-30 + https://wiki.linaro.org/Platform/UserPlatforms/2010-09-06 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Thanks, -- - Alexandros

14 years, 3 months

[PATCH] OMAP CPUIDLE: CPU Idle latency measurement

by vishwanath.sripathy＠linaro.org

From: Vishwanath BS <vishwanath.sripathy(a)linaro.org> This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/state<n>/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/state<n>/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/state<n>/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS <vishwanath.sripathy(a)linaro.org> Cc: linaro-dev(a)lists.linaro.org --- arch/arm/mach-omap2/cpuidle34xx.c | 58 ++++++++++++++++-- arch/arm/mach-omap2/pm.h | 5 ++ arch/arm/mach-omap2/sleep34xx.S | 121 +++++++++++++++++++++++++++++++++++++ drivers/cpuidle/Kconfig | 5 ++ drivers/cpuidle/sysfs.c | 16 +++++- include/linux/cpuidle.h | 3 + 6 files changed, 202 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 3d3d035..398bef8 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -25,6 +25,7 @@ #include <linux/sched.h> #include <linux/cpuidle.h> +#include <linux/clk.h> #include <plat/prcm.h> #include <plat/irqs.h> #include <plat/powerdomain.h> @@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = { {1, 10000, 30000, 300000}, }; +#ifdef CONFIG_CPU_IDLE_PROF +static struct clk *clk_32k; +#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k))) +#endif + static int omap3_idle_bm_check(void) { if (!omap3_can_sleep()) @@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm, * Called from the CPUidle framework to program the device to the * specified target state selected by the governor. */ + static int omap3_enter_idle(struct cpuidle_device *dev, struct cpuidle_state *state) { struct omap3_processor_cx *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; u32 mpu_state = cx->mpu_state, core_state = cx->core_state; +#ifdef CONFIG_CPU_IDLE_PROF + int idle_time, latency; + long sleep_time, wkup_time, total_sleep_time; + long preidle_time, postidle_time; +#endif current_cx_state = *cx; - /* Used to keep track of the total time in idle */ - getnstimeofday(&ts_preidle); - local_irq_disable(); local_fiq_disable(); - + /* Used to keep track of the total time in idle */ + getnstimeofday(&ts_preidle); +#ifdef CONFIG_CPU_IDLE_PROF + preidle_time = omap3_sram_get_32k_tick(); +#endif pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); @@ -153,9 +166,39 @@ return_sleep_time: getnstimeofday(&ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); +#ifdef CONFIG_CPU_IDLE_PROF + postidle_time = omap3_sram_get_32k_tick(); +#endif local_irq_enable(); local_fiq_enable(); +#ifdef CONFIG_CPU_IDLE_PROF + sleep_time = omap3_sram_get_sleep_time(); + wkup_time = omap3_sram_get_wkup_time(); + + /* take care of overflow */ + if (postidle_time < preidle_time) + postidle_time += (u32) 0xffffffff; + if (wkup_time < sleep_time) + wkup_time += (u32) 0xffffffff; + + idle_time = postidle_time - preidle_time; + total_sleep_time = wkup_time - sleep_time; + latency = idle_time - total_sleep_time; + sleep_time = omap3_sram_get_sleep_time(); + wkup_time = omap3_sram_get_wkup_time(); + + /* calculate average latency after ignoring sprious ones */ + if ((total_sleep_time > 0) && (latency > state->actual_latency) + && (latency >= 0)) { + state->actual_latency = CONVERT_32K_USEC(latency); + latency = (sleep_time - preidle_time); + state->sleep_latency = CONVERT_32K_USEC(latency); + latency = postidle_time - wkup_time; + state->wkup_latency = CONVERT_32K_USEC(latency); + } +#endif + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC; } @@ -423,7 +466,9 @@ int __init omap3_idle_init(void) struct omap3_processor_cx *cx; struct cpuidle_state *state; struct cpuidle_device *dev; - +#ifdef CONFIG_CPU_IDLE_PROF + static struct device dummy_device; +#endif mpu_pd = pwrdm_lookup("mpu_pwrdm"); core_pd = pwrdm_lookup("core_pwrdm"); @@ -456,6 +501,9 @@ int __init omap3_idle_init(void) omap3_cpuidle_update_states(); +#ifdef CONFIG_CPU_IDLE_PROF + clk_32k = clk_get(&dummy_device, "wkup_32k_fck"); +#endif if (cpuidle_register_device(dev)) { printk(KERN_ERR "%s: CPUidle register device failed\n", __func__); diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 3de6ece..e62e87d 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -82,4 +82,9 @@ extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap34xx_cpu_suspend_sz; +#ifdef CONFIG_CPU_IDLE_PROF +extern u32 omap3_sram_get_wkup_time(); +extern u32 omap3_sram_get_sleep_time(); +extern u32 omap3_sram_get_32k_tick(); +#endif #endif diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index d522cd7..8dec5ef 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -59,6 +59,20 @@ #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) +#define TIMER_32K_SYNC_P 0x48320010 +#define TIMER_32K_SYNC OMAP2_L4_IO_ADDRESS(TIMER_32K_SYNC_P) + +#define SCRATCHPAD_SLEEP_TIME_OFFSET 0x9f8 +#define SCRATCHPAD_WKUP_TIME_OFFSET 0x9fc +#define SCRATCHPAD_SLEEP_TIME OMAP343X_CTRL_REGADDR(SCRATCHPAD_SLEEP_TIME_OFFSET) +#define SCRATCHPAD_WKUP_TIME OMAP343X_CTRL_REGADDR(SCRATCHPAD_WKUP_TIME_OFFSET) +#define SCRATCHPAD_WKUP_TIME_P OMAP343X_CTRL_BASE + SCRATCHPAD_WKUP_TIME_OFFSET + +#define CM_ICLKEN_WKUP OMAP34XX_CM_REGADDR(WKUP_MOD, CM_ICLKEN) +#define CM_ICLKEN_WKUP_P OMAP3430_CM_BASE + WKUP_MOD + CM_ICLKEN +#define CM_IDLEST_WKUP OMAP34XX_CM_REGADDR(WKUP_MOD, CM_IDLEST) +#define CM_IDLEST_WKUP_P OMAP3430_CM_BASE + WKUP_MOD + CM_IDLEST + .text /* Function to aquire the semaphore in scratchpad */ ENTRY(lock_scratchpad_sem) @@ -183,7 +197,31 @@ api_params: .word 0x4, 0x0, 0x0, 0x1, 0x1 ENTRY(save_secure_ram_context_sz) .word . - save_secure_ram_context +#ifdef CONFIG_CPU_IDLE_PROF +ENTRY(omap3_sram_get_wkup_time) + stmfd sp!, {lr} @ save registers on stack + ldr r0, wkup_time + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_wkup_time_sz) + .word . - omap3_sram_get_wkup_time + +ENTRY(omap3_sram_get_sleep_time) + stmfd sp!, {lr} @ save registers on stack + ldr r0, sleep_time + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_sleep_time_sz) + .word . - omap3_sram_get_sleep_time +ENTRY(omap3_sram_get_32k_tick) + stmfd sp!, {lr} @ save registers on stack + ldr r0, sync_32k_timer + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_32k_tick_sz) + .word . - omap3_sram_get_32k_tick +#endif /* * Forces OMAP into idle state * @@ -207,6 +245,13 @@ loop: cmp r1, #0x0 /* If context save is required, do that and execute wfi */ bne save_context_wfi + +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, sleep_time + str r5, [r6] +#endif /* Data memory barrier and Data sync barrier */ mov r1, #0 mcr p15, 0, r1, c7, c10, 4 @@ -224,8 +269,25 @@ loop: nop nop nop +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup +wait_idlest: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, wkup_time + str r5, [r6] +#endif bl wait_sdrc_ok + ldmfd sp!, {r0-r12, pc} @ restore regs and return restore_es3: /*b restore_es3*/ @ Enable to debug restore code @@ -247,6 +309,23 @@ copy_to_sram: blx r1 restore: /* b restore*/ @ Enable to debug restore code +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup_p + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup_p +wait_idlest1: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest1 + ldr r4, sync_32k_timer_p + ldr r5, [r4] + ldr r6, wkup_time_p + str r5, [r6] +#endif + /* Check what was the reason for mpu reset and store the reason in r9*/ /* 1 - Only L1 and logic lost */ /* 2 - Only L2 lost - In this case, we wont be here */ @@ -587,6 +666,12 @@ finished: mcr p15, 2, r10, c0, c0, 0 isb skip_l2_inval: +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, sleep_time + str r5, [r6] +#endif /* Data memory barrier and Data sync barrier */ mov r1, #0 mcr p15, 0, r1, c7, c10, 4 @@ -603,6 +688,22 @@ skip_l2_inval: nop nop nop +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup +wait_idlest2: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest2 + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, wkup_time + str r5, [r6] +#endif bl wait_sdrc_ok /* restore regs and return */ ldmfd sp!, {r0-r12, pc} @@ -668,5 +769,25 @@ cache_pred_disable_mask: .word 0xFFFFE7FB control_stat: .word CONTROL_STAT +#ifdef CONFIG_CPU_IDLE_PROF +sync_32k_timer: + .word TIMER_32K_SYNC +sync_32k_timer_p: + .word TIMER_32K_SYNC_P +sleep_time: + .word SCRATCHPAD_SLEEP_TIME +wkup_time: + .word SCRATCHPAD_WKUP_TIME +wkup_time_p: + .word SCRATCHPAD_WKUP_TIME_P +iclken_wkup: + .word CM_ICLKEN_WKUP +iclken_wkup_p: + .word CM_ICLKEN_WKUP_P +idlest_wkup: + .word CM_IDLEST_WKUP +idlest_wkup_p: + .word CM_IDLEST_WKUP_P +#endif ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index 7dbc4a8..147456d 100644 --- a/drivers/cpuidle/Kconfig +++ b/drivers/cpuidle/Kconfig @@ -18,3 +18,8 @@ config CPU_IDLE_GOV_MENU bool depends on CPU_IDLE && NO_HZ default y + +config CPU_IDLE_PROF + bool + depends on CPU_IDLE + default n diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c index 0310ffa..a3e9db1 100644 --- a/drivers/cpuidle/sysfs.c +++ b/drivers/cpuidle/sysfs.c @@ -249,6 +249,11 @@ define_show_state_ull_function(usage) define_show_state_ull_function(time) define_show_state_str_function(name) define_show_state_str_function(desc) +#ifdef CONFIG_CPU_IDLE_PROF +define_show_state_function(actual_latency) +define_show_state_function(sleep_latency) +define_show_state_function(wkup_latency) +#endif define_one_state_ro(name, show_state_name); define_one_state_ro(desc, show_state_desc); @@ -256,7 +261,11 @@ define_one_state_ro(latency, show_state_exit_latency); define_one_state_ro(power, show_state_power_usage); define_one_state_ro(usage, show_state_usage); define_one_state_ro(time, show_state_time); - +#ifdef CONFIG_CPU_IDLE_PROF +define_one_state_ro(actual_latency, show_state_actual_latency); +define_one_state_ro(sleep_latency, show_state_sleep_latency); +define_one_state_ro(wkup_latency, show_state_wkup_latency); +#endif static struct attribute *cpuidle_state_default_attrs[] = { &attr_name.attr, &attr_desc.attr, @@ -264,6 +273,11 @@ static struct attribute *cpuidle_state_default_attrs[] = { &attr_power.attr, &attr_usage.attr, &attr_time.attr, +#ifdef CONFIG_CPU_IDLE_PROF + &attr_actual_latency.attr, + &attr_sleep_latency.attr, + &attr_wkup_latency.attr, +#endif NULL }; diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h index 55215cc..6474f6a 100644 --- a/include/linux/cpuidle.h +++ b/include/linux/cpuidle.h @@ -43,6 +43,9 @@ struct cpuidle_state { int (*enter) (struct cpuidle_device *dev, struct cpuidle_state *state); +#ifdef CONFIG_CPU_IDLE_PROF + u32 actual_latency, sleep_latency, wkup_latency; +#endif }; /* Idle State Flags */ -- 1.7.0.4

14 years, 3 months

Minutes Sept 1st User Platforms Status Meeting

by Tom Gall

Greetings, Enclosed you'll find a link to the agenda, notes and actions from the Linaro User Platforms Weekly Status meeting dated 9/01 held in #linaro-meeting at 13:00 UTC. https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-09-01 Regards, Tom (tgall_foo) User Platforms Team

14 years, 3 months

Re: Profiling fixes for -stable

by Nicolas Pitre

On Fri, 3 Sep 2010, Will Deacon wrote: > Hi Nicolas, > > If you're still accepting fixes for the 2.6.35 stable Linaro Kernel > then I have some small profiling updates for you: Thanks. Merged and pushed out. Nicolas

14 years, 3 months

[PM] 25/08/10 - Minutes for the Power Management WG weekly call

by Amit Kucheria

The minutes of the weekly call can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25 The minutes and actions are copied below. Regards, Amit Attendees: Linaro: Amit Kucheria, Amit Arora, Yong Shen ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga == Action Items from this Meeting == * ACTION: Yong to work with John Rigby and Ubuntu kernel team to make sure the Linaro kernel contains powertop kernel patches * ACTION: Vishwa to verify powertop on 2.6.35 * ACTION: Vishwa to check with cpuidle/cpufreq experts in TI for verifying cpufreq behavior on multi-core OMAP * ACTION: Amit A to get the powertop patch integrated into Linaro/Ubuntu packages * ACTION: Yong to test common clk API patches on imx5 and help get it booting on babbage 3.0 == Action Items from Previous Meeting == * ACTIVE (Immediate): * ACTION: Amit A to test on pm enabled OMAP3 board: DONE on 2.6.32 on zoom3 board * New ACTION: Vishwa to verify on 2.6.35 * ACTION: Amit A to document details on power supply class (battery info) to PowerTOP internal wiki page: DONE * ACTION: Yong to look into getting powertop kernel patches applied to Linaro kernel tree: Not DONE * New ACTION: Yong to work with John Rigby and make sure the Linaro kernel contains it * ACTION: Robin to send links to patches sent to linux-pm: DONE * http://www.spinics.net/lists/cpufreq/msg01740.html * It was a pointer to a discussion on having different governors on different cores * ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems: POSTPONED * ACTION: Yong to look at common clock FW, find out if debug info being exported (usage count, clk rate, dependencies): DONE * DORMANT : * ACTION: ARM to share internal instrumentation flow (BAB: we might also align with Linaro on workload discussions) * Might take couple of months * ACTION: Amit K to talk to jeremy about power domain framework: DONE * Jeremy needs help, will revisit in a few weeks * ACTION: Srinivas to provide details of where he believes userspace - kernel interaction is required. (low prio) * ACTION: Bobby to check on multi-core boards availability (request open) * ACTION: ARM to discuss giving out internal Eclipse based tool (similar to powertop) (no ETA as of now) * ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues related to CPUIDLE governor: POSTPONED until instrumentation work == Minutes == * Discussion on http://www.spinics.net/lists/cpufreq/msg01740.html * For ARM, both cores run at same frequency (CMP) * Does it make sense for them to run different governors on each core? * The consensus currently is NO * TI uses ondemand governor + policy manager * One core is kept OFF, all processing happens on the other one. * If load on one core goes above a threshold, they turn ON other core * Both cores run at same Operating Point once ON * Debug info in common clk API being discussed upstream by Jeremy * There is currently no debug info * clock name is not part of the common struct clk to keep size down * Need to engage with Jeremy * Yong will test the patches from Jeremy on imx5 and report back * Powerdebug: should we visualise the clock and power dependencies using information from /sys or debugfs? * No immediate horror expressed at the idea * Freescale and TI already do it to a certain extent by dumping the clock tree and rates into a table * The entire tree is too complex to depict * We could represent it in parts e.g. start at a peripheral and plot it's clock and power dependencies all the way up

14 years, 3 months

Re: imx51 and CONFIG_NEON

by Dave Martin

On Fri, Sep 3, 2010 at 1:41 PM, Amit Kucheria <amit.kucheria(a)linaro.org> wrote: > I copied the 2 patches to http://people.canonical.com/~amitk/imx5 > OK, as far as I can make out the patch does the right thing. On Babbage 2.0 and the Pegatron lange5.1/nettop platforms, your check is triggered, and at least on Babbage 2.0 /proc/cpuinfo and /proc/self/auxv reflect the absence of NEON correctly. (I couldn't boot to an fs on the Pegatron platform --- in any case I had to bodge the machine ID passed by the bootloader to persuage the kernel to boot). On Babbage 3.0, NEON is reported as present in /proc/cpuinfo and /proc/self/auxv. See the attached logs. Cheers ---Dave

14 years, 3 months

Re: Barebox

by Jean-Christophe PLAGNIOL-VILLARD

Cc -dev On 06:15 Mon 06 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote: > Hi all, > > I've like to open the discussion about barebox > > What is Barebox? > > Barebox is a fork of U-Boot which was named before the elce 2009 > U-Boot-V2 with the target to have a modern internal Implememtation > derived from the Linux kernel and user friendly interface > > The current design of barebox is very near from the kernel as example > on AT91 I've update the current API to be as near as possible as the > one in the kernel so it's now really easy to port a new board and on > contrary of U-Boot we can have the multy instance of the drivers. > > I'm start to push the SH with the same idea > > As example have the prompt on all uart at the same time or be able to use > them independently. > > We also support FastBoot, Framebuffer, USB ohci & Ehci, network, nor, > nandflash, dfu, usb ethernet (very usefull for soc without net > device), Menu Framework, etc... > > inprogress mmc, spi flash > > DFU for Device Firmware Upgrade is very use full to update device from > usb device from a PC so you will have an generic updater from the > bootloader > > The Menu Framework will help you to create friendly interface to manage > the booloader via key specially on device without keyboard as cellphone, > STB etc... > > We have also a true shell support with scripting so it's very easy to > create complex command via sheel script and also complex boot sequence > > We have modules support as the kernel which allow to load code based > on the need and speed up the boot but also allow to update the > bootloader functionnality in the feature > > etc... > > Best Regards, > J. > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

14 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev