Re: lava-dispatcher extensions

2011-07-22 Thread Paul Larson
On Fri, Jul 22, 2011 at 6:05 PM, David Schwarz wrote: > > Several of us at Calxeda have been working on extensions to > lava-dispatcher with an eye toward using it as a general test management > engine not just for individual platforms, but for whole clusters of > machines as well. We've broken

Re: lava-dispatcher extensions

2011-07-22 Thread Zygmunt Krynicki
On Sat, Jul 23, 2011 at 1:05 AM, David Schwarz wrote: > > Several of us at Calxeda have been working on extensions to > lava-dispatcher with an eye toward using it as a general test management > engine not just for individual platforms, but for whole clusters of > machines as well. We've broken

lava-dispatcher extensions

2011-07-22 Thread David Schwarz
Several of us at Calxeda have been working on extensions to lava-dispatcher with an eye toward using it as a general test management engine not just for individual platforms, but for whole clusters of machines as well. We've broken our extensions into three feature branches, which can be found

Linaro multimedia work group 11.11 public plan review

2011-07-22 Thread Kurt Taylor
The Linaro multimedia working group will be conducting a public plan review Monday, July 25th at 15:00 UTC. Join us to discuss our plan for 11.11 cycle, or there will also be a recording available following the review. Specifics and slides: https://wiki.linaro.org/Cycles//PublicPlanReview --

Re: Fw: Delivery Status Notification (Failure)

2011-07-22 Thread Loïc Minier
On Fri, Jul 22, 2011, Paul Sokolovsky wrote: > I started to get delivery failures like below when posting to > linaro-dev@ , while having other recipients in to: or cc: too. It seems > ok if I post/forward directly (and only) to linaro-dev@. Can you please > look into this? I've replied directly

Fw: Delivery Status Notification (Failure)

2011-07-22 Thread Paul Sokolovsky
Hello, I started to get delivery failures like below when posting to linaro-dev@ , while having other recipients in to: or cc: too. It seems ok if I post/forward directly (and only) to linaro-dev@. Can you please look into this? Thanks, Paul Begin forwarded message: Date: Fri, 22 Jul 2011 13

[Patch v2 04/11]Power: DA9052 battery driver

2011-07-22 Thread ashishj3
Driver for DA9052 battery charger. This driver depends on DA9052 MFD core dirver for definitions and methods. Signed-off-by: David Dajun Chen Signed-off-by: Ashish Jangam --- Changes since v2 - Correct code styling for inline functions - Remove averaging algorithm - Set use_for_apm thru board sp

Re: [PATCH] ARM: do not mark CPU 0 as hotpluggable

2011-07-22 Thread Santosh Shilimkar
On 7/22/2011 6:15 PM, Woodruff, Richard wrote: From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh With fixed IRQ migration and forcing CPU0 into an infinite WFI loop, I can offline CPU0 and still have a ru

RE: [PATCH] ARM: do not mark CPU 0 as hotpluggable

2011-07-22 Thread Woodruff, Richard
> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- > kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh > > With fixed IRQ migration and forcing CPU0 into an infinite WFI loop, > > I can offline CPU0 and still have a running system. > > > The secure software

Re: Break in gcc-linaro tarball naming conventions, was: Re: Bug 809768 integration into gcc 4.6 for Linaro Android 1107 release

2011-07-22 Thread Michael Hope
(On holiday so short) The tarball name has changed to match the new Linaro conventions. I forgot to put that in the announcement. The inner directory name should change as well but was missed, sorry. On Jul 21, 2011 6:59 PM, "Paul Sokolovsky" wrote: > Hello, > > Well, before proceeding further, t

Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

2011-07-22 Thread Mark Brown
On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote: > On Thursday 21 July 2011 16:47:48 Mark Brown wrote: > > Although the bigger problem is why are these interruptible? That's > > very unusual. > Well, the default should really be to use _interruptible or at least > _killable with th