linaro-dev November 2010

linaro-dev@lists.linaro.org

73 participants
81 discussions

by Jamie Bennett

Hi, According to the 11.05 release schedule [1] the Linaro Alpha-1 release will be made next Thursday. To help prepare and test the images developers are asked to refrain from uploading changes to the archive from Tuesday 30th November until Thursday 2nd December. >From Tuesday onwards the release candidate image for Alpha-1 will be selected and available for testing. The Linaro QA tracking tool [2] will be available for submission of results at the same time so please test, submit your results and report bugs either in the project the bug occurs or if in doubt, to the Linaro project at http://bugs.launchpad.net/linaro. For more information on the Linaro 11.05 release please see the wiki page at: http://wiki.linaro.org/Releases/1105/ Regards, Jamie. -- Linaro Release Manager [1] http://wiki.linaro.org/Releases/1105/Schedule [2] http://qatracker.linaro.org

13 years, 5 months

Linaro Infrastructure Team Weekly Report (2010-11-19 to 2010-11-25)

by Ian Smith

All, The weekly report for the Linaro Infrastructure team may be found at:- Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-25 Burndown chart: This link is awaiting the production of new burndown charts. The Infrastructure related blueprints from the maverick cycle, of which currently there are 4 active ones (4 from the last report), are showing that there are 8 work items in progress (8 last report), and 11 work items to undertake (11 last report). These are to be moved into the natty cycle if still required. arm-m-validation-dashboard; 0 work items completed since last report; 3 in progress; 7 to do arm-m-image-building-console; 0 work items completed since last report; 3 in progress; 3 to do arm-m-automated-testing-framework; no change in status from last report; 1 in progress; 0 to do arm-m-testsuites-and-profilers; no change in status from last report; 1 in progress; 1 to do In the natty cycle, the following lists the current active Blueprints, or Blueprints planned and not started:- other-linaro-n-improve-linaro-media-create: 2 work items completed; 4 work items in progress; 7 work items to do. other-linaro-n-test-result-display-in-launch-control: 1 work item completed; 1 work item in progress; 14 work items to do other-linaro-n-patch-tracking: 1 work item completed; 2 work items in progress; 9 work items to do other-linaro-n-image-building: 7 work items to do. other-linaro-n-continuous-integration: Not started - awaiting a Hudson build server (RT#42278). other-linaro-n-package-development-tools: Not Started; 9 work items to do Specifics accomplished this week include:- * ImproveLinaroMediaCreate: Two work items completed - porting of the create_boot_cmd and planning to ensure new python functions are accessible to the system LinaroMediaCreate. * ImageBuilding: The initial branch of "Multiple hwpacks" is in review. * TestResultTracking: Work has been ongoing for the pre-requisites for this development and a demonstration report seems to work well under engineer test. Code reviews should start shortly. Please let me know if you have any comments or questions. Kind Regards, Ian

13 years, 5 months

[PATCHv2] export clock debug information to user space

by Yong Shen

Hi Jeremy, Sorry for delay sending out this patch, I was slow down by other things and eye infection :( I followed your suggestion to make clock debug interface cleaner and more independent, like removing unnecessary #ifdef and moving all operations to kernel/clk.c. >From 2b6c378c3c42d695f72f987e5e158faa2aac15d5 Mon Sep 17 00:00:00 2001 From: Yong Shen <yong.shen(a)linaro.org> Date: Thu, 18 Nov 2010 14:54:49 +0800 Subject: [PATCHv2] export clock debug information to user space create a tree-like directory structure in debugfs so user space tools like powerdebug can generate readable clock information. more functions tend to be add in, like individual clock enable/disable by writing to this debug interface. Signed-off-by: Yong Shen <yong.shen(a)linaro.org> --- arch/arm/common/Kconfig | 7 +++ arch/arm/common/clkdev.c | 3 + include/linux/clk.h | 18 +++++++ kernel/clk.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 144 insertions(+), 0 deletions(-) diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig index 0a34c81..c84eb90 100644 --- a/arch/arm/common/Kconfig +++ b/arch/arm/common/Kconfig @@ -41,3 +41,10 @@ config SHARP_SCOOP config COMMON_CLKDEV bool select HAVE_CLK + +config CLK_DEBUG + bool "clock debug information export to user space" + depends on USE_COMMON_STRUCT_CLK && PM_DEBUG && DEBUG_FS + default n + help + export clk debug information to user space diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c index 9e4c4d9..1d08fb3 100644 --- a/arch/arm/common/clkdev.c +++ b/arch/arm/common/clkdev.c @@ -19,6 +19,7 @@ #include <linux/mutex.h> #include <linux/clk.h> #include <linux/slab.h> +#include <linux/debugfs.h> #include <asm/clkdev.h> @@ -104,6 +105,7 @@ EXPORT_SYMBOL(clk_put); void clkdev_add(struct clk_lookup *cl) { + clk_debug_register(cl->clk); mutex_lock(&clocks_mutex); list_add_tail(&cl->node, &clocks); mutex_unlock(&clocks_mutex); @@ -114,6 +116,7 @@ void __init clkdev_add_table(struct clk_lookup *cl, size_t num) { mutex_lock(&clocks_mutex); while (num--) { + clk_debug_register(cl->clk); list_add_tail(&cl->node, &clocks); cl++; } diff --git a/include/linux/clk.h b/include/linux/clk.h index 56416b7..3d5f9ba 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -18,6 +18,7 @@ struct device; #ifdef CONFIG_USE_COMMON_STRUCT_CLK +#define CLK_NAME_LEN 32 /* If we're using the common struct clk, we define the base clk object here */ @@ -48,12 +49,23 @@ struct clk { const struct clk_ops *ops; unsigned int enable_count; struct mutex mutex; +#ifdef CONFIG_CLK_DEBUG + char name[CLK_NAME_LEN]; + struct dentry *dentry; +#endif }; +#ifdef CONFIG_CLK_DEBUG +#define __INIT_CLK_DEBUG(n) .name = #n, +#else +#define __INIT_CLK_DEBUG(n) +#endif + #define INIT_CLK(name, o) { \ .ops = &o, \ .enable_count = 0, \ .mutex = __MUTEX_INITIALIZER(name.mutex), \ + __INIT_CLK_DEBUG(name) \ } struct clk_ops { @@ -245,4 +257,10 @@ struct clk *clk_get_sys(const char *dev_id, const char *con_id); int clk_add_alias(const char *alias, const char *alias_dev_name, char *id, struct device *dev); +#ifdef CONFIG_CLK_DEBUG +void clk_debug_register(struct clk *clk); +#else +static inline void clk_debug_register(struct clk *clk) {} +#endif + #endif diff --git a/kernel/clk.c b/kernel/clk.c index 32f25ef..d23633f 100644 --- a/kernel/clk.c +++ b/kernel/clk.c @@ -11,6 +11,8 @@ #include <linux/clk.h> #include <linux/mutex.h> #include <linux/module.h> +#include <linux/slab.h> +#include <linux/debugfs.h> int clk_enable(struct clk *clk) { @@ -113,3 +115,117 @@ struct clk_ops clk_fixed_ops = { .get_rate = clk_fixed_get_rate, }; EXPORT_SYMBOL_GPL(clk_fixed_ops); + +#ifdef CONFIG_CLK_DEBUG +/* + * debugfs support to trace clock tree hierarchy and attributes + */ +static int clk_debug_rate_get(void *data, u64 *val) +{ + struct clk *clk = data; + + *val = (u64)clk_get_rate(clk); + return 0; +} +DEFINE_SIMPLE_ATTRIBUTE(clk_debug_rate_fops, clk_debug_rate_get, NULL, + "%llu\n"); + + +static struct dentry *clk_root; +static int clk_debug_register_one(struct clk *clk) +{ + int err; + struct dentry *d, *child, *child_tmp; + struct clk *pa = clk_get_parent(clk); + + if (pa && !IS_ERR(pa)) + d = debugfs_create_dir(clk->name, pa->dentry); + else { + if (!clk_root) + clk_root = debugfs_create_dir("clocks", NULL); + if (!clk_root) + return -ENOMEM; + d = debugfs_create_dir(clk->name, clk_root); + } + + if (!d) + return -ENOMEM; + + clk->dentry = d; + + d = debugfs_create_u32("enable_count", S_IRUGO, clk->dentry, + (u32 *)&clk->enable_count); + if (!d) { + err = -ENOMEM; + goto err_out; + } + + d = debugfs_create_file("rate", S_IRUGO, clk->dentry, (void *)clk, + &clk_debug_rate_fops); + if (!d) { + err = -ENOMEM; + goto err_out; + } + + return 0; + +err_out: + d = clk->dentry; + list_for_each_entry_safe(child, child_tmp, &d->d_subdirs, d_u.d_child) + debugfs_remove(child); + debugfs_remove(clk->dentry); + return err; +} + +struct preinit_clk { + struct list_head list; + struct clk *clk; +}; +static LIST_HEAD(preinit_clks); +static DEFINE_MUTEX(preinit_lock); +static int init_done; + +void clk_debug_register(struct clk *clk) +{ + int err; + struct clk *pa; + + if (init_done) { + pa = clk_get_parent(clk); + + if (pa && !IS_ERR(pa) && !pa->dentry) + clk_debug_register(pa); + + if (!clk->dentry) { + err = clk_debug_register_one(clk); + if (err) + return; + } + } else { + struct preinit_clk *p; + mutex_lock(&preinit_lock); + p = kmalloc(sizeof(*p), GFP_KERNEL); + if (!p) + goto unlock; + p->clk = clk; + list_add(&p->list, &preinit_clks); +unlock: + mutex_unlock(&preinit_lock); + } +} +EXPORT_SYMBOL_GPL(clk_debug_register); + +static int __init clk_debugfs_init(void) +{ + struct preinit_clk *pclk; + + if (debugfs_initialized()) + init_done = 1; + + list_for_each_entry(pclk, &preinit_clks, list) { + clk_debug_register(pclk->clk); + } + return 0; +} +late_initcall(clk_debugfs_init); +#endif -- 1.7.0.4 Cheers Yong

13 years, 5 months

[RFC] thermal sensor drivers under drivers/hwmon

by Yong Shen

Hi there, In power management group, we have a working item of exposing thermal information to user space through sysfs. However, so far, the thermal sensor drivers under 'drivers/hwmon' expose their information in various nodes under sysfs, which makes information collection difficult. Intel's thermal framework is located under 'drivers/thermal', but all the thermal drivers under hwmon don't make use of it due to some reason (part of the reason for this situation may be that intel's thermal framework is comparatively new therefore when those sensor drivers were implemented they did not have a framework to register themselves.) We like to find out a simple and unified way to expose thermal related information, intel's thermal interface could be a choice. Using thermal framework is straightforward, below is a sample driver for this purpose. Thus all the information goes to /sys/class/thermal, like temperature, mode... ... #include <linux/module.h> #include <linux/device.h> #include <linux/thermal.h> #include <linux/hwmon.h> static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp) { *temp = xxx; return 0; } static struct device *hwmon; static struct thermal_zone_device *thermal; static struct thermal_zone_device_ops ops = { .get_temp = thermal_get_temp, }; static int __init sensor_init(void) { ... thermal = thermal_zone_device_register("sample", 0, 0, &ops, 0, 0, 0, 0); } static void __exit sensor_cleanup(void) { ... } module_init(sensor_init); module_exit(sensor_cleanup); Are there any better ideas about this? Your comments are highly appreciated. Yong

13 years, 5 months

Re: [Blueprint multimedia-linaro-optimize-aac-encoding] optimize AAC/EAAC/AAC+ encoding for ARM

by Yao Qi

On 11/24/2010 09:30 PM, kan hu wrote: > Blueprint changed by kan hu: > + Looks like these work are related to toolchain. Here are some my cents, > + GDB and Oprofiler on Cortex a9(required for profiling or look for a workaround) : TODO > + We plan to improve the correctness of GDB and Oprofile on cortex-a9. If you find bugs on them, please file tickets in launchpad, and we can have a look. > + Check FFMpeg test application or write a new one to measure performance: TODO > + Select contents with different parameter setting for using measure performance. TODO > + Check current performance result and find a reasonable target performance: TODO Speed performance improvement is one of our task also. Feedback on GCC performance on cortex-a9 are welcome. > + Measure and record performance increased by NEON optimize method: TODO Recent Linaro GCC release includes some NEON improvements. This may be helpful to this task.

13 years, 5 months

[PM] 24/11/2010 - Minutes for the Power Management WG weekly call

by Amit Kucheria

Hello Everyone, The minutes of the weekly call can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-11-24 Attendees: Amit Kucheria, Vincent, Yong and Srinivas Highlight: Status of Dormant actions Regards, Amit

13 years, 5 months

Upstart Tech Talk

by Christian Robottom Reis

Hi there, Scott James Remnant, author of the upstart boot daemon, will be doing a tech talk on it today at 16:30 UTC; it will be streamed live at: http://www.ustream.tv/channel/upstart-tech-talk Upstart has an interesting architecture, and Scott's a pretty engaging character, so I think it's worth watching if you have that hour free. See you there! -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

13 years, 5 months

Minutes & actions: Kernel Working Group meeting of Nov 22, 2010

by Mounir Bsaibes

Greetings, Enclosed you'll find a link to the agenda, minutes and actions from the Linaro kernel working group weekly meeting of November 22nd, 2010. https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-11-… Regards, Mounir <https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-11-17>

13 years, 5 months

omap4 panda ehci failure

by John Rigby

All omap4 experts, I have a packaged kernel for omap3/omap4 that boots to a shell prompt on a Panda and a Beagle XM. One problem on Panda is that I have not network. When I looked at the dmesg I noticed that the ehci driver failed to initialize: [ 0.761352] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.768280] ehci-omap: probe of ehci-omap.0 failed with error -2 My kernel is linux-linaro-2.6.36 from Nicolas plus some Ubuntu sauce and packaging. Here is my packaged kernel: http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-natty.git;a=summary Here is linux-linaro-2.6.36 http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.36.git;a=summary and attached is my config. If anyone knows what is wrong with ehci it would be greatly appreciated. One more thing, my pandaboard is an old black 6 layer version. Thanks John

13 years, 5 months

[PATCH] ARM: oprofile: fix merge conflict introduced by cd2cc211

by Will Deacon

Commit 1b6740a1 was marked as stable but conflicts with 93068241. This patch resolves the conflict so that an OProfile-enabled ARM kernel can be used. Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Linaro Dev <linaro-dev(a)lists.linaro.org> Signed-off-by: Will Deacon <will.deacon(a)arm.com> --- Nicolas - this patch fixes an unresolved merge conflict present in the Linaro 2.6.35-stable tree which results in build failure if oprofile is enabled. The resolution isn't especially trivial but I think I've got it right. arch/arm/oprofile/common.c | 27 ++++----------------------- 1 files changed, 4 insertions(+), 23 deletions(-) diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c index b03ef43..bd7426f 100644 --- a/arch/arm/oprofile/common.c +++ b/arch/arm/oprofile/common.c @@ -352,6 +352,8 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) { int cpu, ret = 0; + memset(&perf_events, 0, sizeof(perf_events)); + perf_num_counters = armpmu_get_max_events(); counter_config = kcalloc(perf_num_counters, @@ -365,11 +367,8 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) } ret = init_driverfs(); - if (ret) { - kfree(counter_config); - counter_config = NULL; - return ret; - } + if (ret) + goto out; for_each_possible_cpu(cpu) { perf_events[cpu] = kcalloc(perf_num_counters, @@ -410,36 +409,18 @@ void __exit oprofile_arch_exit(void) int cpu, id; struct perf_event *event; -<<<<<<< HEAD for_each_possible_cpu(cpu) { for (id = 0; id < perf_num_counters; ++id) { event = perf_events[cpu][id]; if (event) perf_event_release_kernel(event); -======= - if (*perf_events) { - for_each_possible_cpu(cpu) { - for (id = 0; id < perf_num_counters; ++id) { - event = perf_events[cpu][id]; - if (event != NULL) - perf_event_release_kernel(event); - } - kfree(perf_events[cpu]); ->>>>>>> v2.6.35.8 } kfree(perf_events[cpu]); } -<<<<<<< HEAD kfree(counter_config); exit_driverfs(); -======= - if (counter_config) { - kfree(counter_config); - exit_driverfs(); - } ->>>>>>> v2.6.35.8 } #else int __init oprofile_arch_init(struct oprofile_operations *ops) -- 1.7.0.4

13 years, 5 months

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev November 2010