Marking a toolchain or build releasable - for saving.

Paul, I was wondering if we could make a small change to android-build. I just recently tested: https://android-build.linaro.org/builds/~linaro-android/leb-panda/#build=166 It works great and I'd like to move it to a first 11.08 release. Its based on toolchain: https://android-build.linaro.org/

Re: [PATCH] ARM: do not mark CPU 0 as hotpluggable

On Fri, Jul 22, 2011 at 5:53 AM, Santosh Shilimkar wrote: > On 7/22/2011 6:15 PM, Woodruff, Richard wrote: >> >>> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- >>> kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh >> With fixed IRQ migration and forci

Re: [PATCH v3 1/2] cpumask: introduce cpumask for hotpluggable CPUs

On Thu, 2011-08-11 at 12:54 -0700, Mike Turquette wrote: > On some platforms it is possible to have some CPUs which support CPU > hotplug and some which do not. Currently the prescence of an 'online' > sysfs entry in userspace is adequate for applications to know that a CPU > supports hotplug, but

[PATCH v3 1/2] cpumask: introduce cpumask for hotpluggable CPUs

On some platforms it is possible to have some CPUs which support CPU hotplug and some which do not. Currently the prescence of an 'online' sysfs entry in userspace is adequate for applications to know that a CPU supports hotplug, but there is no convenient way to make the same determination in the

[PATCH v3 2/2] cpu: update cpu_hotpluggable_mask in register_cpu

Update the cpu_hotpluggable_mask for each registered CPU which supports hotplug. This makes it trivial for kernel code to know which CPUs support hotplug operations. Signed-off-by: Mike Turquette --- Change log: v2: no change v3: no change drivers/base/cpu.c |4 +++- 1 files changed, 3 ins

Re: [PATCH v2 0/2] new cpumask for hotpluggable CPUs

On Thu, 2011-08-11 at 12:25 -0700, Turquette, Mike wrote: > On Thu, Aug 11, 2011 at 11:30 AM, Peter Zijlstra wrote: > > On Wed, 2011-08-10 at 13:03 -0700, Mike Turquette wrote: > >> This patch series introduces a new cpumask which tracks CPUs that > >> support hotplugging. The purpose of this pat

Re: [PATCH v2 0/2] new cpumask for hotpluggable CPUs

On Thu, Aug 11, 2011 at 11:30 AM, Peter Zijlstra wrote: > On Wed, 2011-08-10 at 13:03 -0700, Mike Turquette wrote: >> This patch series introduces a new cpumask which tracks CPUs that >> support hotplugging.  The purpose of this patch series is to provide a >> simple method for kernel code to know

Re: [PATCH v2 1/2] cpumask: introduce cpumask for hotpluggable CPUs

On Wed, Aug 10, 2011 at 11:06 PM, Amit Kucheria wrote: > See comments inline. > > On 11 Aug 10, Mike Turquette wrote: >> On some platforms it is possible to have some CPUs which support CPU >> hotplug and some which do not.  Currently the prescence of an 'online' >> sysfs entry in userspace is ade

Linaro 11.08 weekly testing 2011-08-11

LEBs images on their way to the next release: 11.08. * Android for PandaBoard: http://snapshots.linaro.org/11.05-daily/linaro-android/leb-panda/20110811/ * Android for Snowball: http://snapshots.linaro.org/11.05-daily/linaro-android/leb-snowball/20110811/ * Ubuntu: http

Re: [PATCH v2 0/2] new cpumask for hotpluggable CPUs

On Wed, 2011-08-10 at 13:03 -0700, Mike Turquette wrote: > This patch series introduces a new cpumask which tracks CPUs that > support hotplugging. The purpose of this patch series is to provide a > simple method for kernel code to know which CPUs can be hotplugged and > which ones cannot. Potent

Re: What are the chances of a phone based developer image

On Tue, Aug 09, 2011 at 07:32:51PM -0300, Christian Robottom Reis wrote: > On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote: > > >You should definitely be trying to build using the Linaro 4.5 and 4.6 > > >compiler branches; they are pretty much guaranteed to give you better > > >performan

Re: [PATCH] add a test description for each test

ACK. On 11 Aug 11, Daniel Lezcano wrote: > Signed-off-by: Daniel Lezcano > --- > cpufreq/Makefile |2 ++ > cpufreq/cpufreq_01.txt |1 + > cpufreq/cpufreq_02.txt |1 + > cpufreq/cpufreq_03.txt |1 + > cpufreq/cpufreq_04.txt |1 + > cpufreq/cpufreq_05.txt |1 + > cpuf

[PATCH] add a test description for each test

Signed-off-by: Daniel Lezcano --- cpufreq/Makefile |2 ++ cpufreq/cpufreq_01.txt |1 + cpufreq/cpufreq_02.txt |1 + cpufreq/cpufreq_03.txt |1 + cpufreq/cpufreq_04.txt |1 + cpufreq/cpufreq_05.txt |1 + cpufreq/cpufreq_06.txt |1 + cpufreq/cpufreq_07.txt |1 +

[ACTIVITY] Android Platform Team 2011-07-31 to 2011-08-06

Key Points for wider discussion === JPEG pictures now can be viewed on Android platform with libjpeg-turbo successfully. Toolchain now supports CLooG-ISL and OpenMP. Team Highlights === Move to Android 2.3.5 is proceeding good. libvpx 0.9.6, x264, ffmpeg i

Re: [ANN] Linaro Android tree hosting switched to Gerrit

Hello, Here's update on the migration process: 1. I've made first pass thru updating wiki with new Android tree location. 2. LEB-Panda currently doesn't build. That's because it turned out that we have none tags at all in our existing (forked) Android components, and manifest of leb-panda appears

Re: [ANN] Linaro Android tree hosting switched to Gerrit

Hello Zach, On Thu, 11 Aug 2011 00:23:00 -0500 Zach Pfeffer wrote: > This looks really great Paul. Thanks! > > Time to start pushing changes... Actually, it would be nice for people to concentrate on updating their build configs, docs, exercising build system, to make sure that our existing in

Re: Hacking Android from a Toolchain perspective

Hello Michael, On Thu, 11 Aug 2011 16:30:42 +1200 Michael Hope wrote: > Hi there. One of our goals in toolchain is to give good support to > the Android group. I've written a page from the toolchain perspective > on what is Android, how do you build it, and how you do common > toolchainy tasks

Re: Why are our Android toolchains 32bit?

Hello Alexander, On Wed, 10 Aug 2011 16:48:23 +0200 Alexander Sack wrote: [] > Also our binary toolchain will probably become more useful for 32-bit > once we start talking about shipping NDK/SDK. Then, having just one > binary to verify could turn out to be a smart thing. Btw, NDK toolchain is