linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH] export clock debug information to user space

by Yong Shen

Hi Jeremy, This is latest one for review. I add some minor changes in. Cheers Yong >From efe7fa8bea67f9bf532c0074a92d938e6d6f4c5d 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: [PATCH] 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 | 6 ++ arch/arm/common/clkdev.c | 3 + include/linux/clk.h | 18 +++++++ kernel/clk.c | 121 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 148 insertions(+), 0 deletions(-) diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig index 0a34c81..13d7cf9 100644 --- a/arch/arm/common/Kconfig +++ b/arch/arm/common/Kconfig @@ -41,3 +41,9 @@ 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 + 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..4aaddea 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -48,12 +48,24 @@ struct clk { const struct clk_ops *ops; unsigned int enable_count; struct mutex mutex; +#ifdef CONFIG_CLK_DEBUG +#define CLK_NAME_LEN 32 + 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..7f8bea9 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,122 @@ 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, *tmp; + + if (debugfs_initialized()) + init_done = 1; + + list_for_each_entry(pclk, &preinit_clks, list) { + clk_debug_register(pclk->clk); + } + + list_for_each_entry_safe(pclk, tmp, &preinit_clks, list) { + list_del(&pclk->list); + kfree(pclk); + } + return 0; +} +late_initcall(clk_debugfs_init); +#endif -- 1.7.0.4

14 years

[ACTIVITY] Toolchain WG 2010-11-03

by Michael Hope

Here's what the toolchain group has been doing: * 2010.12 release is coming up. Bug list is in a good way. Build is good, test results are good. * Atomic memory operations are finished, in GCC, in GLIBC, and in Ubuntu. Coverage report is done at [[WorkingGroups/ToolChain/AtomicMemoryOperations]] * Handed off valgrind to Foundations to make sure the updated version is in Ubuntu * String routines are approaching the end of a good phase 1. Next is sorting out the copyright assignment issues * Lack of A9 hardware is causing headaches. People are benchmarking Linaro GCC on hardware and getting unexpected results. * Started investigating libffi variadic support * Received a copy of the SPEC CPU 2006 benchmark suite Weekly meeting minutes are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-12-06 Standup minutes are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-12-08 Audio is here: http://tc.seabright.co.nz/toolchainwg/ -- Michael

14 years

Linaro QEMU package in Ubuntu?

by Jani Monoses

Hello, one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to Linaro/ARM work in the official archives, allowing to test at least the official Ubuntu ARM images. The Linaro PPA provides a package based on qemu-maemo from gitorious, and it is ahead of what is packaged in that it supports the BeagleBoard. I see there's also qemu-arm repo in git.linaro.org - I assume this is a newer and preferable upstream to the maemo one? Are the ARM patches being pushed and accepted into upstream QEMU regularly? In this case there may be no need to create a new package and just wait for that work to get released and packaged, and maybe focus the effort on helping with upstreaming the ARM changes. any pointers appreciated :) thanks Jani

14 years

[PATCH v2 0/3] ARM: omap: Thumb-2 kernel compatibility fixes

by Dave Martin

These patches enable the omap kernel to build and work in Thumb-2 (CONFIG_THUMB2_KERNEL). They may make useful reading for all low-level BSP maintainers, since in general similar issues tend to crop up whenever migrating code to support Thumb-2. Tested on: omap3 (Beagle xM A2) Not tested on any other platforms yet. Dave Martin (3): ARM: omap: Enable low-level omap3 PM code to work with CONFIG_THUMB2_KERNEL ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL arch/arm/mach-omap2/include/mach/omap4-common.h | 5 +++ arch/arm/mach-omap2/omap-headsmp.S | 2 +- arch/arm/mach-omap2/omap44xx-smc.S | 8 ++-- arch/arm/mach-omap2/pm.h | 2 + arch/arm/mach-omap2/pm34xx.c | 13 ++++++-- arch/arm/mach-omap2/sleep34xx.S | 37 +++++++++++++++++++++-- arch/arm/mach-omap2/sram34xx.S | 34 +++++++++++++++----- arch/arm/plat-omap/include/plat/sram.h | 1 + arch/arm/plat-omap/sram.c | 10 +++++- 9 files changed, 90 insertions(+), 22 deletions(-)

14 years

license for setup_sdcard.sh

by John Rigby

Hi Robert, The Linaro project has a script that started as your setup_sdcard.sh called linaro_media_create. As part of our release process we need to have licenses for our files and since our script is based on yours, your choice of license affects what choices we have. So long story short, your file has no license included so care to add one or just tell us what the license is so we can give our script a compatible if not identical one? Thanks John

14 years

RFC: Dynamic hwcaps

by Dave Martin

Hi all, I'd be interested in people's views on the following idea-- feel free to ignore if it doesn't interest you. For power-management purposes, it's useful to be able to turn off functional blocks on the SoC. For on-SoC peripherals, this can be managed through the driver framework in the kernel, but for functional blocks of the CPU itself which are used by instruction set extensions, such as NEON or other media accelerators, it would be interesting if processes could adapt to these units appearing and disappearing at runtime. This would mean that user processes would need to select dynamically between different implementations of accelerated functionality at runtime. This allows for more active power management of such functional blocks: if the CPU is not fully loaded, you can turn them off -- the kernel can spot when there is significant idle time and do this. If the CPU becomes fully loaded, applications which have soft-realtime constraints can notice this and switch to their accelerated code (which will cause the kernel to switch the functional unit(s) on). Or, the kernel can react to increasing CPU load by speculatively turn it on instead. This is analogous to the behaviour of other power governors in the system. Non-aware applications will still work seamlessly -- these may simply run accelerated code if the hardware supports it, causing the kernel to turn the affected functional block(s) on. In order for this to work, some dynamic status information would need to be visible to each user process, and polled each time a function with a dynamically switchable choice of implementations gets called. You probably don't need to worry about race conditions either-- if the process accidentally tries to use a turned-off feature, you will take a fault which gives the kernel the chance to turn the feature back on. Generally, this should be a rare occurrence. The dynamic feature status information should ideally be per-CPU global, though we could have a separate copy per thread, at the cost of more memory. It can't be system-global, since different CPUs may have a different set of functional blocks active at any one time -- for this reason, the information can't be stored in an existing mapping such as the vectors page. Conversely, existing mechanisms such sysfs probably involve too much overhead to be polled every time you call copy_pixmap() or whatever. Alternatively, each thread could register a userspace buffer (a single word is probably adequate) into which the CPU pokes the hardware status flags each time it returns to userspace, if the hardware status has changed or if the thread has been migrated. Either of the above approaches could be prototyped as an mmap'able driver, though this may not be the best approach in the long run. Does anyone have a view on whether this is a worthwhile idea, or what the best approach would be? Cheers ---Dave

14 years

Linaro-Alpha-1:Unable to Create Boot Images

by Praveen Arkeri

Hi, I am trying to create boot images for vexpress platform following instructions mentioned here https://wiki.linaro.org/Releases/MilestoneBuilds. Daily Build & HwPack Images used: * http://releases.linaro.org/platform/linaro-n/headless/alpha-1/linaro-nat ty-headless-tar-20101202-1.tar.gz * http://releases.linaro.org/platform/linaro-n/hwpacks/alpha-1/vexpress/20 101201/1/images/hwpack/hwpack_linaro-vexpress_20101201-1_armel_supported .tar.gz I am getting errors while installing images on SD card when I tried following command: sudo linaro-media-create --rootfs ext3 --mmc /dev/sdb --dev vexpress --binary linaro-natty-alip-tar-20101202-1.tar.gz --hwpack hwpack_linaro-vexpress_20101201-1_armel_supported.tar.gz . . Populating Boot Partition Installing Boot Loader tar: binary/usr/lib/u-boot/ca9x4_ct_vxp/u-boot.bin: Not found in archive tar: Exiting with failure status due to previous errors I am not sure whether I am using right build images, can anyone point me to the working build images for vexpress platform. Thanks Praveen

14 years

useful embedded linux wiki

by Bill Traynor

Hello, It was suggested to me that I recommend to the list the http://elinux.orgwiki as a good online resource for embedded linux information. If you find it useful, please feel free to register and contribute ;) Thanks Bill

14 years

Re: dpkg: emdebian.org and other machines patched for armhf support

by Konstantinos Margaritis

On 7 December 2010 18:35, Paul Brook <paul(a)codesourcery.com> wrote: >> In essence, I would like to express my objection in having the same triplet >> for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they >> just haven't done the extensive compiling I have and didn't consider the >> problems (I doubt anyone else has built ~8000 packages for a hardfloat >> port). > > As the relevant upstream maintainer I'll confirm this objection. In the past > gcc used to try and guess which config to use based on variants of the > triplet. In practice this caused more problems than it solved, especially when > you have a single toolchain that can target multiple variants. > > If you want different triplets then I suggest you use the vendor field. e.g > arm-debian_armel-linux-gnueabi and arm-debian_armhf-linux-gnueabi. Which is exactly what I am doing. You are right I should be more specific. Right now, armhf uses arm-hardfloat-linux-gnueabi -which as was suggested here uses the vendor field. It works fine, in truth, only a handful of packages break with the vendor field and the fix is trivial. What was suggested to me was that the vendor field should *NOT* be used and a single arm-linux-gnueabi should be used for both softfp and hard ABIs. I'm sorry but especially in the case of compilers and in particular cross-compilers, this just does not work. Unless there is another way of OS (and ABI) detection, like the DEB_HOST_ABI fields, there is no way to know which ABI to compile from. So, my objection is in not keeping the arm-hardfloat-linux-gnueabi triplet. I did not suggest a different triplet altogether, just the ability to use the vendor field and thus in essence make a different triplet -but not too different. Konstantinos

14 years

Re: dpkg: emdebian.org and other machines patched for armhf support

by Konstantinos Margaritis

On Tuesday 07 December 2010 16:02:16 Hector Oron wrote: > Hello, > > I am patching machines to support armhf, which it is almost at 90% > built. I know you are very busy with squeeze release, but could you > give a comment if the patch is wrong or right, as we are using it for > patching machines? Why is it taking so long to include such > architecture? > Let me know if I can help you out doing a NMU if you do not have the > time. Nice timing Hector, I was just thinking of sending a mail to the lists (so I'm cross-posting this mail to both debian-arm and linaro-dev lists as they are [in]directly involved in this). In essence, I would like to express my objection in having the same triplet for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they just haven't done the extensive compiling I have and didn't consider the problems (I doubt anyone else has built ~8000 packages for a hardfloat port). So, what is the problem: I'm trying to port some compilers now to armhf now - gnat, openjdk, etc- using cross-compiling (you know, build a cross-compiler on an arch that already supports gnat, then use that cross-compiler to build a native binary and use that binary to build the final compiler on the native machine. It's a complicated process with lots of problems, but I've done this before -I actually did the gnat powerpc port for Debian back in 2000, using that same method, things have evolved since then but not that much. With a different triplet, I just have to add a new triplet entry for armhf to gnat's setup scripts. Using the same triplet, I would have to actually go to great lengths to change the scripts to use something else than the gnu triplet to decide cpu/system detection -not to mention that I would have to push for acceptance for each and every such patch. I'm sorry, but right now I have better things to do than this. Anyway, I know this point has been stressed before, but I now I would like to re-surface this issue again. Till now I was mostly indifferent, but now I'm convinced that we should *not* force the same triplets for the two abis until there is a concrete migration plan of OS detection using another method. It mostly ends down to unnecessary over-engineering with little benefit and way too many problems. I like simplicity and any other solution than a single triplet is not simple at the moment. So, what does this mean? It means that someone has first to propose a proper solution for handling this sort of stuff when a single triplet -something like that has been proposed in http://bugs.debian.org/596298 but though it's a good idea, it has not been discussed as much as it should. It has to actually be decided and even then we still would have to change many configure scripts to use that, as gcc for example configures based on the gnu triplet, NOT something as arbitrary as DEB_{HOST,BUILD}_ABI. In real terms, this means it's going to take a very long time to actually have something that works -no I don't think 6 months are enough. Anyway, with regards to the actual bug report, I have done a 1.15.8.6+armhf.1 release -in debian-ports.org/unreleased for now- which fixes a bug I missed previously. Some tests also fail, but that's beside the point, they have to be fixed to support quads as well -which I will do in the next days and I will send a complete patch. For that matter, I have tested the patch on amd64 and i386 and it doesn't break anything. The problem is that with ~7600 packages built and still the port is not recognized by dpkg. So, bottom line, until the issue with multiarch/DEB_HOST_ABI is actually *decided* could you please please get armhf support into dpkg proper? Or at least give a good reason why you do not accept the patch? Thanks Konstantinos

14 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev