I've now got a Gumstix Stagecoach with six NFS root OMAP3-based boards
up and running in my office. That brings the grand total up to ten
Cortex-A8 based boards on the local network.
Eventually these or something similar will go up into the data centre
but, until then, I might as well put them to use. Any suggestions?
If you'd like access then drop me a line.
-- Michael
Hi,
Just a reminder to say that the weekly Linaro release meeting will be
held tomorrow at 17:00 UTC in the #linaro-meeting irc channel on
freenode. The wiki page for the meeting can be found at:
https://wiki.linaro.org/Releases/WeeklyReleaseMeeting/2010-12-02
If you have something to add to the discussion either reply directly to
this email or add you notes to the wiki page above.
See you there.
Regards,
Jamie.
--
Linaro Release Manager
Currently cpufreq transition latency value does not really reflect the actual
OMAP OPP transition delay. This patch has the actual latency value.
I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value
goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer
expiry.
With this change, performance of ondemand governor is improved when tested
using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand
performance as 40% of performance governor, and with this patch it's around 70%
(using below procedure).
cpufreq-bench:
http://lwn.net/Articles/339862/http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/
Command used for performance testing:
cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -v
Signed-off-by: Vishwanath BS <vishwanath.bs(a)ti.com>
---
arch/arm/plat-omap/cpu-omap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
old mode 100644
new mode 100755
index c47faf8..d3fc423
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
policy->max = policy->cpuinfo.max_freq;
policy->cur = omap_getspeed(0);
- /* FIXME: what's the actual transition time? */
- policy->cpuinfo.transition_latency = 300 * 1000;
+ /* Program the actual transition time for worstcase */
+ policy->cpuinfo.transition_latency = 30 * 1000;
return 0;
}
--
1.7.0.4
Hi,
Tomorrow Linaro will release the Alpha-1 images. In anticipation of this
the release candidate has been produced and is ready for testing. If you
have supported hardware and are willing to test please head on over to:
http://releases.linaro.org/platform/linaro-n
and select an image type. Please take the files from the alpha-1-rc
directory and combine them with a alpha-1-rc hardware pack from the
hwpack directory at the same location. Instructions on how to do this
can be found at:
http://wiki.linaro.org/Releases/MilestoneBuilds
The QA tool, qatracker, has been setup ready for test results and can be
found at:
http://qatracker.linaro.org
and instructions on how to test are available on the wiki at:
http://wiki.linaro.org/QA/QATracker
Alpha-1 is a very early snapshot of Linaro's development progress for
the 11.04 release. It *will* contain bugs but with the help of our
testers, these bugs will be squished as the development cycle
progresses.
Regards,
Jamie.
--
Linaro Release Manager
Hi Stephen,
please consider to start merging our ux500-core branch into
linux-next:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
Branch: ux500-core
(NB: there is a "next" branch, which include patches to multiple
subsystems, don't merge that, this is just the ux500 core.)
I rebase this regularly to Torvalds' -rc tags, hope that's OK.
All code is being reviewed on the linux-arm-kernel list, and the
patches here are intended for pull request to Russell King who
in turn take them upstream. I hope this procedure is
acceptable.
We currently have some of these patches in Russells patch tracker
as well, but they will be taken out in favor of the pull approach
once this branch lands in -next.
Yours,
Linus Walleij