Video here:
https://plus.google.com/u/0/104422661029399872488/posts/gKZxeTmEkMe
This is cool because it lets us easily integrate the system into LAVA.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.faceb
On Fri, Sep 14, 2012 at 12:41 AM, Tushar Behera
wrote:
> OHCI-HCD driver does not support multiple SoC drivers during the compile
> time. Hence the generic driver should be disabled in ubuntu.conf and related
> OHCI Soc drivers should be enabled in respective board config files.
>
> Signed-off-by:
Commit 542f90381422 ("dm: support non power of two target max_io_len")
renames struct dm_target:split_io variable to max_io_len.
Signed-off-by: Tushar Behera
---
ubuntu/dm-raid4-5/dm-raid4-5.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ubuntu/dm-raid4-5/dm-raid4-5.
Fixes following compilation warning.
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: initialization from
incompatible pointer type [enabled by default]
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: (near initialization for
‘raid_target.status’) [enabled by default]
Signed-off-by: Tushar Behera
OHCI-HCD driver does not support multiple SoC drivers during the compile
time. Hence the generic driver should be disabled in ubuntu.conf and related
OHCI Soc drivers should be enabled in respective board config files.
Signed-off-by: Tushar Behera
---
linaro/configs/ubuntu.conf |1 -
1 files
(Thanks for Cc'ing me.)
On Thu, Sep 13, 2012 at 02:37:38PM +, Arnd Bergmann wrote:
[...]
> > > If this is true, I don't understand what makes the 'supplied-to'
> > > properties you list in the device tree binding board specific. Are
> > > they not always done the same way? If so, you could jus
On 9/13/12, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote:
>> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
>
> Well, updating the load statistics on the cpu you're going to balance
> seems like a good end to me.. ;-) No point updating the local statis
+Nishanth Menon
Quoting Vincent Guittot (2012-09-12 21:13:33)
> synchronize_rcu blocks the caller of opp_enable/disbale
> for a complete grace period. This blocking duration prevents
> any intensive use of the functions. Replace synchronize_rcu
> by call_rcu which will call our function for freein
On 09/09/2012 11:40 AM, Ricardo Salveti wrote:
On Wed, Sep 5, 2012 at 7:55 AM, Andy Green wrote:
On 09/05/12 17:19, the mail apparently from Andy Green included:
On 09/04/12 12:13, the mail apparently from Ricardo Salveti included:
Hi -
1) Can we have linux stable point release content in
Russell,
sorry for not CC'ing you on the entire patch series in the past, I'll do
it in the next iteration of the series (that TBH is nearly identical to
this one apart from being 3.6-rc5 based).
Are you happy with it? Given that the changes are entirely contained
within arch/arm/xen and arch/arm/
On Thursday 13 September 2012, Rajanikanth HV wrote:
> On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> >
> > If this is true, I don't understand what makes the 'supplied-to'
> > properties you list in the device tree binding board specific. Are
> > they not always done the same way?
From: Rajagopal Venkat
Devfreq returns governor predicted frequency as current frequency
via sysfs interface. But device may not support all frequencies
that governor predicts. So add a callback in device profile to get
current freq from driver. Also add a new sysfs node to expose
governor predic
From: Rajagopal Venkat
Prepare devfreq core framework to support devices which
can idle. When device idleness is detected perhaps through
runtime-pm, need some mechanism to suspend devfreq load
monitoring and resume back when device is online. Present
code continues monitoring unless device is re
From: Rajagopal Venkat
Add devfreq suspend/resume apis for devfreq users. This patch
supports suspend and resume of devfreq load monitoring, required
for devices which can idle.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c | 26 ++
drive
From: Rajagopal Venkat
This patchset updates devfreq core to add support for devices
which can idle. When device idleness is detected perhaps
through runtime-pm, need some mechanism to suspend devfreq
load monitoring and resume when device is back online.
patch 1 introduce core design changes -
On 10 September 2012 14:43, 함명주 wrote:
>> Prepare devfreq core framework to support devices which
>> can idle. When device idleness is detected perhaps through
>> runtime-pm, need some mechanism to suspend devfreq load
>> monitoring and resume back when device is online. Present
>> code continues
On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:
> On Wednesday 12 September 2012, Rajanikanth HV wrote:
>> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
>>> On Tuesday 11 September 2012, Rajanikanth HV wrote:
>
>> Consider: USB charging:
>> ___
On Mon, Jul 09, 2012 at 11:27:04AM +0200, Vincent Guittot wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system and to update
> the cpu_power field accordingly.
> This patch enables to put more running tasks on big cores than
> on
On 13 September 2012 14:07, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote:
>> On 10 July 2012 15:42, Peter Zijlstra wrote:
>> > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
>> >>
>> >> May be the last one which enable ARCH_POWER should also go into
On Thu, 2012-09-13 at 10:19 +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote:
> > On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> > > On tickless system, one CPU runs load balance for all idle CPUs.
> > > The cpu_load of this CPU is updated before
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote:
> On 10 July 2012 15:42, Peter Zijlstra wrote:
> > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
> >>
> >> May be the last one which enable ARCH_POWER should also go into tip ?
> >>
> > OK, I can take it.
>
> Hi Peter,
>
> I c
On Thu, 13 Sep 2012, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we s
On Thu, 13 Sep 2012, Dave Martin wrote:
> Do you think it's feasible to standardise on some interoperable ABI for
> kvm and Xen? This sounds pretty optimistic, but I'm not aware of all
> the technicalities, or what possible third-party hypervisors are out
> there.
>
> If we could do it, it would
On Thu, 13 Sep 2012, Dave Martin wrote:
> On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any
This patch adds driver for S5K4ECGX sensor with embedded ISP SoC,
S5K4ECGX, which is a 5M CMOS Image sensor from Samsung
The driver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/bri
On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While
On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > On Tue, 28 Aug 2012, Rob Herring wrote:
> > > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > > While it is a PPC doc, we should reuse or extend what
Hi Francesco
On 12 September 2012 19:07, Francesco Lavra wrote:
> Hi Sangwook,
> two remarks from my review on September 9th haven't been addressed.
Thanks for the review.
I missed those, please let me correct them and send patch again.
Regards
Sangwook
> I believe those remarks are correct,
On 10 July 2012 15:42, Peter Zijlstra wrote:
> On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
>>
>> May be the last one which enable ARCH_POWER should also go into tip ?
>>
> OK, I can take it.
Hi Peter,
I can't find the patch that enable ARCH_POWER in the tip tree. Have
you take it i
On Thu, 2012-09-13 at 10:45 +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > > I think you need to present numbers showing benefit. Crawling all over
> > > a mostly idle (4096p?) box is decidedly bad thing to do.
>
> Yeah, but we're already doing that
On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > I think you need to present numbers showing benefit. Crawling all over
> > a mostly idle (4096p?) box is decidedly bad thing to do.
Yeah, but we're already doing that anyway.. we know nohz idle balance
doesn't scale. Venki and Suresh
Wrong button make me removed others guys from the thread.
Sorry for this mistake.
On 13 September 2012 09:56, Mike Galbraith wrote:
> On Thu, 2012-09-13 at 09:44 +0200, Vincent Guittot wrote:
>> On 13 September 2012 09:29, Mike Galbraith wrote:
>> > On Thu, 2012-09-13 at 08:59 +0200, Vincent Gu
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> On tickless system, one CPU runs load balance for all idle CPUs.
> The cpu_load of this CPU is updated before starting the load balance
> of each other idle CPUs. We should instead update the cpu_load of the
> balance_cpu.
>
> Signed-off
On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote:
> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> > On tickless system, one CPU runs load balance for all idle CPUs.
> > The cpu_load of this CPU is updated before starting the load balance
> > of each other idle CPUs. We should
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> On tickless system, one CPU runs load balance for all idle CPUs.
> The cpu_load of this CPU is updated before starting the load balance
> of each other idle CPUs. We should instead update the cpu_load of the
> balance_cpu.
>
> Signed-of
35 matches
Mail list logo
