On 10 August 2011 12:44, Michael Hope wrote:
> 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.
If it actually builds on 32 bit hosts, I agree -- but in that case we
should patch out the fact that t
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 adequate for applications to know that a CPU
> supports hotplug, bu
This looks really great Paul. Thanks!
Time to start pushing changes...
On 10 August 2011 12:48, Paul Sokolovsky wrote:
> On Wed, 10 Aug 2011 20:31:11 +0300
> Paul Sokolovsky wrote:
>
>> [originally sent from wrong email, so not sure if got thru]
>>
> []
>> The official Linaro builds at https://
On 10 August 2011 14:44, Michael Hope wrote:
> On Thu, Aug 11, 2011 at 2:29 AM, 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
On Wed, Aug 10, 2011 at 11:42 PM, Daniel Lezcano
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
>
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/An
Hi Detlev,
On 10 August 2011 15:48, Detlev Zundel wrote:
> 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.
> >>>
> >>
> >
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
-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 Turquett
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 usef
-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 kno
-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 frequenc
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
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
drivers/base/cpu.c |4 +++-
1 files changed, 3 insertions(+), 1
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 wh
On Thu, Aug 11, 2011 at 2:29 AM, 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 m
Hi,
The patch which should come as a reply to this email contains a fastboot
gadget for u-boot. I don't claim that the code has been tested or
anything. I just want to post what I have now and get some feedback on it.
The code uses the "newer" gadget API which is used by the rndis gadget for
inst
On Wed, 10 Aug 2011 10:48:26 -0700
Bernhard Rosenkranzer wrote:
> On 10 August 2011 09:20, Vladimir Pantelic 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,
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 platf
On Wed, 10 Aug 2011 20:31:11 +0300
Paul Sokolovsky 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 pe
On 10 August 2011 09:20, Vladimir Pantelic 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
On Wed, Aug 10, 2011 at 1:42 AM, Amit Kucheria 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
[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.andr
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 curren
2011/8/10 Ramana Radhakrishnan :
>> . 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 tal
On Wed, Aug 10, 2011 at 10:05 AM, Christian Robottom Reis
wrote:
> On Wed, Aug 10, 2011 at 09:18:04AM -0500, Tom Gall wrote:
>> On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack wrote:
>> > Does this involve adding easy/automatic benchmarks so we can track a)
>> > improvements turbo gives over plai
> . 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
On Wed, Aug 10, 2011 at 09:18:04AM -0500, Tom Gall wrote:
> On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack 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 ver
On Wed, Aug 10, 2011 at 4:29 PM, 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 m
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
On Wed, Aug 10, 2011 at 4:18 PM, Tom Gall wrote:
> On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack wrote:
>> On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall wrote:
>>> Hi All,
>>>
>>> I thought I would clarify what is in store for the next few linaro
>>> cycles from a libjpeg-turbo perspective.
>>>
>>
On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack wrote:
> On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall 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 patche
On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall 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 upstr
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
11.09
1.2 upstream based linaro release (presum
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
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 convenie
36 matches
Mail list logo
