Hi,
This is a message sent out once per week to call on our community to
help test the Linaro evaluation builds we produce. If you have supported
hardware, as found on:
http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/
please help our initiative by testing the official Linaro Evaluation
On Thu, May 5, 2011 at 2:59 AM, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
On Wed, 4 May 2011 09:30:53 +0300, Paul Sokolovsky
paul.sokolov...@linaro.org wrote:
On Wed, 04 May 2011 11:40:50 +1200
Michael Hudson-Doyle michael.hud...@canonical.com wrote:
that Android team's
Hey there,
I was asked today in the board meeting about the use of NEON
routines in the kernel; I said we had looked into this but hadn't done
it because a) it wasn't conclusively better and b) if better, it would
need to be done conditionally per-platform. But I wanted to double-check
that's
Hello all:
Lee will be giving a talk about upstreaming in his electrifying
presentation titled What is upstreaming and why should we bother?.
The presentation [1] is targeted at managers involved in such act or
engineers who just started upstreaming, or want to do it.
Please spread the work to
Please note that for this week's test, the nano image has seen a
significant drop in size. (~33M compressed, smaller than a hwpack now
:-)
If you run into a functional issue involving the nano image, please
copy me on the bug so I can look into it ASAP!
Regards,
Tom
On Thu, May 5, 2011 at 2:28
On Thu, May 05, 2011 at 03:47:08PM +0100, David Gilbert wrote:
Hi Kiko,
On 5 May 2011 15:21, Christian Robottom Reis k...@linaro.org wrote:
Hey there,
I was asked today in the board meeting about the use of NEON
routines in the kernel; I said we had looked into this but hadn't done
it
Hi,
The Android track has a similar session where we are going to discuss
upstreaming to the Android project.
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-upstreaming
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-upstreamingWe
will discuss what
On 5 May 2011 17:21, Christian Robottom Reis k...@linaro.org wrote:
Hey there,
I was asked today in the board meeting about the use of NEON
routines in the kernel; I said we had looked into this but hadn't done
it because a) it wasn't conclusively better and b) if better, it would
need to
On 5 May 2011 17:57, Steve McIntyre steve.mcint...@linaro.org wrote:
Technically it *can*, but you'll then have to be responsible for
dealing with all the extra register save/restores for context
switches. Normal wisdom is that it's just not worth that cost unless
you're doing an extended
David Gilbert david.gilb...@linaro.org writes:
Hi Kiko,
On 5 May 2011 15:21, Christian Robottom Reis k...@linaro.org wrote:
Hey there,
I was asked today in the board meeting about the use of NEON
routines in the kernel; I said we had looked into this but hadn't done
it because a) it
Hi
As some of you know we have something called Star rating for supported
boards.
There are [1][2][3] pages on Linaro wiki which can be used as kind of
base for understanding what is all about.
We need to discuss what exactly our requirements mean and how to check
are they supported - for that
On 5 May 2011 17:45, Deepak Saxena dsax...@plexity.net wrote:
On May 05 2011, at 16:46, David Gilbert was caught saying:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
Not quite:
a) Neon memcpy/memset is worse on A9 than non-neon
Scott,
It would be nice to have some landing team folks subscribe to
https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-kernel-leb-process
I believe we have had some chaos at the end of both release cycles so
far with trying to add additional features to the packaged kernel. It
On 5 May 2011 18:17, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
Not quite:
a) Neon memcpy/memset is worse on A9 than non-neon versions (better
on
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
Not quite:
a) Neon memcpy/memset is worse on A9 than non-neon versions (better
on A8 typically)
That is not my experience at all. On the
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 17:45, Deepak Saxena dsax...@plexity.net wrote:
On May 05 2011, at 16:46, David Gilbert was caught saying:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
Not quite:
a)
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 18:17, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert david.gilb...@linaro.org writes:
Not quite:
a) Neon memcpy/memset
Zach,
Unfortunately CCS Licenses are not free yet.
To get a license you can either buy an XDS100 and use the free license that
works with that or you can buy a CCS license from TI or a distributor.
There is also a 90 day eval license that you can get here:
On Thu, 5 May 2011, David Gilbert wrote:
If people believe it's worth breaking the context-switching taboo and
putting a neon version into the kernel then yes I agree it's something
you'd want to do as a build and/or runtime selection - but that's
quite a big taboo to break.
There is no
On Thu, 5 May 2011, Måns Rullgård wrote:
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 17:45, Deepak Saxena dsax...@plexity.net wrote:
On May 05 2011, at 16:46, David Gilbert was caught saying:
On 5 May 2011 16:08, Måns Rullgård m...@mansr.com wrote:
David Gilbert
On 5 May 2011 18:44, Måns Rullgård m...@mansr.com wrote:
The relative performance of NEON vs non-NEON seems to depend a lot on
the size (relative to cache), alignment, and whether or not any
prefetching (explicit PLD, automatic, or preload engine) is used.
Yes, agreed - Neon does very well in
David Gilbert david.gilb...@linaro.org writes:
On 5 May 2011 18:44, Måns Rullgård m...@mansr.com wrote:
The relative performance of NEON vs non-NEON seems to depend a lot on
the size (relative to cache), alignment, and whether or not any
prefetching (explicit PLD, automatic, or preload
On Thu, 5 May 2011, Måns Rullgård wrote:
David Gilbert david.gilb...@linaro.org writes:
The memcpy case is not interesting. Not at all. Most kernel memcpy
calls are for small size copies. The large copy instances are just bad
and misdesigned in the first place if they rely on memcpy
From: Stefan Nilsson XK stefan.xk.nils...@stericsson.com
If there is only 1 function interrupt registered it is possible to
improve performance by directly calling the irq handler
and avoiding the overhead of reading the CCCR registers.
Signed-off-by: Per Forlin per.for...@linaro.org
Acked-by:
Optimize performance for single irq
Changes since v2.
* Clarify comment in process_sdio_pending_irqs
* Simplify sdio_single_irq if-condition
Stefan Nilsson XK (1):
sdio: optimized SDIO IRQ handling for single irq
drivers/mmc/core/sdio_irq.c | 33 -
On Thu, 5 May 2011, David Gilbert wrote:
Yes, while I've not actually looked at coding CRC32 or the crypto things
I agree that they feel like they have much more room for working with;
it's outside of the scope of what I was asked to look at however.
Well, you said that the current memcpy
On Thu, 5 May 2011, Christian Robottom Reis wrote:
Hey there,
I was asked today in the board meeting about the use of NEON
routines in the kernel; I said we had looked into this but hadn't done
it because a) it wasn't conclusively better and b) if better, it would
need to be done
Last quasi-random question of the night: would reviving the kmemcheck
ARM port (that IIRC was hacked up a while back) be something useful, or
is it something that is too niche to be worth it? At the board's
request, I was looking across platform gaps and this feature was one of
the things that I
Thanks for the tip.
I haven't gotten a kernel panic since I used that config mix as my base.
However, I have been getting strange memory errors from applications.
AJ ONeal
On Mon, May 2, 2011 at 9:36 PM, Andy Doan andy.d...@linaro.org wrote:
On 05/02/2011 05:45 PM, AJ ONeal wrote:
Is there
David Gilbert david.gilb...@linaro.org writes:
The memcpy case is not interesting. Not at all. Most kernel memcpy
calls are for small size copies. The large copy instances are just bad
and misdesigned in the first place if they rely on memcpy (maybe they
should simply have a custom copy
On Thu, 5 May 2011 15:49:06 +0200, Alexander Sack a...@linaro.org wrote:
On Thu, May 5, 2011 at 2:59 AM, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
On Wed, 4 May 2011 09:30:53 +0300, Paul Sokolovsky
paul.sokolov...@linaro.org wrote:
On Wed, 04 May 2011 11:40:50 +1200
I believe that some of these random application crashes claiming to be
out-of-memory have to do with the fact that swap is off by default.
Knowing that to be an issue from my experience with OpenEmbedded
I preemptively set
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
in /etc/sysctl.conf
On Thu, 5 May 2011, Christian Robottom Reis wrote:
Last quasi-random question of the night: would reviving the kmemcheck
ARM port (that IIRC was hacked up a while back) be something useful, or
is it something that is too niche to be worth it? At the board's
request, I was looking across
On Thu, May 05, 2011 at 07:28:33PM -0400, Nicolas Pitre wrote:
On Thu, 5 May 2011, Christian Robottom Reis wrote:
Last quasi-random question of the night: would reviving the kmemcheck
ARM port (that IIRC was hacked up a while back) be something useful, or
is it something that is too niche
On Thu, 5 May 2011, Christian Robottom Reis wrote:
On Thu, May 05, 2011 at 07:28:33PM -0400, Nicolas Pitre wrote:
On Thu, 5 May 2011, Christian Robottom Reis wrote:
Last quasi-random question of the night: would reviving the kmemcheck
ARM port (that IIRC was hacked up a while back) be
35 matches
Mail list logo
