linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Anca Emanuel

http://landley.net/notes.html#16-03-2013 Let's jump back to the 3.6 kernel release, where I was reverting all the irq routing stuff back to what it looked like in 3.3 or so, and both scsi and the ethernet controller worked. In that context, we got the following boot messages: PCI: enabling device 0000:00:0d.0 (0100 -> 0103) sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 27 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: SCSI BUS has been reset. ... 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) PCI: enabling device 0000:00:0c.0 (0100 -> 0103) 8139cp 0000:00:0c.0 eth0: RTL-8139C+ at 0xc8874400, 52:54:00:12:34:56, IRQ 27 So both the scsi and ethernet were sharing IRQ 27. After they moved the IRQ controller start from 0 to 32 (for not obvious reason), this means the corresponding IRQ is now 27+32=59. And this is the one that works. Here are the new boot messages after the fix I checked in yesterday: PCI: enabling device 0000:00:0d.0 (0100 -> 0103) sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 59 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: SCSI BUS has been reset. ... 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) PCI: enabling device 0000:00:0c.0 (0100 -> 0103) 8139cp 0000:00:0c.0 eth0: RTL-8139C+ at 0xd0874400, 52:54:00:12:34:56, IRQ 62 Spot anything? Like the fact that 62 != 59? And thus, when I run the nativel linux from scratch build and it tries to distribute compilation over distcc, we get: === zlib(2 of 48) Checking for gcc... irq 59: nobody cared (try booting with the "irqpoll" option) Backtrace: [<c00113e8>] (dump_backtrace+0x0/0x110) from [<c001152c>] (dump_stack+0x18/0x1c) r6:00000000 r5:c02eabdc r4:c02eabdc [<c0011514>] (dump_stack+0x0/0x1c) from [<c004d384>] (__report_bad_irq+0x28/0xb0) ... (mondo useless stack dump that just says the IRQ came from hardware) Disabling IRQ #59 ... (more stack dump) 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff Oddly, QEMU's scsi device still seems to be usable so at a guess they didn't actually disable IRQ 59? Dunno... So let's annotate and see: slot=12 pin=1 irq=62 slot=13 pin=1 irq=59

13 years, 1 month

Re: BLS 13.03 RC1 ready for testing

by Dietmar Eggemann

Hi Viresh, (1) Recently I have done a lot of testing for the new RCU functionality (new RCU FNOHZ implementation, updated RCU no-callback implementation) which is scheduled for 3.11/3.12 mainline. In my tests it helped to keep the A15's quiet and showed power savings for some workloads. During last Linaro Connect people started to ask me if we can bring these features in already earlier. Would it be possible for you to merge in 'idlenocb.2013.03.18b' (based on v3.9-rc2) (or newer) from 'git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git' into your big.LITTLE MP tree? I talked to Paul McKenney about this and he would like to have this additional test coverage. I have performed the following tests: System comes up and pm-qa (cpufreq, cpuidle, cpuhotplug) on nano and FTS (mpbasic, mpcore, mpextended, mploadbalance, mpregression, pmump) on Android FS look good. (2) On top of the merge, we must assure that the TC2 default config file gets changed: Change the config file: * Set CONFIG_RCU_FAST_NO_HZ=y * Set CONFIG_RCU_NOCB_CPU=y * Set CONFIG_RCU_NOCB_CPU_ALL=y diff -Naur config_orig .config --- config_orig 2013-03-13 14:15:10.574248125 +0000 +++ .config 2013-03-13 14:15:34.334248346 +0000 @@ -93,9 +93,12 @@ CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set -# CONFIG_RCU_FAST_NO_HZ is not set +CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_RCU_NOCB_CPU is not set +CONFIG_RCU_NOCB_CPU=y +# CONFIG_RCU_NOCB_CPU_NONE is not set +# CONFIG_RCU_NOCB_CPU_ZERO is not set +CONFIG_RCU_NOCB_CPU_ALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 Cheers, -- Dietmar -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

13 years, 1 month

[RELEASE] big LITTLE MP Upstream based of 3.9-rc3

by Viresh Kumar

Hi Guys, [All this is not yet mainlined and is WIP] Linaro and ARM are developing Linux solutions for big LITTLE Architecture. And I maintain all the stable stuff on this here: [1] and this gets pulled in by Andrey for every linux-linaro release. [1] by itself isn't much usable as it doesn't have many bits which are pulled in by Andrey, like: tc2 support from tixy and Android stuff from John. As this is a stable release it contains what works best and it may contain stuff that is never going to be mainlined. So, i have started to maintain another release for people who are only interested in working with latest upstream effort in this direction. It is created with following steps: - Checkout a new branch based of linux-linaro latest release tag - git revert Merge with big-LITTLE-MP-master-v* - git merge with [2] And we finally get [3] which only contains all the big LITTLE MP efforts that are under review on LKML. [3] has all the bits required to test it on TC2 as it is based of linux-linaro release. Interested people may check it out to give it a try. -- viresh [1]: https://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/hea… [2]: https://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/hea… [3]: https://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/hea…

13 years, 1 month

[PATCH v3 0/5] common clk framework reentrancy & dvfs, take 3

by Mike Turquette

Hello, This series implements reentrancy for the common clk implementation of the clk.h api. Making reentrant calls into the clock framework is both necessary and desirable for many use cases such as enabling off-chip clocks via i2c. The first patch in the series implements this. A neat side effect of reentrancy is that it is possible for platforms using voltage regulators controlled via i2c to register rate-change notifier handlers to scale voltage as a function of clock rate. This is an effective way to implement dynamic voltage & frequency scaling. Patch #2 implements a helper function for registering such a notifier handler. The third patch in the series demonstrates dvfs on OMAP platforms by modifying the cpufreq-omap driver; it migrates the voltage scaling logic out of the cpufreq driver's .target callback and registers callbacks via the helper introduced in patch #2. Patches four and five are purely test coverage. And what better way to test than to muck with fragile PLL programming code? These patches test out a lot of the aforementioned reentrancy in the OMAP3+ DPLL code. They are not for merging, but as a demonstration of what is now possible. Finally, I know that Documentation/clk.txt needs an update for these changes but I wanted this on the list before I flew out to LCA 2013. I'll provide that update during or after the conference. Two previous (and considerably more insane) attempts at this, v1: http://article.gmane.org/gmane.linux.kernel/1327866 v2: http://marc.info/?l=linux-kernel&m=134507429302463&w=2 Mike Turquette (5): clk: allow reentrant calls into the clk framework clk: notifier handler for dynamic voltage scaling cpufreq: omap: scale regulator from clk notifier HACK: set_parent callback for OMAP4 non-core DPLLs HACK: omap: opp: add fake 400MHz OPP to bypass MPU arch/arm/mach-omap2/cclock44xx_data.c | 1 + arch/arm/mach-omap2/clock.h | 1 + arch/arm/mach-omap2/dpll3xxx.c | 107 ++++++++++---- arch/arm/mach-omap2/opp4xxx_data.c | 18 +++ drivers/clk/Makefile | 1 + drivers/clk/clk.c | 254 ++++++++++++++++++++++++--------- drivers/clk/dvfs.c | 125 ++++++++++++++++ drivers/cpufreq/omap-cpufreq.c | 82 +++-------- include/linux/clk.h | 27 +++- 9 files changed, 459 insertions(+), 157 deletions(-) create mode 100644 drivers/clk/dvfs.c -- 1.7.10.4

13 years, 1 month

API to download from snapshots and releases is live

by James Tunnicliffe

Hi, There are many scripts in use that parse the web interface for snapshots and releases.linaro.org. This is far from ideal because changes to the web interface can result in the scripts breaking. To alleviate this problem an API has been introduced. The API is very simple, just two new URLs and a new header when downloading files. <server>/api/ls/<path to file> returns a JSON document containing all the data shown by a file listing on the web interface. It can target either a directory of a file. <server>/api/license/<path to file> returns a JSON document containing the licence information for the file pointed to. Both the license text and the digest used to accept the license are returned. Including the digest means that the choice of digest used internally can change without re-writing clients - to the client this is just a magic string and they don't need to care how it is generated. When downloading a file you simply include the header LICENSE_ACCEPTED, its value being a space separated list of license digests representing the licenses that you have accepted. e.g. (license text and digest removed for brevity) http://snapshots.linaro.org/api/ls/quantal/hwpacks/snowball/latest { "files": [ { "mtime": "15-Mar-2013 08:29", "name": "hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt", "size": "762", "type": "text", "url": "/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt" }, { "mtime": "15-Mar-2013 08:31", "name": "hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz", "size": "18.1M", "type": "other", "url": "/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz" } ] } http://snapshots.linaro.org/api/license/quantal/hwpacks/snowball/latest/hwp… { "licenses": [ { "text": "license text...", "digest": "license digest..." } ] } wget --header="LICENSE_ACCEPTED: license digest..." http://snapshots.linaro.org/quantal/hwpacks/snowball/latest/hwpack_linaro-s… There is a example client script that illustrates how to use the API here: http://bazaar.launchpad.net/~linaro-automation/linaro-license-protection/tr… Usage: download.py <URL> If URL points to a directory all files are downloaded. If URL points to a file, just that file is downloaded. It prints the license(s) for each file and waits for the user to accept each one. It also stores which licenses the user has accepted so they don't need to be re-accepted if the text hasn't changed. -- James Tunnicliffe

13 years, 1 month

[PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare

by Bill Huang

Add notifier calls in clk_prepare and clk_unprepare so drivers which are interested in knowing that clk_prepare/unprepare call can act accordingly. The existing "clk_set_rate" notifier is not enough for normal DVFS inplementation since clock might be enabled/disabled at runtime. Adding these notifiers is useful on DVFS core which take clk_prepare as a hint on that the notified clock might be enabled later so it can raise voltage to a safe level before enabling the clock, and take clk_unprepare as a hint that the clock has been disabled and is safe to lower the voltage. The added notifier events are: PRE_CLK_PREPARE POST_CLK_PREPARE ABORT_CLK_PREPARE PRE_CLK_UNPREPARE POST_CLK_UNPREPARE Signed-off-by: Bill Huang <bilhuang(a)nvidia.com> --- drivers/clk/clk.c | 88 ++++++++++++++++++++++++++++++--------------------- include/linux/clk.h | 5 +++ 2 files changed, 57 insertions(+), 36 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index ed87b24..ac07c6e 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -516,6 +516,42 @@ struct clk *__clk_lookup(const char *name) /*** clk api ***/ +/** + * __clk_notify - call clk notifier chain + * @clk: struct clk * that is changing rate + * @msg: clk notifier type (see include/linux/clk.h) + * @old_rate: old clk rate + * @new_rate: new clk rate + * + * Triggers a notifier call chain on the clk rate-change notification + * for 'clk'. Passes a pointer to the struct clk and the previous + * and current rates to the notifier callback. Intended to be called by + * internal clock code only. Returns NOTIFY_DONE from the last driver + * called if all went well, or NOTIFY_STOP or NOTIFY_BAD immediately if + * a driver returns that. + */ +static int __clk_notify(struct clk *clk, unsigned long msg, + unsigned long old_rate, unsigned long new_rate) +{ + struct clk_notifier *cn; + struct clk_notifier_data cnd; + int ret = NOTIFY_DONE; + + cnd.clk = clk; + cnd.old_rate = old_rate; + cnd.new_rate = new_rate; + + list_for_each_entry(cn, &clk_notifier_list, node) { + if (cn->clk == clk) { + ret = srcu_notifier_call_chain(&cn->notifier_head, msg, + &cnd); + break; + } + } + + return ret; +} + void __clk_unprepare(struct clk *clk) { if (!clk) @@ -549,7 +585,14 @@ void __clk_unprepare(struct clk *clk) void clk_unprepare(struct clk *clk) { mutex_lock(&prepare_lock); + + if (clk->notifier_count) + __clk_notify(clk, PRE_CLK_UNPREPARE, clk->rate, clk->rate); + __clk_unprepare(clk); + if (clk->notifier_count) + __clk_notify(clk, POST_CLK_UNPREPARE, clk->rate, clk->rate); + mutex_unlock(&prepare_lock); } EXPORT_SYMBOL_GPL(clk_unprepare); @@ -597,7 +640,16 @@ int clk_prepare(struct clk *clk) int ret; mutex_lock(&prepare_lock); + + if (clk->notifier_count) + __clk_notify(clk, PRE_CLK_PREPARE, clk->rate, clk->rate); + ret = __clk_prepare(clk); + if (!ret && clk->notifier_count) + __clk_notify(clk, POST_CLK_PREPARE, clk->rate, clk->rate); + else if (clk->notifier_count) + __clk_notify(clk, ABORT_CLK_PREPARE, clk->rate, clk->rate); + mutex_unlock(&prepare_lock); return ret; @@ -749,42 +801,6 @@ long clk_round_rate(struct clk *clk, unsigned long rate) EXPORT_SYMBOL_GPL(clk_round_rate); /** - * __clk_notify - call clk notifier chain - * @clk: struct clk * that is changing rate - * @msg: clk notifier type (see include/linux/clk.h) - * @old_rate: old clk rate - * @new_rate: new clk rate - * - * Triggers a notifier call chain on the clk rate-change notification - * for 'clk'. Passes a pointer to the struct clk and the previous - * and current rates to the notifier callback. Intended to be called by - * internal clock code only. Returns NOTIFY_DONE from the last driver - * called if all went well, or NOTIFY_STOP or NOTIFY_BAD immediately if - * a driver returns that. - */ -static int __clk_notify(struct clk *clk, unsigned long msg, - unsigned long old_rate, unsigned long new_rate) -{ - struct clk_notifier *cn; - struct clk_notifier_data cnd; - int ret = NOTIFY_DONE; - - cnd.clk = clk; - cnd.old_rate = old_rate; - cnd.new_rate = new_rate; - - list_for_each_entry(cn, &clk_notifier_list, node) { - if (cn->clk == clk) { - ret = srcu_notifier_call_chain(&cn->notifier_head, msg, - &cnd); - break; - } - } - - return ret; -} - -/** * __clk_recalc_rates * @clk: first clk in the subtree * @msg: notification type (see include/linux/clk.h) diff --git a/include/linux/clk.h b/include/linux/clk.h index b3ac22d..41d567d 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -43,6 +43,11 @@ struct clk; #define PRE_RATE_CHANGE BIT(0) #define POST_RATE_CHANGE BIT(1) #define ABORT_RATE_CHANGE BIT(2) +#define PRE_CLK_PREPARE BIT(3) +#define POST_CLK_PREPARE BIT(4) +#define ABORT_CLK_PREPARE BIT(5) +#define PRE_CLK_UNPREPARE BIT(6) +#define POST_CLK_UNPREPARE BIT(7) /** * struct clk_notifier - associate a clk with a notifier -- 1.7.9.5

13 years, 1 month

Test Result Summary of Linaro 13.03 Release for Linux Linaro ubuntu Quantal.

by Botao Sun

Linaro 13.03 Release (Calendar Week 13): Here is test result summary for Linux Linaro ubuntu Quantal image on following boards: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdEtLT… 1) ARM Versatile Express A9; 2) Samsung Arndale; 3) TI Panda 4430; 4) TI Panda 4460; 5) ST Ericsson Snowball. Synopsis: Kernel version on all boards has been upgraded to "3.9.0-1"; TI Panda 4460 booting failed. 1. ARM Versatile Express A9 + Linux Linaro Quantal (Column O): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV… It keeps exactly same status since calendar week 50 last year: only "Halt" & "Device Tree" test failed, all other features work well. 2. Samsung Arndale + Linux Linaro Quantal (Column I): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdGZJS… It keeps same status as last week: system hangs during the Power Management test, HDMI display is unavailable. All other features work well. 3. TI Panda 4430 + Linux Linaro Quantal (Column O): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… WiFi, HDMI and DVI-D are unavailable. All other features work well. 4. TI Panda 4460 + Linux Linaro Quantal (Column O): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… System booting failed since 3 weeks ago, all test cases are blocked. No release for this board in this month. 5. ST Ericsson Snowball + Linux Linaro Quantal (Column P): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFJ4X… SD/MMC test works well now, I/O error has been eliminated. Kernel panic has gone in power management test but another test case "thermal_03.1" failed there. "Reboot" & HDMI display are still unavailable. All other features work well. For the previous week test summary (Calendar Week 12), please refer to attachment. Thank you. Best Regards Botao Sun

13 years, 1 month

second raring ringtail test rebuild

by Matthias Klose

A second test rebuild of raring ringtail was started yesterday for the amd64, i386 and armhf architectures. Currently running, and with mostly idle buildds over easter and the current freeze it will hopefully finish within ten days. Results can be seen at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-201303… The archive for the test rebuild is https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/ Some common build failures are: - underlinking: symbols used in linked object files, which formerly were resolved by linked libraries. The fix almost always is to add the library (mentioned in the error message) to the link command. - Tcl/Tk migration to multiarch locations. For autoconf based packages it should be enough to adjust the configure arguments for the Tcl/Tk libraries. The location for the header files didn't change. - eglibc-2.17 changes: -Werror=unused-result used together with -Werror. - Some glib/gtk/dbus related build and test failures, however there is no common pattern yet. Please help fixing the build failures for the final release. Matthias

13 years, 1 month

Question about flashbench results

by Harvey Chapman

[ Please Cc me on replies ] The README for flashbench shows numbers that only descend. Can someone help me decode the following alignment results? Perhaps the README could be updated, too? root@spot-372b21:/var/volatile/media/sda1# ./flashbench -a /dev/mmcblk0 --blocksize=1024 --count=100 align 2147483648 pre 1.82ms on 2.74ms post 2.1ms diff 784µs align 1073741824 pre 1.79ms on 2.68ms post 2.05ms diff 757µs align 536870912 pre 1.78ms on 2.67ms post 2.05ms diff 755µs align 268435456 pre 1.79ms on 2.66ms post 2.04ms diff 749µs align 134217728 pre 1.79ms on 2.67ms post 2.04ms diff 753µs align 67108864 pre 1.78ms on 2.66ms post 2.05ms diff 750µs align 33554432 pre 1.79ms on 3.38ms post 2.19ms diff 1.39ms align 16777216 pre 1.84ms on 3.56ms post 2.19ms diff 1.54ms align 8388608 pre 1.85ms on 2.73ms post 2.04ms diff 786µs align 4194304 pre 1.84ms on 3.56ms post 2.2ms diff 1.54ms align 2097152 pre 1.83ms on 2.69ms post 2.26ms diff 648µs align 1048576 pre 1.81ms on 2.85ms post 2.24ms diff 826µs align 524288 pre 1.83ms on 2.95ms post 2.24ms diff 920µs align 262144 pre 1.87ms on 2.18ms post 2.18ms diff 162µs align 131072 pre 1.89ms on 2.2ms post 2.2ms diff 161µs align 65536 pre 1.9ms on 2.21ms post 2.21ms diff 160µs align 32768 pre 1.91ms on 2.21ms post 2.18ms diff 160µs align 16384 pre 1.92ms on 2.22ms post 2.19ms diff 168µs align 8192 pre 1.92ms on 2.22ms post 2.19ms diff 168µs align 4096 pre 2.08ms on 2.08ms post 2.04ms diff 19.5µs align 2048 pre 2.15ms on 2.15ms post 2.11ms diff 18.1µs root@spot-372b21:/var/volatile/media/sda1# find /sys/block/mmcblk0/device/ -maxdepth 1 -type f | xargs head ==> /sys/block/mmcblk0/device/uevent <== DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SD8GB MODALIAS=mmc:block ==> /sys/block/mmcblk0/device/cid <== 4134325344384742300030018f00b367 ==> /sys/block/mmcblk0/device/csd <== 400e00325b5900003b777f800a40009f ==> /sys/block/mmcblk0/device/scr <== 0235800000000000 ==> /sys/block/mmcblk0/device/date <== 03/2011 ==> /sys/block/mmcblk0/device/fwrev <== 0x0 ==> /sys/block/mmcblk0/device/hwrev <== 0x3 ==> /sys/block/mmcblk0/device/manfid <== 0x000041 ==> /sys/block/mmcblk0/device/name <== SD8GB ==> /sys/block/mmcblk0/device/oemid <== 0x3432 ==> /sys/block/mmcblk0/device/serial <== 0x0030018f ==> /sys/block/mmcblk0/device/type <== SD root@spot-372b21:/var/volatile/media/sda1#

13 years, 1 month

Quantal developer rootfs issue

by Renato Golin

Hi folks, I installed the panda-quantal_developer_20130128-58.img.gz on an old Pandaboard A1 and apt-get update got a new kernel and have overwritten the preEnv.txt boot=UUID=...hash... into boot=UUID=rootfs, only that rootfs is not a device. It fell back to busybox saying couldn't find root, so I re-wrote the file to have the correct UUID and it booted correctly. Not sure anyone has seen this, but seems like a simple bug to fix... cheers, --renato

13 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev