On Tue, 12 Jul 2011 08:53:29 +1200, Michael Hudson-Doyle
wrote:
> > > > Then (whether there is an upstream change or not) it should be uploaded
> > > to a PPA. I think the part here that I don't really get is basically
> > > how to use bzr build-deb in practice. But I've just found
> > > http:/
On Mon, 11 Jul 2011 11:41:17 +0200, Zygmunt Krynicki
wrote:
> Forwarding at it got bounced (odd?)
Yeah, my fault. I always forget the "lists." in
linaro-dev@lists.linaro.org...
> -- Wiadomość oryginalna --
> Temat: Re: ppas, version numbers, releases and validation.linaro.org
> Data: M
As Alexander says, we need to be able to reference the sha since our
"pinned-manifest" list all the subgit syncables by sha.
Like this:
https://android-build.linaro.org/jenkins/job/linaro-android_beagle-11.07-release/1/artifact/build/out/pinned-manifest.xml
-Zach
On 11 July 2011 16:18, Alexande
On 7/11/2011 1:14 PM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 01:05:20PM -0700, Santosh Shilimkar wrote:
(Just to add few more points on top of what Colin already commented)
On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo
On Mon, Jul 11, 2011 at 4:11 PM, Zach Pfeffer wrote:
> In-order to make reproducible builds we create pinned manifests with
> each commit explicitly listed. We also use this method to create a
> release. We depend on these pinned commits - if they don't exist the
> "released" builds can no longer
On Mon, Jul 11, 2011 at 01:05:20PM -0700, Santosh Shilimkar wrote:
> (Just to add few more points on top of what Colin already commented)
>
> On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
>> On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
>>> Well, short answer is no. On
On 7/11/2011 12:19 PM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 11:51:00AM -0700, Colin Cross wrote:
On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
Well, short answer is no. On SMP we do need
(Just to add few more points on top of what Colin already commented)
On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
Well, short answer is no. On SMP we do need to save CPU registers
but if just one single cpu is shutdown
On Mon, Jul 11, 2011 at 12:19 PM, Russell King - ARM Linux
wrote:
> On Mon, Jul 11, 2011 at 11:51:00AM -0700, Colin Cross wrote:
>> On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
>> >> Well, short answer
On Mon, Jul 11, 2011 at 11:51:00AM -0700, Colin Cross wrote:
> On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
> wrote:
> > On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> >> Well, short answer is no. On SMP we do need to save CPU registers
> >> but if just one sing
On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
wrote:
> On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
>> Well, short answer is no. On SMP we do need to save CPU registers
>> but if just one single cpu is shutdown L2 is still on.
>> cpu_suspend saves regs on the sta
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> Well, short answer is no. On SMP we do need to save CPU registers
> but if just one single cpu is shutdown L2 is still on.
> cpu_suspend saves regs on the stack that has to be cleaned from
> L2 before shutting a CPU down which m
On Mon, Jul 11, 2011 at 05:57:29PM +0100, Frank Hofmann wrote:
> On Mon, 11 Jul 2011, Lorenzo Pieralisi wrote:
>
> [ ... ]
> >>> The array of pointers is there to save pgdir on idle entry, one per-cpu.
> >>
> >> If you're going through cpu_{do_}suspend/resume, the TTBRs are
> >> saved/restored any
On Mon, 2011-07-11 at 09:11 -0500, Zach Pfeffer wrote:
> In-order to make reproducible builds we create pinned manifests with
> each commit explicitly listed. We also use this method to create a
> release. We depend on these pinned commits - if they don't exist the
> "released" builds can no longer
On Mon, 11 Jul 2011, Lorenzo Pieralisi wrote:
[ ... ]
The array of pointers is there to save pgdir on idle entry, one per-cpu.
If you're going through cpu_{do_}suspend/resume, the TTBRs are
saved/restored anyway, what do you need to keep the virtual addresses
around for ?
Because I switch m
Hi All,
I put some timestamp code into the compress and decompress testcases
that I had posted about last friday for libjpeg-turbo. I have new and
much better performance numbers as a result. In addition, I've put
together a simple wiki page to capture various libjpeg-turbo kinds of
things.
https
On Mon, Jul 11, 2011 at 03:31:30PM +0100, Frank Hofmann wrote:
>
>
> On Mon, 11 Jul 2011, Lorenzo Pieralisi wrote:
>
> > On Fri, Jul 08, 2011 at 05:12:22PM +0100, Frank Hofmann wrote:
> >> Hi Lorenzo,
> >>
> >> only a few comments at this stage.
> >>
[...]
> >> How much memory do all the paged
On Sat, Jul 09, 2011 at 09:45:08AM +0100, Russell King - ARM Linux wrote:
> On Sat, Jul 09, 2011 at 09:38:15AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 07, 2011 at 04:50:18PM +0100, Lorenzo Pieralisi wrote:
> > > +static int late_init(void)
> > > +{
> > > + int rc;
> > > + struct sr_c
(If you reply, reply to this one, not the previous message I sent, this one
fixes the linaro-dev email address)
On Mon, Jul 11, 2011 at 4:35 AM, Zygmunt Krynicki <
zygmunt.kryni...@linaro.org> wrote:
> In short: ~zygaN is the thing we can increment. We should KEEP and perhaps
> change the name to
On Mon, 11 Jul 2011, Lorenzo Pieralisi wrote:
On Fri, Jul 08, 2011 at 05:12:22PM +0100, Frank Hofmann wrote:
Hi Lorenzo,
only a few comments at this stage.
The sr_entry.S code is both exclusively .arm (using conditionals and
long-distance adr, i.e. not Thumb2-clean), and it uses post-armv5
In-order to make reproducible builds we create pinned manifests with
each commit explicitly listed. We also use this method to create a
release. We depend on these pinned commits - if they don't exist the
"released" builds can no longer be reproduced.
-Zach
___
On Fri, Jul 08, 2011 at 05:12:22PM +0100, Frank Hofmann wrote:
> Hi Lorenzo,
>
> only a few comments at this stage.
>
> The sr_entry.S code is both exclusively .arm (using conditionals and
> long-distance adr, i.e. not Thumb2-clean), and it uses post-armv5
> instructions (like wfi). Same for the
On Mon, Jul 11, 2011 at 12:27:46PM +0530, Ashish Jangam wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Tuesday, July 05, 2011 8:25 PM
> Can anyone ack this patch?
You've only left it about a week for a response. You cannot demand any
particular res
On 11 July 2011 12:30, Dave Martin wrote:
> On Mon, Jul 11, 2011 at 10:42:27AM +0100, Richard Sandiford wrote:
>> Dave Martin writes:
>> > IFUNC doesn't solve the problem because either it gets resolved
>> > lazily (violating the above principle (*)), or we have to force _all_
>> > symbols to res
On Sat, Jul 09, 2011 at 11:01:23AM +0100, Russell King - ARM Linux wrote:
> The idea of splitting a large patch up into smaller patches is to do
> it in a logical way so that:
>
> 1. Each patch is self-contained, adding a single new - and where possible
>complete - feature or bug fix.
> 2. Eas
On Mon, Jul 11, 2011 at 10:42:27AM +0100, Richard Sandiford wrote:
> Dave Martin writes:
> > IFUNC doesn't solve the problem because either it gets resolved
> > lazily (violating the above principle (*)), or we have to force _all_
> > symbols to resolve at startup, with may have a significant impa
On Mon, Jul 11, 2011 at 10:42:27AM +0100, Richard Sandiford wrote:
> Dave Martin writes:
> > IFUNC doesn't solve the problem because either it gets resolved
> > lazily (violating the above principle (*)), or we have to force _all_
> > symbols to resolve at startup, with may have a significant impa
Dave Martin writes:
> IFUNC doesn't solve the problem because either it gets resolved
> lazily (violating the above principle (*)), or we have to force _all_
> symbols to resolve at startup, with may have a significant impact on
> startup time for large programs.
IFUNCs are never resolved lazily;
Forwarding at it got bounced (odd?)
-- Wiadomość oryginalna --
Temat: Re: ppas, version numbers, releases and validation.linaro.org
Data: Mon, 11 Jul 2011 11:35:46 +0200
Nadawca: Zygmunt Krynicki
Firma/Organizacja: Linaro
Adresat: Michael Hudson-Doyle
Kopia: linaro-...@linaro.org, paul.
On 11 July 2011 09:42, David Gilbert wrote:
> On 11 July 2011 09:36, Dave Martin wrote:
>> On Sat, Jul 09, 2011 at 12:29:01AM +0100, Peter Maydell wrote:
>>> QEMU supports calls into the fixed vector page (it just special cases
>>> attempts to execute at addresses >= 0x and emits code to
On 11 July 2011 09:36, Dave Martin wrote:
> On Sat, Jul 09, 2011 at 12:29:01AM +0100, Peter Maydell wrote:
>> On 8 July 2011 19:32, Nicolas Pitre wrote:
>> > On Fri, 8 Jul 2011, Dave Martin wrote:
>> >> On Fri, Jul 08, 2011 at 12:21:27AM +0100, David Gilbert wrote:
>> >> > Nicolas just added; Ric
On Sat, Jul 09, 2011 at 12:29:01AM +0100, Peter Maydell wrote:
> On 8 July 2011 19:32, Nicolas Pitre wrote:
> > On Fri, 8 Jul 2011, Dave Martin wrote:
> >> On Fri, Jul 08, 2011 at 12:21:27AM +0100, David Gilbert wrote:
> >> > Nicolas just added; Richard's argument is that if it was actually a
> >>
On Fri, Jul 08, 2011 at 11:36:30AM -0700, Richard Henderson wrote:
> On 07/08/2011 09:55 AM, Dave Martin wrote:
> > Talking to Will Deacon about this, it sounds like there may be little
> > appetite for VDSO-ifying the vectors page unless there's a real, concrete
> > benefit.
> >
> > Making the li
On Mon, Jul 11, 2011 at 10:05 AM, Michael Hudson-Doyle
wrote:
>
> Another question I have is around version numbers. Currently we're
> using version numbers like 0.2-0ubuntu0~zyga1. I don't really see why
> the "zyga" is in there :) I think simply dropping the zyga and using
> versions like 0.2-
Hi Paul & Zygmunt (& others),
I spent a while today fixing a couple of bugs in lava-tool and in the
packaging of lava-server, and was wondering what the process should be
for getting them into the ~linaro-validation ppa and onto v.l.o
(although there's no particular urgency in getting these precis
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, July 05, 2011 8:25 PM
> To: Ashish Jangam
> Cc: Mark Brown; sa...@openedhand.com; linux-ker...@vger.kernel.org; Dajun;
> linaro-dev@lists.linaro.org
> Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2
36 matches
Mail list logo
