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

On 11 Aug 09, 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 there is no convenient

Re: [U-Boot] [PATCH v4 1/2] ARMV7: Add support for Samsung ORIGEN board

Hi Chander, [...] lease get rid of all these magic hard coded constants. Use symbolic names instead. If needed, auto-generate these from the respective C structs. If needed, create the C structs. I will change hard coded values to symbolic names While doing this, I find that the

Re: linaro libjpeg-turbo roadmap

On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall tom.g...@linaro.org wrote: Hi All, I thought I would clarify what is in store for the next few linaro cycles from a libjpeg-turbo perspective. 11.08 1.1.2 libjpeg-turbo (featuring cleaned up patches) upstreaming and support of what could be a late

Re: linaro libjpeg-turbo roadmap

On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack a...@linaro.org wrote: On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall tom.g...@linaro.org wrote: Hi All, I thought I would clarify what is in store for the next few linaro cycles from a libjpeg-turbo perspective. 11.08 1.1.2 libjpeg-turbo

Re: linaro libjpeg-turbo roadmap

On Wed, Aug 10, 2011 at 4:18 PM, Tom Gall tom.g...@linaro.org wrote: On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack a...@linaro.org wrote: On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall tom.g...@linaro.org wrote: Hi All, I thought I would clarify what is in store for the next few linaro cycles

Why are our Android toolchains 32bit?

Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines

Re: Why are our Android toolchains 32bit?

On Wed, Aug 10, 2011 at 4:29 PM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't

Re: linaro libjpeg-turbo roadmap

On Wed, Aug 10, 2011 at 09:18:04AM -0500, Tom Gall wrote: On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack a...@linaro.org wrote: Does this involve adding easy/automatic benchmarks so we can track a) improvements turbo gives over plain and b) improvements we do to turbo over time? If not, I

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

. Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations. Sorry about the delayed response. I did notice your mail last week but I was busy with our conference and then the first couple of days

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

2011/8/10 Ramana Radhakrishnan ramana.radhakrish...@linaro.org: . Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations. I would be interested in hearing how you get on with LTO and FDO on ARM.

Re: Why are our Android toolchains 32bit?

Bernhard Rosenkranzer wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't matter much, it doesn't make much sense to me - Android can't

[ANN] Linaro Android tree hosting switched to Gerrit

[originally sent from wrong email, so not sure if got thru] Hello, Linaro Android codebase migration to Gerrit, which was announced at Linaro Connect, happened today. From now, Linaro Android is available via: http://android.git.linaro.org/ Accompanied by Gerrit frontend at:

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

On Wed, Aug 10, 2011 at 1:42 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On 11 Aug 09, 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

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

On Wed, 10 Aug 2011 20:31:11 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: [originally sent from wrong email, so not sure if got thru] [] The official Linaro builds at https://android-build.linaro.org/ were converted to use new manifest location, and I'd like to ask other

Re: Why are our Android toolchains 32bit?

On Wed, 10 Aug 2011 10:48:26 -0700 Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: On 10 August 2011 09:20, Vladimir Pantelic vlado...@gmail.com wrote: fwiw, android GB and HC both build fine on 32 bit here... How so? Did you simply patch out the ifeq ($(BUILD_OS),linux)

Linaro Connect - Kernel Working Group Summary

Hi all, I wanted to provide an update of what the kernel team accomplished at Linaro Connect last week for those who were unable to attend. The team was split into two main groups, the first being led by Grant Likely and focusing on continuing the work on enabling Device Tree support on ARM

Re: Why are our Android toolchains 32bit?

On Thu, Aug 11, 2011 at 2:29 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't

[PATCH v2 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 mturque...@ti.com --- Change log: v2: no change drivers/base/cpu.c |4 +++- 1 files changed, 3

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

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. Potential users of this code might be a thermal mitigation technique

[PATCH v2 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

pm-qa test output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Amit, Here is the example output with the test description. The email wraps the lines, actually each test are one line output. Let me know if it is ok for you. Thanks -- Daniel [ ... ] ### ### cpufreq_04: ### test the change of the

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2011 10:03 PM, 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

Jenkins repo plugin

Hi, https://github.com/jenkinsci/repo-plugin is a new plugin for Jenkins to provide a repo SCM provider. This means that you can have Jenkins watch for changes via repo, and trigger actions based on that. I don't think this is useful to us with the things that we currently do, but may be

Re: [PATCH v2 2/2] cpu: update cpu_hotpluggable_mask in register_cpu

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2011 10:03 PM, Mike Turquette wrote: 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

Re: 3D Demo at ARM

Ramin, Thanks for the email. I've added linaro-dev to my response. The demo consisted of two identical PandaBoards with identical SD cards running the 3D benchmark of 0xbench using software 3D to amplify compiler and kernel improvements. 0xbench is a benchmarking program we ship with our Android

Hacking Android from a Toolchain perspective

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 like reproduce a compiler fault:

Re: pm-qa test output

On Wed, Aug 10, 2011 at 11:42 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Amit, Here is the example output with the test description. The email wraps the lines, actually each test are one line output. Let me know if it is ok for

Re: Why are our Android toolchains 32bit?

On 10 August 2011 14:44, Michael Hope michael.h...@linaro.org wrote: On Thu, Aug 11, 2011 at 2:29 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any

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

This looks really great Paul. Thanks! Time to start pushing changes... On 10 August 2011 12:48, Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Wed, 10 Aug 2011 20:31:11 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: [originally sent from wrong email, so not sure if got thru]