linaro-dev March 2013

linaro-dev@lists.linaro.org

51 participants
53 discussions

Start a nNew thread

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

by Bill Huang

11 years, 9 months

lists.linaro.org maintenance completed

by IT Services

This is to let you know that the migration of lists.linaro.org has been successfully completed. As per the email I sent on Wednesday, it may take some time for the new address of the server to be seen by your computer. You can check this by trying to connect to the web site: http://lists.linaro.org/ If you are able to connect and you do not get an error, this means you are connecting to the new server and you can send email to the lists. If you experience any problems after the weekend and you find that you still cannot connect to the server, please reply to this email to let us know. Regards Philip IT Services Manager Linaro

11 years, 9 months

Re: [BUG] v7_coherent_kern_range broken on big.LITTLE

by Jon Medhurst (Tixy)

On Fri, 2013-02-15 at 10:33 +0000, Lorenzo Pieralisi wrote: > On Fri, Feb 15, 2013 at 10:04:37AM +0000, Jon Medhurst (Tixy) wrote: > > On Thu, 2013-02-14 at 17:16 +0000, Will Deacon wrote: > > > Hi Tixy, > > > > > > On Thu, Feb 14, 2013 at 05:07:43PM +0000, Jon Medhurst (Tixy) wrote: > > > > The function v7_coherent_kern_range uses the macro icache_line_size to > > > > read the current CPUs icache line size for the purpose of invalidating > > > > all cache lines in the given range. > > > > > > > > Unfortunately, on the TC2 big.LITTLE test chip, the A15 icache line size > > > > is 64 bytes, but the A7 size is only 32 bytes. So when the function > > > > executes on the A15 it will miss out every alternate cache line for the > > > > A7. > > > > > > There is a signal (IMINLN) to the core which allows A15 to behave as though > > > it has a 32-byte line size and this should be driven correctly for big/little. > > > > How do we set that signal? Is that something we have to set up in Linux > > or is it something that we expect the Firmware to set up? > > If I am not mistaken, SCC register at offset 0x400 (bit 7) allows IMINLN to > be forced to 0 (ie Instruction Cache minimum line size == 32 bytes). > > This can be done through board.txt so that it is set up as we want. According to the TRM for TC2 the default value for that register is 0x33330c80, so adding the line "SCC: 0x400 0x33330c00" and incrementing TOTALSCCS does the trick, and the A15's now report an icache size of 32. We'll have to get everyone with a TC2 to make that change then? As this is a TC2 issue, and not Linux related, shall we drop linux-arm-kernel from all future replies to avoid the noise? I've added linaro-dev to the cc list so this continues to get public visibility. -- Tixy

11 years, 9 months

Linaro Release 13.02 Postmortem Summary

by David Zinman

Postmortem and lessons learned for Linaro's release 2013.02 https://wiki.linaro.org/Cycles/1302/Release/Review Highlights and Key Successes ============================ http://www.linaro.org/downloads/1302 http://wiki.linaro.org/Cycles/1302/Release#Release_Information The Linaro Engineering Group (LEG) released Linaro UEFI 2013.02 which fixed several bugs targeting the Arndale boards. LEG also added ARM support to libhugetlbfs, merged into next branch--package is available from Linaro's Overlay PPA. The Linaro Developer Platform team completed the CI bring up for the Arndale board: Arndale image reports have been added to the LAVA dashboard and daily tests are run on the board. The team has also enabled UEFI support in the Arndale hardware pack. The Linaro Toolchain Team released Linaro GCC 4.7-2013.02-01 based off GCC 4.7.2+svn195745 and includes arm/aarch64-4.7-branch up to svn revision 195716, support for Cortex-A7 backported from trunk. The 2013.02 Linaro Toolchain Binaries release were updated to latest Linaro GCC 4.7 2013.02-01 which included upgrades for binutils to v2.23.1, eglibc to v2.17 and the kernel header to v3.7. Blueprints ========= The number of high or essential priority blueprints that missed the cycle: Android 7 out of 11 Developer Platform 5 out of 9 Infrastructure 1 out of 4 Lava 4 out of 7 QA 2 out of 9 Total 19 out of 40 48% of high or essential priority blueprints scheduled for this cycle were not delivered. Total blueprints: 35 out of 69 missed the cycle. High priority missed blueprints recap: 12.05: 19 out of 48, 39% 12.06: 13 out of 31, 42% 12.07: 14 out of 31, 45% 12.08: 6 out of 26, 23% 12.09: 9 out of 28, 32% 12.10: 15 out of 38, 39% 12.11: 7 out of 19, 37% 12.12: not available 13.01: 9 out of 28, 33% * Not included is data from working groups and landing teams Source: https://docs.google.com/spreadsheet/ccc?key=0AjEaTwrvj1bidDFUaFJpYXJJS25CV1… -- David Zinman, Project Manager Linaro.org | Open source software for ARM SoCs

11 years, 9 months

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

by Bill Huang

Add the below two notifier events so drivers which are interested in knowing the clock status can act accordingly. This is extremely useful in some of the DVFS (Dynamic Voltage Frequency Scaling) design. CLK_PREPARED CLK_UNPREPARED Signed-off-by: Bill Huang <bilhuang(a)nvidia.com> --- drivers/clk/clk.c | 75 ++++++++++++++++++++++++++------------------------- include/linux/clk.h | 2 ++ 2 files changed, 41 insertions(+), 36 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index ed87b24..d78ed16 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) @@ -550,6 +586,7 @@ void clk_unprepare(struct clk *clk) { mutex_lock(&prepare_lock); __clk_unprepare(clk); + __clk_notify(clk, CLK_UNPREPARED, clk->rate, clk->rate); mutex_unlock(&prepare_lock); } EXPORT_SYMBOL_GPL(clk_unprepare); @@ -598,6 +635,8 @@ int clk_prepare(struct clk *clk) mutex_lock(&prepare_lock); ret = __clk_prepare(clk); + if (!ret) + __clk_notify(clk, CLK_PREPARED, clk->rate, clk->rate); mutex_unlock(&prepare_lock); return ret; @@ -749,42 +788,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..16c1d92 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -43,6 +43,8 @@ struct clk; #define PRE_RATE_CHANGE BIT(0) #define POST_RATE_CHANGE BIT(1) #define ABORT_RATE_CHANGE BIT(2) +#define CLK_PREPARED BIT(3) +#define CLK_UNPREPARED BIT(4) /** * struct clk_notifier - associate a clk with a notifier -- 1.7.9.5

11 years, 9 months

Fwd: tjbench for libjpeg-8c

by Tom Gall

CCing the list as well. ---------- Forwarded message ---------- From: Tom Gall <tom.gall(a)linaro.org> Date: Wed, Mar 13, 2013 at 10:35 AM Subject: Re: tjbench for libjpeg-8c To: Anand Kumar <bala.anand.k(a)gmail.com> Hi Anand, I had to build tjbench from other sources in order to use it with libjpeg8c. It's a pretty straight forward recompile. It's been awhile since I had worked on this. I seem to remember I used the libjpeg-turbo tjbench source code. I'll be working on this again quite quite soon as I need to refresh and push things upstream. On Wed, Mar 13, 2013 at 8:10 AM, Anand Kumar <bala.anand.k(a)gmail.com> wrote: > With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have a > query on Libjpeg8c's tjbench. > https://wiki.linaro.org/TomGall/LibJpeg8. > > When i downloaded libjpeg8c source code from the community, i couldn't find > the tjbench support in libjpeg8c package. But in the above mentioned link i > could see the benchmark results of tjbench for Libjpeg8c. > > Please let me know, where i can get the libjpeg8c package with tjbench > support. > > ~ Ananda > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Tech Lead, Graphics Working Group | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org h) tom_gall att mac.com

11 years, 9 months

ATTENTION: OpenEmbedded layers from Linaro have new structure

by Marcin Juszkiewicz

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Today I made several changes to OpenEmbedded layers hosted on git.linaro.org: - - meta-aarch64 - - meta-linaro Meta-aarch64 is now empty and is obsolete. Probably will be removed from server in about month or two. Meta-linaro repository got new structure based on meta-openembedded one and contains three layers: - - meta-aarch64 - - meta-linaro - - meta-linaro-toolchain Today meta-aarch64 is just a copy of old one but everything not related to ARMv8 will be moved from it to meta-linaro. Meta-linaro-toolchain contains just gcc-linaro and support for external Linaro cross toolchains (armv7a and armv8 ones). I considered creation of meta-aarch64-arm-toolchain one with ARM Ltd. version of gcc but it is not often used option so can stay where it is now (meta-aarch64). Instructions how to start building for ARMv8 (with OE) are in wiki: https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded Note that any scripts present in 'meta-aarch64' got dropped. If you want easy way then use 'jenkins-setup' scripts like it is described in wiki. They are written to be as easy to use as possible. If you have any problems/questions: reply to this email. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRQJERAAoJECbKqQEReiUeKFgQAMUYDB1ymQs8ZspWVynJVJMQ InFsFQUd/QZCgNB9GcG6IepzmViHeMlIxNQ7u+KFABGV8uAz8gwdgcPtWwa/dc1b wu8u84mmwy77WBIMuX087AiXdg8WhJDJz5sztBoK2PL8Ljn1TFB/R17Ew90eN3zn o1DpPnbgMGs67phNiTy8GiQxyaaLZub0ZZZ5v00tWdt7x4vazw6n2r8/o+wzGLj2 536KI13Sepso2dg2mrpqzrwVH8KFP7S/rRiDdKI4Gw9FlTPiaiEEadX7OPKx8YC5 j1WIR0u66LCSe+F3NsfNfEgTOXPGVUNgqvemwGYXQuOLUKz7nnnkEdVRUegSuEVj +bZsgzFunghOsvEgX4ynxLVXgOrkiH4PPMhD+OWcB1pso9+ZdVFTVO2oGOnDg9pK ov7lidEoUDDIZqHxjy5cV36jDnXt8BTI9uEIjVo9gH/0g/67QImXHVONcppg2MfM GDfhYorkah3VTo9zgHZKCDEIstT1OsCSg+PNeKCAN6fDUdmnzGxCJNEj2CaRAzaI vJekxAK0+ptscJ9c+bUmAtcBK+XRvJ9K3naN+apUm13Y6INwKuS68knWzOJc0xhd rpPQ2EcYd8FP1gspjNJPyQKWr2pAUGQkOGkhHrsrb4nj6mkMDDgZ2ET1x8uxI056 vMRn7PKF7x3bItUP9NzA =GNf7 -----END PGP SIGNATURE-----

11 years, 9 months

tjbench for libjpeg-8c

by Anand Kumar

With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have a query on Libjpeg8c's tjbench. https://wiki.linaro.org/TomGall/LibJpeg8. When i downloaded libjpeg8c source code from the community, i couldn't find the tjbench support in libjpeg8c package. But in the above mentioned link i could see the benchmark results of tjbench for Libjpeg8c. Please let me know, where i can get the libjpeg8c package with tjbench support. ~ Ananda

11 years, 9 months

Planned maintenance - lists.linaro.org

by IT Services

Hello You are receiving this email because you are subscribed to one or more mailing lists provided by the lists.linaro.org server. IT Services are announcing planned maintenance for this server scheduled for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work is to move the service to another server. There will be some disruption during this maintenance. In order to ensure that you do not accidentally try to use the service while it is being moved, the current server will be shut down at 2pm. A further email will be sent on Friday afternoon to confirm that the migration of the service is completed. However, due to the way servers are found, it may take a while before your computer is able to connect to the relocated service. After the old server has been shut down, email sent to any of the lists will be queued, but it is possible that the sending server will still trying to deliver the email to the old server rather than the new one when it is started. It is therefore *strongly* recommended that you do not send any email to an @lists.linaro.org email address until you can connect to the new service, which you will be able to test by trying to use a web browser to connect to http://lists.linaro.org after you receive the email confirming that the migration has been completed. Since the old service will be shut down, if you are able to connect, you can be sure you have connected to the new service. If by Monday you are still unable to connect to the service or you are not able to send email to an @lists.linaro.org email address, please send an email to its(a)linaro.org. Thank you. Regards Philip IT Services Manager Linaro

11 years, 9 months

Re: libjpeg8c vs libjpeg-turbo with libjpeg8 compat on

by Balasubramaniam, Anandakumar

Dear Tom, With respect to your nice investigation report on Libjpeg-turbo Vs Libjpeg8c, I have a query on Libjpeg8c's tjbench https://wiki.linaro.org/TomGall/LibJpeg8 When i took the Libjpeg8c source code from the Libjpeg community, I did not find the tjbench support in the libjpeg8c package. But in your Libjpeg8c's performance report, I have observed that tjbench is used for benchmarking. So please let me know whether the tjbench support for Libjpeg8c package is released to the community. Thanks & Regards, Ananda Kumar B ________________________________ This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. - This mail is sent via Sony Asia Pacific Mail Gateway..

11 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev March 2013