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 way to make the same determination in the kernel. To better model this relationship this patch introduces a new cpumask to track CPUs that support CPU hotplug operations. This new cpumask is populated at boot-time and remains static for the life of the machine. Bits set in the mask indicate a CPU which supports hotplug, but make no guarantees about whether that CPU is currently online or not. Likewise a cleared bit in the mask indicates either a CPU which cannot hotplug or a lack of a populated CPU. The purpose of this new cpumask is to aid kernel code which uses CPU to take CPUs online and offline. Possible uses are as a thermal event mitigation technique or as a power capping mechanism. Signed-off-by: Mike Turquette mturque...@ti.com --- include/linux/cpumask.h | 27 ++- kernel/cpu.c| 18 ++ 2 files changed, 40 insertions(+), 5 deletions(-) diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index b24ac56..9eed444 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -39,10 +39,11 @@ extern int nr_cpu_ids; * The following particular system cpumasks and operations manage * possible, present, active and online cpus. * - * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable - * cpu_present_mask - has bit 'cpu' set iff cpu is populated - * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler - * cpu_active_mask - has bit 'cpu' set iff cpu available to migration + * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable + * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable + * cpu_present_mask - has bit 'cpu' set iff cpu is populated + * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler + * cpu_active_mask - has bit 'cpu' set iff cpu available to migration * * If !CONFIG_HOTPLUG_CPU, present == possible, and active == online. * @@ -51,7 +52,11 @@ extern int nr_cpu_ids; * life of that system boot. The cpu_present_mask is dynamic(*), * representing which CPUs are currently plugged in. And * cpu_online_mask is the dynamic subset of cpu_present_mask, - * indicating those CPUs available for scheduling. + * indicating those CPUs available for scheduling. The + * cpu_hotpluggable_mask is also fixed at boot time, as the set of CPU + * id's which are possible AND can hotplug. Cleared bits in this mask + * mean that either the CPU is not possible, or it is possible but does + * not support CPU hotplug operations. * * If HOTPLUG is enabled, then cpu_possible_mask is forced to have * all NR_CPUS bits set, otherwise it is just the set of CPUs that @@ -61,6 +66,9 @@ extern int nr_cpu_ids; * depending on what ACPI reports as currently plugged in, otherwise * cpu_present_mask is just a copy of cpu_possible_mask. * + * If CONFIG_HOTPLUG_CPU is enabled, then cpu_hotpluggable_mask matches + * the description above, otherwise it is the empty set. + * * (*) Well, cpu_present_mask is dynamic in the hotplug case. If not * hotplug, it's a copy of cpu_possible_mask, hence fixed at boot. * @@ -76,6 +84,7 @@ extern int nr_cpu_ids; */ extern const struct cpumask *const cpu_possible_mask; +extern const struct cpumask *const cpu_hotpluggable_mask; extern const struct cpumask *const cpu_online_mask; extern const struct cpumask *const cpu_present_mask; extern const struct cpumask *const cpu_active_mask; @@ -85,19 +94,23 @@ extern const struct cpumask *const cpu_active_mask; #define num_possible_cpus() cpumask_weight(cpu_possible_mask) #define num_present_cpus() cpumask_weight(cpu_present_mask) #define num_active_cpus()cpumask_weight(cpu_active_mask) +#define num_hotpluggable_cpus() cpumask_weight(cpu_hotpluggable_mask) #define cpu_online(cpu) cpumask_test_cpu((cpu), cpu_online_mask) #define cpu_possible(cpu)cpumask_test_cpu((cpu), cpu_possible_mask) #define cpu_present(cpu) cpumask_test_cpu((cpu), cpu_present_mask) #define cpu_active(cpu) cpumask_test_cpu((cpu), cpu_active_mask) +#define cpu_hotpluggable(cpu)cpumask_test_cpu((cpu, cpu_hotpluggable_mask) missing closing bracket? #else #define num_online_cpus()1U #define num_possible_cpus() 1U #define num_present_cpus() 1U #define num_active_cpus()1U +#define num_hotpluggable_cpus() 0 #define cpu_online(cpu) ((cpu) == 0) #define
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 values written to the registers are used just once. So do you still prefer to have them as macros ? I did convert the register offsets and addresses to macros, but did not find it right to have macros for register values that are used just once. Please advise. Most of all we want to get rid of address constants in code. For _values_ that are written to some register, my personal preference is not so strong, alas if you _do_ use macros, usually already the macro name carries documentation as to what this is and it will make code reuse easier for the people having to maintain or build upon your code in the future. Cheers Detlev -- Zivilisation ist der Zaubertrick, der uns unsere wahre Natur verbirgt. -- Salman Rushdie -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 august upstream 1.2 release 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 would very much like to see that that's part early phases of the plan. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 (featuring cleaned up patches) upstreaming and support of what could be a late august upstream 1.2 release 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 would very much like to see that that's part early phases of the plan. 1.1.1 includes in cjpeg and djpeg (encode and decode respectively) timing code for measurement. Make test also includes timing code. It's less than perfect but it's there. Upstream 1.2's make test is improved and more fleshed out. Could it be better? When can code never be improved or have more and better test? ;-) -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 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 august upstream 1.2 release 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 would very much like to see that that's part early phases of the plan. 1.1.1 includes in cjpeg and djpeg (encode and decode respectively) timing code for measurement. Make test also includes timing code. It's less than perfect but it's there. Upstream 1.2's make test is improved and more fleshed out. Could it be better? When can code never be improved or have more and better test? ;-) Cool. Is hooking this up into lava-test framework for daily runs in the lab part of the current plan? If not, could you try to include that somehow? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... ttyl bero ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... That's a good question. It was an explicit decision from the past as we said we don't want to deviate from AOSP best practices unless we have very good arguments. 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. If you feel strongly this should be changed in future, let's discuss during this month so we can work eventual changes into our 11.09 plan preparations. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 would very much like to see that that's part early phases of the plan. 1.1.1 includes in cjpeg and djpeg (encode and decode respectively) timing code for measurement. Make test also includes timing code. It's less than perfect but it's there. Do we have a vanilla libjpeg run to compare against (and/or can we ensure we keep that handy for easy comparison)? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 this week have just disappeared with some internal training. I would be interested in hearing how you get on with LTO and FDO on ARM. Listening to Honza talking at the GCC unconference in London about the memory usage for full LTO with trunk I did wonder what would happen if we tried it on the ARM target to see what we got, but I never managed to get around to trying anything there :) . We did look at getting FDO working with Linaro GCC last cycle but there are still a couple of issues with PGO in Linaro GCC 4.5. With respect to LTO , the one problem we have currently is that the Neon intrinsics aren't streamed out and streamed back in. So you might have a few issues if your code uses arm_neon.h . https://bugs.launchpad.net/gcc-linaro/+bug/823548 is an example of this problem. This was fixed upstream and we probably just need to backport that into our 4.6 tree. I've tried a backport this morning and I think I have this right finally. If you could do a build and a firefox benchmark run in about 30-60 minutes by all means please do let us know how you get on and what you find. We've been steadily trying to improve the performance of the ARM toolchain and the biggest improvements you'll notice will be with the vectorizer but there will be other small improvements that you'll notice in other general areas of code generation. We would be interested in feedback about what can be done and to add to our queue of things to look at and improve for the ARM port of GCC. With respect to the images, Kiko's probably answered that bit. cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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. Listening to Honza talking at the GCC unconference in London about the memory usage for full LTO with trunk I did wonder what would happen if we tried it on the ARM target to see what we got, but I never managed to get around to trying anything there :) . We did look at getting FDO working with Linaro GCC last cycle but there are still a couple of issues with PGO in Linaro GCC 4.5. FYI. The toolchain benchmark suite derived from Google already includes the FDO mode, and I would suggest to enable it for comparisons. Android build system has (incomplete) FDO integration since Android 2.2[*]. In my experience, it sometimes helps the performance for special cases slightly. Sincerely, -jserv [*] The build system would perform build-run-build scheme with the help of ADB, which deploys the profiler on target. Option: BUILD_FDO_INSTRUMENT ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 currently be built on 32-bit machines (so it's not about fwiw, android GB and HC both build fine on 32 bit here... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[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: http://review.android.git.linaro.org/ It is recommended to perform a fresh checkout of the tree. To do that, run: repo init -u git://android.git.linaro.org/platform/manifest.git \ -b branch \ -m manifest branch and manifest are those you used before. E.g. repo init -u git://android.git.linaro.org/platform/manifest.git \ -b linaro_android_2.3.4 \ -m default.xml The official Linaro builds at https://android-build.linaro.org/ were converted to use new manifest location, and I'd like to ask other developers to convert their personal builds (I'm not trying to automate this so far, to make that everyone was in loop on what changed and how). To update, just change in a build config: MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git to MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git Old tree (git.linaro.org/android/*) was made inaccessible for the time being to help with updating all references to it. It should be back up shortly in read-only mode. (If there're immediate concerns, it's at git.linaro.org/android-old/ now and can be renamed back by anyone with git.linaro.org access). With the spirit of making one change at time, all developers still should have permissions similar to what they had before: anyone can still create branches and push changes directly to them (*1). However, once we finish updating build configs and docs for new tree location, the next step will be setting up a workflow based on mandatory code review, so I'd like to invite all developers to practice that right away. Details on how to submit change for review are given at https://wiki.linaro.org/Platform/Android/Gerrit (in particular, repo upload works now). (*1) The remote for such commits is different now of course, like this: ssh://pfal...@android.git.linaro.org:29418/platform/build . Replace pfalcon with you gerrit username and platform/build is the component you need. Please share any issues, concerns, and questions you may have related to this migration. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 for applications to know that a CPU supports hotplug, but there is no convenient way to make the same determination in the kernel. To better model this relationship this patch introduces a new cpumask to track CPUs that support CPU hotplug operations. This new cpumask is populated at boot-time and remains static for the life of the machine. Bits set in the mask indicate a CPU which supports hotplug, but make no guarantees about whether that CPU is currently online or not. Likewise a cleared bit in the mask indicates either a CPU which cannot hotplug or a lack of a populated CPU. The purpose of this new cpumask is to aid kernel code which uses CPU to take CPUs online and offline. Possible uses are as a thermal event mitigation technique or as a power capping mechanism. Signed-off-by: Mike Turquette mturque...@ti.com --- include/linux/cpumask.h | 27 ++- kernel/cpu.c | 18 ++ 2 files changed, 40 insertions(+), 5 deletions(-) diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index b24ac56..9eed444 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -39,10 +39,11 @@ extern int nr_cpu_ids; * The following particular system cpumasks and operations manage * possible, present, active and online cpus. * - * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable - * cpu_present_mask - has bit 'cpu' set iff cpu is populated - * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler - * cpu_active_mask - has bit 'cpu' set iff cpu available to migration + * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable + * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable + * cpu_present_mask - has bit 'cpu' set iff cpu is populated + * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler + * cpu_active_mask - has bit 'cpu' set iff cpu available to migration * * If !CONFIG_HOTPLUG_CPU, present == possible, and active == online. * @@ -51,7 +52,11 @@ extern int nr_cpu_ids; * life of that system boot. The cpu_present_mask is dynamic(*), * representing which CPUs are currently plugged in. And * cpu_online_mask is the dynamic subset of cpu_present_mask, - * indicating those CPUs available for scheduling. + * indicating those CPUs available for scheduling. The + * cpu_hotpluggable_mask is also fixed at boot time, as the set of CPU + * id's which are possible AND can hotplug. Cleared bits in this mask + * mean that either the CPU is not possible, or it is possible but does + * not support CPU hotplug operations. * * If HOTPLUG is enabled, then cpu_possible_mask is forced to have * all NR_CPUS bits set, otherwise it is just the set of CPUs that @@ -61,6 +66,9 @@ extern int nr_cpu_ids; * depending on what ACPI reports as currently plugged in, otherwise * cpu_present_mask is just a copy of cpu_possible_mask. * + * If CONFIG_HOTPLUG_CPU is enabled, then cpu_hotpluggable_mask matches + * the description above, otherwise it is the empty set. + * * (*) Well, cpu_present_mask is dynamic in the hotplug case. If not * hotplug, it's a copy of cpu_possible_mask, hence fixed at boot. * @@ -76,6 +84,7 @@ extern int nr_cpu_ids; */ extern const struct cpumask *const cpu_possible_mask; +extern const struct cpumask *const cpu_hotpluggable_mask; extern const struct cpumask *const cpu_online_mask; extern const struct cpumask *const cpu_present_mask; extern const struct cpumask *const cpu_active_mask; @@ -85,19 +94,23 @@ extern const struct cpumask *const cpu_active_mask; #define num_possible_cpus() cpumask_weight(cpu_possible_mask) #define num_present_cpus() cpumask_weight(cpu_present_mask) #define num_active_cpus() cpumask_weight(cpu_active_mask) +#define num_hotpluggable_cpus() cpumask_weight(cpu_hotpluggable_mask) #define cpu_online(cpu) cpumask_test_cpu((cpu), cpu_online_mask) #define cpu_possible(cpu) cpumask_test_cpu((cpu), cpu_possible_mask) #define cpu_present(cpu) cpumask_test_cpu((cpu), cpu_present_mask) #define cpu_active(cpu) cpumask_test_cpu((cpu), cpu_active_mask) +#define cpu_hotpluggable(cpu) cpumask_test_cpu((cpu, cpu_hotpluggable_mask) missing closing bracket? Oops. Will fix in V2. Thanks, Mike #else #define num_online_cpus() 1U #define num_possible_cpus() 1U #define num_present_cpus() 1U #define num_active_cpus() 1U +#define num_hotpluggable_cpus() 0 #define
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 developers to convert their personal builds (I'm not trying to automate this so far, to make that everyone was in loop on what changed and how). To update, just change in a build config: MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git to MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git I should also add that I updated manifests living at git://android.git.linaro.org/platform/manifest.git in linaro_android_2.3.4 and linaro-android-11.08-release branches. Manifests in other locations and branches need to be updated manually. Look at http://android.git.linaro.org/gitweb?p=platform/manifest.git;a=shortlog;h=refs/heads/linaro_android_2.3.4 for details. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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) build_arch := $(shell uname -m) ifneq (64,$(findstring 64,$(build_arch))) $(warning ) $(warning You are attempting to build on a 32-bit system.) $(warning Only 64-bit build environments are supported beyond froyo/2.2.) $(warning ) $(error stop) endif endif part of build/core/main.mk? (I never understood why they put it there, but never bothered to question it and patch it out). I personally did. I understand that what comes out is nothing official, but it helps to at least look at non-related build issues. I don't have strong opinion on whether we should switch for Linaro builds, but would like to see stronger motivation than it might be slightly faster ;-). There're in particular bunch of ideas how to make android-build quicker, but going for them w/o actual benchmarking might be waste of time or lead to adverse effects... ttyl bero -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 platforms. In addition to Linaro members, David Brown and Nicolas Ferre also worked on DT support for their platforms and all together the team got much accomplished in 5 days there with a number of patches ready for the 3.2 merge windows: * Several device drivers for the Freescale iMX were converted to use DT-base discovery. * Code was written to bridge between the Device Tree model and TI OMAP's HWMOD. * Initial support for DT was added to the Samsung Exynos, Qualcomm MSM86, and Atmel AT91 by Nicolas Ferre * DT skeleton code was written for the ARM Versatile and ST-E platforms. The rest of the team primarilly focused on code cleanup and development to work towards a multi-SOC zImage. Nicolas posted and original email with info at http://bit.ly/oVQRQm and folks took individual bits to work on. Russel King was also in attendance and there was good discussion around some of these topics. What we discovered is that many of these issues are multi-layered and as we start cleaning up one bit of code, we need to fix other areas to make them work consistently. The areas we looked into were: * Replacing low level IO accessor macros with runtime selected functions based on platform type. * Replacing the global NR_IRQS constant with per-board information * Removing duplicated low-level serial output functions. Currently the code to print Uncompressing kernel... and the code for low-level in-kernel serial output are completely different but could be made to be the same. At the end of the day, the method we're looking at using is providing a special node in the DT that contains the physical mapping of the debug serial registers in place. * Removing CLOCK_TICK_RATE from the kernel * Replace CONSISTENT_DMA_SIZE with a runtime variable * Removing arch_idle() and moving to using the run time selected pm_idle hooks. Similar work to be done with arch_reset() * Getting rid of VMALLOC_END. Russel and Nicolas agreed that we'll just use a static VMALLOC_END for everyone and insert static I/O mappings in there. In addition the the above work, KWG members also were involved in discussions about continuous integration and testing of the upstream kernels on ARM platforms, kernel development process at Linaro and how to better stay in sync with upstream, -stable patches for ARM platforms, Android development, and flash storage roadmap to name a few. Overall, the team had an extremely productive week of hacking on existing projects and on coming up with more detailed plans on what other items on which we need to focus. I want to thank everone on the team for their hard work last week and also the non-Linaro developers David Brown, Will Deacon, Nicolas Ferre, and Marc Zyngier for taking time to join us in hacking and planning. All together connect was a great technically focused event and I highly encourage folks to join us in Orlando in November. You can register now at http://connect.linaro.org/events/event/linaro-connect-q411/. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[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 insertions(+), 1 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 251acea..91ddcf8 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -224,8 +224,10 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
error = sysdev_register(cpu-sysdev);
- if (!error cpu-hotpluggable)
+ if (!error cpu-hotpluggable) {
register_cpu_control(cpu);
+ set_cpu_hotpluggable(num, true);
+ }
if (!error)
per_cpu(cpu_sys_devices, num) = cpu-sysdev;
if (!error)
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[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 which uses hotplug to lower temperature, or a power capping mechanism which uses hotplug to lower power consumption. All the of usual cpumask helper functions are created for this new mask. The second patch in this series simply sets the bit for elligible CPUs while they are being registered. The cpumask itself is static after boot and should not change (like the possbile mask). Mike Turquette (2): cpumask: introduce cpumask for hotpluggable CPUs cpu: update cpu_hotpluggable_mask in register_cpu drivers/base/cpu.c |4 +++- include/linux/cpumask.h | 27 ++- kernel/cpu.c| 18 ++ 3 files changed, 43 insertions(+), 6 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[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 the kernel. To better model this relationship this patch introduces a new cpumask to track CPUs that support CPU hotplug operations. This new cpumask is populated at boot-time and remains static for the life of the machine. Bits set in the mask indicate a CPU which supports hotplug, but make no guarantees about whether that CPU is currently online or not. Likewise a cleared bit in the mask indicates either a CPU which cannot hotplug or a lack of a populated CPU. The purpose of this new cpumask is to aid kernel code which uses CPU to take CPUs online and offline. Possible uses are as a thermal event mitigation technique or as a power capping mechanism. Signed-off-by: Mike Turquette mturque...@ti.com --- Change log: v2: fixed missing parentheses in cpumask_test_cpu and improved grammar in comments include/linux/cpumask.h | 27 ++- kernel/cpu.c| 18 ++ 2 files changed, 40 insertions(+), 5 deletions(-) diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index b24ac56..52e64a7 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -39,10 +39,11 @@ extern int nr_cpu_ids; * The following particular system cpumasks and operations manage * possible, present, active and online cpus. * - * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable - * cpu_present_mask - has bit 'cpu' set iff cpu is populated - * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler - * cpu_active_mask - has bit 'cpu' set iff cpu available to migration + * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable + * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable + * cpu_present_mask - has bit 'cpu' set iff cpu is populated + * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler + * cpu_active_mask - has bit 'cpu' set iff cpu available to migration * * If !CONFIG_HOTPLUG_CPU, present == possible, and active == online. * @@ -51,7 +52,11 @@ extern int nr_cpu_ids; * life of that system boot. The cpu_present_mask is dynamic(*), * representing which CPUs are currently plugged in. And * cpu_online_mask is the dynamic subset of cpu_present_mask, - * indicating those CPUs available for scheduling. + * indicating those CPUs available for scheduling. The + * cpu_hotpluggable_mask is also fixed at boot time as the set of CPU + * id's which are possible AND can hotplug. Cleared bits in this mask + * mean that either the CPU is not possible, or it is possible but does + * not support CPU hotplug operations. * * If HOTPLUG is enabled, then cpu_possible_mask is forced to have * all NR_CPUS bits set, otherwise it is just the set of CPUs that @@ -61,6 +66,9 @@ extern int nr_cpu_ids; * depending on what ACPI reports as currently plugged in, otherwise * cpu_present_mask is just a copy of cpu_possible_mask. * + * If HOTPLUG is not enabled then cpu_hotpluggable_mask is the empty + * set. + * * (*) Well, cpu_present_mask is dynamic in the hotplug case. If not * hotplug, it's a copy of cpu_possible_mask, hence fixed at boot. * @@ -76,6 +84,7 @@ extern int nr_cpu_ids; */ extern const struct cpumask *const cpu_possible_mask; +extern const struct cpumask *const cpu_hotpluggable_mask; extern const struct cpumask *const cpu_online_mask; extern const struct cpumask *const cpu_present_mask; extern const struct cpumask *const cpu_active_mask; @@ -85,19 +94,23 @@ extern const struct cpumask *const cpu_active_mask; #define num_possible_cpus()cpumask_weight(cpu_possible_mask) #define num_present_cpus() cpumask_weight(cpu_present_mask) #define num_active_cpus() cpumask_weight(cpu_active_mask) +#define num_hotpluggable_cpus()cpumask_weight(cpu_hotpluggable_mask) #define cpu_online(cpu)cpumask_test_cpu((cpu), cpu_online_mask) #define cpu_possible(cpu) cpumask_test_cpu((cpu), cpu_possible_mask) #define cpu_present(cpu) cpumask_test_cpu((cpu), cpu_present_mask) #define cpu_active(cpu)cpumask_test_cpu((cpu), cpu_active_mask) +#define cpu_hotpluggable(cpu) cpumask_test_cpu((cpu, cpu_hotpluggable_mask)) #else #define num_online_cpus() 1U #define num_possible_cpus()1U #define num_present_cpus() 1U #define num_active_cpus() 1U +#define num_hotpluggable_cpus()0 #define cpu_online(cpu)((cpu) == 0) #define cpu_possible(cpu) ((cpu) == 0) #define cpu_present(cpu) ((cpu) == 0) #define cpu_active(cpu)((cpu) == 0) +#define cpu_hotpluggable(cpu) 0 #endif /* verify cpu
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 frequency is effective in 'userspace' mode ### cpufreq_04.0/cpu0 checking setting frequency '2.6 GHz'... PASS cpufreq_04.1/cpu0 checking setting frequency '2.6 GHz'... PASS cpufreq_04.2/cpu0 checking setting frequency '2.0 GHz'... PASS cpufreq_04.3/cpu0 checking setting frequency '1.6 GHz'... PASS cpufreq_04.4/cpu0 checking setting frequency '1.2 GHz'... PASS cpufreq_04.5/cpu0 checking setting frequency '800.0 MHz'... PASS cpufreq_04.0/cpu1 checking setting frequency '2.6 GHz'... PASS cpufreq_04.1/cpu1 checking setting frequency '2.6 GHz'... PASS cpufreq_04.2/cpu1 checking setting frequency '2.0 GHz'... PASS cpufreq_04.3/cpu1 checking setting frequency '1.6 GHz'... PASS cpufreq_04.4/cpu1 checking setting frequency '1.2 GHz'... PASS cpufreq_04.5/cpu1 checking setting frequency '800.0 MHz'... PASS ### ### cpufreq_05: ### test 'ondemand' and 'conservative' trigger correctly the configuration directory ### cpufreq_05.0/cpu1 checking 'ondemand' directory exists... PASS cpufreq_05.0/cpu1 checking 'conservative' directory exists... PASS cpufreq_05.0/cpu1 checking 'ondemand' directory is not there... PASS cpufreq_05.1/cpu1 checking 'conservative' directory is not there... PASS cpufreq_05.2/cpu1 checking 'ondemand' directory exists... PASS cpufreq_05.3/cpu1 checking 'conservative' directory exists... PASS ### ### cpufreq_06: ### test the change of the frequencies affect the performances of a test program ### cpufreq_06.0/cpu0 checking deviation for frequency 2.6 GHz... PASS cpufreq_06.1/cpu0 checking deviation for frequency 2.6 GHz... FAIL cpufreq_06.2/cpu0 checking deviation for frequency 2.0 GHz... FAIL cpufreq_06.3/cpu0 checking deviation for frequency 1.6 GHz... PASS cpufreq_06.4/cpu0 checking deviation for frequency 1.2 GHz... FAIL cpufreq_06.5/cpu0 checking deviation for frequency 800.0 MHz... FAIL cpufreq_06.0/cpu1 checking deviation for frequency 2.6 GHz... PASS cpufreq_06.1/cpu1 checking deviation for frequency 2.6 GHz... FAIL cpufreq_06.2/cpu1 checking deviation for frequency 2.0 GHz... FAIL cpufreq_06.3/cpu1 checking deviation for frequency 1.6 GHz... PASS cpufreq_06.4/cpu1 checking deviation for frequency 1.2 GHz... FAIL cpufreq_06.5/cpu1 checking deviation for frequency 800.0 MHz... FAIL ### ### cpufreq_07: ### test the load of the cpu affects the frequency with 'ondemand' ### cpufreq_07.0/cpu0 checking 'ondemand' increase frequency on load... PASS cpufreq_07.1/cpu0 checking 'ondemand' decrease frequency on idle... FAIL cpufreq_07.0/cpu1 checking 'ondemand' increase frequency on load... PASS cpufreq_07.1/cpu1 checking 'ondemand' decrease frequency on idle... PASS ### ### cpufreq_08: ### test the load of the cpu does not affect the frequency with 'userspace' ### http://www.linaro.org/ Linaro.org ? Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQu00AAoJEAKBbMCpUGYAK70IAJMaNajxLrAR4tLlv4aFyFHl DB9M0pX4OgLmxVJ18zGR5oOr/IzjXXMZTrJrfQJre0DLzCi/yur0wJntJFEUbUy/ M/xHJFBEEY8GX7wxws5LGaR9b/ASGfax4LZVo85CAldaHCl6QzTXolsj/IRvB/r+ uVoCToUMWQT2oaOwW7q9U1ItBPgFb0yTrqTcz1jgC3IMFPNh867sRH/z+UFfHzF6 yBaZ34E5bNO/VGQuGOmWp5vEl//KlvGmGAKPWb/KxHD0gEwVoF+2gf+fWvdOf9sD CC23Hc5FnqrP5SaRLwHRuO7NcxIX2ooUADn6ojN3SJm0nN/qx3qMyTMqakfkxgk= =4oGS -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 that a CPU supports hotplug, but there is no convenient way to make the same determination in the kernel. To better model this relationship this patch introduces a new cpumask to track CPUs that support CPU hotplug operations. This new cpumask is populated at boot-time and remains static for the life of the machine. Bits set in the mask indicate a CPU which supports hotplug, but make no guarantees about whether that CPU is currently online or not. Likewise a cleared bit in the mask indicates either a CPU which cannot hotplug or a lack of a populated CPU. The purpose of this new cpumask is to aid kernel code which uses CPU to take CPUs online and offline. Possible uses are as a thermal event mitigation technique or as a power capping mechanism. Signed-off-by: Mike Turquette mturque...@ti.com Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org - -- http://www.linaro.org/ Linaro.org ? Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQu/KAAoJEAKBbMCpUGYAxnoH/0+WtrRGq0oOjkU8jIxzAEUP OW6S7EQT13v97YapaEwUZpHOzrdeEa9bV5sVI3uc3H9n6dnQbh25eMuhiH/dTwF6 LHV1Tdv7/+ghiSc4NJunpXjAsObezUgTV9n2Zoip3kAfhMdV5DntJu0Izkdb5lkA AD5CqV6oHqC0spa2/nMMeOYsdp3hLP3hA5wCyE8a2rxvbytxl2jRVommXOpF3AnI s3OS7oyVFLpdvxVdAio1cXvM6vILtJFArAqw88AJUBsUsuehRxeOYVvTR3/z4RZD LNEH72IkGY/8OVYp9/VoixWgWTUhXUR5BZwAjCP7a+xQk/1qK1LAM+/CXimwND0= =90gJ -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 useful sometime, e.g. * if we want to add a build on any change option to the build service, rather than just build daily * As part of the solution to https://wiki.linaro.org/Platform/Android/Specs/BuildTestedMerge Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 mturque...@ti.com Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org - -- http://www.linaro.org/ Linaro.org ? Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQvAUAAoJEAKBbMCpUGYADTYH/3jGeK5pryiVKaxQ7wUBwsG6 7ugSLCCgBVUL6ueuVmlphhfW8Vv9Uz72LlJnaJUmJ0deK/Rf5x1ccFulBTtIsyjK Zbw4Wg0MYxfNo0OAi7OSjWMUw31PC8kKVBSUZd3zHeqi6TanKUtxR5im4EWGhQbc +Njhx2jAqZBEEcPnODiRx+CbYJX17N2Cesmk8Z+Tk00LIpM30iGGX15ZWXnV6KWM zD3vG7ATLa/rv1/xPa67SDXdZIo99wDodjtjTFPClygM/XTSNBiIxsm9LnnUkmyw gw1Q6Ng+wo2XyhxJ//b+kM0natnc7Tl6RtDIL7T+j9rIAdf8Sz9DPgmafWQRxYY= =hwkF -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 images from 0xlab. Each build ran the same Android userspace, 2.3.4, but one was using the 2.6.36 Linux kernel and GCC 4.4 from the stock AOSP distribution and one was using an upgraded Linaro 3.0 Linux kernel with Linaro GCC 4.5. We ran the board in 640x480 mode so that we wouldn't be memory bound. Users can use and recreate the builds easily. To program the builds visit 2.6.36 https://android-build.linaro.org/builds/~linaro-android/panda-11.05-release/ and 3.0 https://android-build.linaro.org/builds/~linaro-android/panda-11.07-release/ To recreate the builds from scratch visit: https://wiki.linaro.org/Platform/Android/GetSource https://wiki.linaro.org/Platform/Android/BuildSource Here's a video of demo running: https://plus.google.com/104422661029399872488/posts/Rjmo5HCHQxZ (this is running in 720P mode not 640x480) I'm happy to help you reproduce the demos. Feel free to drop by #linaro-android on freenode. -Zach On 10 August 2011 06:24, Ramin Zaghi ramin.za...@arm.com wrote: Hi Zach I didn’t get a chance to see you yesterday so got your card from the table. I was one of the first employees of our Multimedia Division who was from a game-dev background. Your demos were interesting so I was wondering if I could ask for a bit of explanation, and what they were? I also like to know what engine they were running or was it a custom bit of code that you wrote? Thanks Ramin -- Ramin Zaghi Software Engineer Processor Division / PDSW -- ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ, UK -- Tel: +44 1223 406347 [Extn 22347] -- -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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: https://wiki.linaro.org/MichaelHope/Sandbox/AndroidAndToolchain Comments are welcome. It needs sections on how the compiler is configured, running a program using adb, and basic debugging. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 you. Thanks -- Daniel [ ... ] ### ### cpufreq_04: ### test the change of the frequency is effective in 'userspace' mode ### cpufreq_04.0/cpu0 checking setting frequency '2.6 GHz'... PASS cpufreq_04.1/cpu0 checking setting frequency '2.6 GHz'... PASS cpufreq_04.2/cpu0 checking setting frequency '2.0 GHz'... PASS Yes, this looks good to me. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 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 (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on. I agree with Michael. That's a little more deviation than we should introduce. I think creating an investigation BP for it for 11.09 would be a good idea though. -Zach -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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] [] The official Linaro builds at https://android-build.linaro.org/ were converted to use new manifest location, and I'd like to ask other developers to convert their personal builds (I'm not trying to automate this so far, to make that everyone was in loop on what changed and how). To update, just change in a build config: MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git to MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git I should also add that I updated manifests living at git://android.git.linaro.org/platform/manifest.git in linaro_android_2.3.4 and linaro-android-11.08-release branches. Manifests in other locations and branches need to be updated manually. Look at http://android.git.linaro.org/gitweb?p=platform/manifest.git;a=shortlog;h=refs/heads/linaro_android_2.3.4 for details. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
