On Tue, Jul 12, 2011 at 9:07 AM, Ricardo Salveti wrote:
> Is there other way to fix this at the tool instead of forcing the
> component tree owner to not rebase the tree?
>
if the problem is that you rely on external maintainers to 1) create a tag
or a ref that reaches the commits you depend on
Original at https://wiki.linaro.org/Platform/Android/Meetings/2011-07-13
=== Highlights ===
* Supported unaccelerated Snowball Android bringup and got the first
leb-snowball build going in https://android-build.linaro.org/
* Drove android-build to LAVA integration
* Onboarded Chao Yang, Tony Ma
On Tue, Jul 12, 2011 at 5:13 AM, John Rigby wrote:
> On Tue, Jul 12, 2011 at 1:07 AM, Ricardo Salveti
> wrote:
>> On Mon, Jul 11, 2011 at 6:18 PM, Alexander Sack wrote:
>>> On Mon, Jul 11, 2011 at 4:11 PM, Zach Pfeffer
>>> wrote:
In-order to make reproducible builds we create pinned manif
Key Points for wider discussion:
8 engineers are now on board and operative in the Android Platform Team.
LT/Android plugfests are all running and seem to be speeding up integration
We'd like all teams to ensure that what their doing is always included in
our daily Android builds in support of our
It is fragile, but I think its the only way to do it and still give
people the ability to create arbitrary builds easily, with 100%
fidelity using a method that's easy to automate and that generally
works. Since we need to use repo -r, we don't want to have people
using side gits if we can help it,
On Tue, 2011-07-12 at 04:07 -0300, Ricardo Salveti wrote:
> On Mon, Jul 11, 2011 at 6:18 PM, Alexander Sack wrote:
> > 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 us
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, July 13, 2011 12:03 AM
> 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
On Tue, Jul 12, 2011 at 10:44 AM, Zach Pfeffer wrote:
> > This one is complete, results can be easily found at the usual place
> based
> > on the
> > url:
> http://validation.linaro.org/launch-control/dashboard/reports/android-runs/
>
> This link is dead.
>
Well, you waited too long to check it :)
On Monday 11 July 2011 08:57:46 Ashish Jangam wrote:
> > -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.linar
All,
Just a quick reminder. If you're trying to get anything delivered into
an Android target for 11.07 you should have talked to me and we should
have an integration BP tracking it. You should also be testing your
stuff against the Android target you want to deliver on. Simply
getting source into
On 4 July 2011 12:29, Paul Larson wrote:
>
> On Sun, Jul 3, 2011 at 9:13 PM, Zach Pfeffer
> wrote:
>>
>> Yeah. Those results seem rational. Would you test:
>>
>>
>> https://android-build.linaro.org/builds/~linaro-android/panda-11.06-release/#build=3
>
> This one is currently running
Where are th
From: Vincent Guittot
(Patch accepted by Russell for 3.1:
http://www.spinics.net/lists/arm-kernel/msg131273.html)
The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency. We ca
From: Amit Kucheria
(Please bear with pull-request for a single patch, but we're creating a
consolidation tree through which we will offer various topic branches for
merge into the Linaro kernel in the future)
The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:
Linux
Hello,
Here at Linaro, we pull components for Android builds from various
sources, like AOSP upstream, our forks of AOSP components (to
fix compatibility issues with gcc 4.5/4.6, etc.), bootloaders and
kernels from SoC support teams, etc. All in all, that means that we
don't have full control over
On Tue, Jul 12, 2011 at 02:25:09PM +0100, Richard Sandiford wrote:
> Sorry, should have included this in my last reply.
>
> Dave Martin writes:
> >> Also, remember this whole discussion is just to print a message and exit
> >> nicely
> >> in the case of someone using a currently incredibly rare
Sorry, should have included this in my last reply.
Dave Martin writes:
>> Also, remember this whole discussion is just to print a message and exit
>> nicely
>> in the case of someone using a currently incredibly rare function on an old
>> kernel!
>
> I'd say we want to notify the operating envir
On 12 July 2011 13:40, Dave Martin wrote:
> On Tue, Jul 12, 2011 at 01:10:24PM +0100, David Gilbert wrote:
>> Does it help address rth's concerns though?
>
> Which ones in particular?
Good question - hence my prompt to rth at the bottom; I know he originally
asked why not go to VDSO, so what I d
Dave Martin writes:
>> To be honest I don't see the point in the more general indirected
>> approach; if we
>> want to be more general then I think we should use IFUNC (it would be the 1st
>> use of it, which means we may have to fix some issues but hey that's what
>> we're
>> here for).
>
> Does
On Tue, Jul 12, 2011 at 01:10:24PM +0100, David Gilbert wrote:
> On 12 July 2011 11:43, Dave Martin wrote:
>
> > Just for context, I had a quick play to get a feel for the feasibility of
> > implementing this directly, without relying either on a VDSO or on IFUNC.
>
> I originally thought about
On 12 July 2011 11:43, Dave Martin wrote:
> Just for context, I had a quick play to get a feel for the feasibility of
> implementing this directly, without relying either on a VDSO or on IFUNC.
I originally thought about doing something similar to what you've done
with the indirection; but event
On 12 July 2011 02:22, J Freyensee wrote:
> On 07/10/2011 12:21 PM, Per Forlin wrote:
>> +MMC host extensions
>> +===
>> +
>> +There are two optional members in the
>> +mmc_host_ops -- pre_req() and post_req() -- that the host
>> +driver may implement in order to move work to befor
On Mon, Jul 11, 2011 at 01:00:08PM +0100, David Gilbert wrote:
> 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 (violatin
On Tue, Jul 12, 2011 at 11:12:57AM +0100, Lorenzo Pieralisi wrote:
> Thank you very much Russell for this recap.
>
> On Mon, Jul 11, 2011 at 07:40:10PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> > > Well, short answer is no. On S
Thank you very much Russell for this recap.
On Mon, Jul 11, 2011 at 07:40:10PM +0100, 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 shutdo
Dear Chander Kashyap ,
On 27 June 2011 17:37, Chander Kashyap wrote:
> Adds mmc boot support.
>
> Signed-off-by: Chander Kashyap
> ---
> mmc_spl/board/samsung/origen/Makefile | 105
> mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++
> mmc_spl/b
On 07/10/2011 12:21 PM, Per Forlin wrote:
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
Acked-by: Randy Dunlap
---
ChangeLog:
v2: - Minor updates after proofreading comments from
Adds mmc boot support.
Signed-off-by: Chander Kashyap
---
Changes in v2:
Use sys/stat.h for file permission macros in tools/mkv310_image.c
mmc_spl/board/samsung/origen/Makefile | 105 +++
mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++
mmc
Origen board is based upon S5PV310 SoC which is similiar to
S5PC210 SoC.
Signed-off-by: Chander Kashyap
---
MAINTAINERS |1 +
board/samsung/origen/Makefile| 46
board/samsung/origen/lowlevel_init.S | 468 ++
board/samsu
Adds support for ORIGEN board with MMC Booting.
Chander Kashyap (2):
ARMV7: Add support for Samsung ORIGEN board
ORIGEN: Add MMC SPL support
MAINTAINERS |1 +
board/samsung/origen/Makefile | 46 ++
board/samsung/origen/lowlevel_
On Tue, Jul 12, 2011 at 1:07 AM, Ricardo Salveti
wrote:
> On Mon, Jul 11, 2011 at 6:18 PM, Alexander Sack wrote:
>> 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 thi
On 12 July 2011 11:37, Minkyu Kang wrote:
> Dear Chander Kashyap ,
>
> On 27 June 2011 17:37, Chander Kashyap wrote:
>> Adds mmc boot support.
>>
>> Signed-off-by: Chander Kashyap
>> ---
>> mmc_spl/board/samsung/origen/Makefile | 105
>> mmc_spl/board/samsung/orige
On Mon, Jul 11, 2011 at 6:18 PM, Alexander Sack wrote:
> 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
32 matches
Mail list logo
