On 13 June 2012 21:51, David Zinman wrote:
> Regretfully this summary is very late.
>
> The Linaro 12.05 delivery cycle was fast and furious with Connect Q2.12, end
> of
> quarter and delivery all occurring in the same week.
>
> During this 2012.05 Linaro Connect, much of the effort was focused on
On Wed, Jun 13, 2012 at 8:51 PM, David Zinman wrote:
> Regretfully this summary is very late.
>
> The Linaro 12.05 delivery cycle was fast and furious with Connect Q2.12, end
> of
> quarter and delivery all occurring in the same week.
>
> During this 2012.05 Linaro Connect, much of the effort was
On Wed, 2012-06-13 at 20:27 +0100, Andy Whitcroft wrote:
> Actually if it was a new line, it would have been reported, at least in
> theory:
>
> # check for memory barriers without a comment.
> if ($line =~
>
> /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|
On 06/13/2012 03:26 PM, Michael Hope wrote:
> On 14 June 2012 04:22, Rob Herring wrote:
>> On 06/10/2012 05:31 PM, Michael Hope wrote:
>>> There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux
>>> kernels before 3.2 which causes the kernel to halt straight after
>>> showing 'Uncompres
On 14 June 2012 04:22, Rob Herring wrote:
> On 06/10/2012 05:31 PM, Michael Hope wrote:
>> There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux
>> kernels before 3.2 which causes the kernel to halt straight after
>> showing 'Uncompressing Linux'. The question comes up every couple o
On Wed, 2012-06-13 at 20:27 +0100, Andy Whitcroft wrote:
> On Wed, Jun 13, 2012 at 02:52:49PM +0200, Peter Zijlstra wrote:
> > On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> > > }
> > > smp_wmb();
> > > }
> >
> > You know what.. we should make checkpatch report an er
On Wed, Jun 13, 2012 at 02:52:49PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> > }
> > smp_wmb();
> > }
>
> You know what.. we should make checkpatch report an error for memory
> barriers that don't have a comment.
>
> I know this
Regretfully this summary is very late.
The Linaro 12.05 delivery cycle was fast and furious with Connect Q2.12, end of
quarter and delivery all occurring in the same week.
During this 2012.05 Linaro Connect, much of the effort was focused on:
* ARM big.LITTLE implementation and testing
* Pe
On 06/10/2012 05:31 PM, Michael Hope wrote:
> There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux
> kernels before 3.2 which causes the kernel to halt straight after
> showing 'Uncompressing Linux'. The question comes up every couple of
> months so I've blogged about it:
> http://s
On Wed, 2012-06-13 at 16:54 +0200, Vincent Guittot wrote:
> On 13 June 2012 15:07, Peter Zijlstra wrote:
> > On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> >> +struct cpu_capacity cpu_capacity[NR_CPUS];
> >
> > I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
>
On 13 June 2012 15:07, Peter Zijlstra wrote:
> On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
>> +struct cpu_capacity cpu_capacity[NR_CPUS];
>
> I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
> reason to use a NR_CPUS array over a per-cpu variable?
At this stag
On Wed, 13 Jun 2012, Peter Zijlstra wrote:
> On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> > +#ifdef CONFIG_OF
>
> That must really be the worst CONFIG_ name ever..
Indeed! We must corner Grant to do a s/CONFIG_OF/CONFIG_DEVICE_TREE/
on the whole tree and send the patch to Linus.
On 13 June 2012 15:32, Peter Zijlstra wrote:
> On Wed, 2012-06-13 at 15:29 +0200, Vincent Guittot wrote:
>> In fact, there is 2 tracks, one for a power aware scheduler and one
>> for setting the capacity of each core of a big.LITTLE system. This
>> patch is for the latter and is not directly link
Release Dates and Deliveries
ToolchainJune 14
WG/LT'sJune 21
12.06 RC'sJune 25
12.06 ReleaseJune 28
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
___
li
On 13 June 2012 15:28, Peter Zijlstra wrote:
> On Wed, 2012-06-13 at 15:20 +0200, Vincent Guittot wrote:
>>
>> In v3.4, x86 hasn't got any specific declaration for
>> arch_scale_freq_power so it would now use the weak
>> arch_scale_freq_power which calls default_scale_freq_power. Isn't it
>> enoug
On Wed, 2012-06-13 at 15:29 +0200, Vincent Guittot wrote:
> In fact, there is 2 tracks, one for a power aware scheduler and one
> for setting the capacity of each core of a big.LITTLE system. This
> patch is for the latter and is not directly link to the power because
> the default/performance mode
On 13 June 2012 14:47, Peter Zijlstra wrote:
> On Wed, 2012-06-13 at 18:14 +0530, Amit Kucheria wrote:
>> Various discussions around power-aware scheduling have amplified the
>> need for the scheduler to have some knowledge of DVFS. This would then
>> require the scheduler to track 'cpu_power' ( =
On Wed, 2012-06-13 at 15:20 +0200, Vincent Guittot wrote:
>
> In v3.4, x86 hasn't got any specific declaration for
> arch_scale_freq_power so it would now use the weak
> arch_scale_freq_power which calls default_scale_freq_power. Isn't it
> enough ?
---
Subject: sched, x86: Remove broken power e
On 13 June 2012 14:50, Peter Zijlstra wrote:
> On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
>> Heteregeneous ARM platform uses arch_scale_freq_power function
>> to reflect the relative capacity of each core
>
> I think I've pointed out before that this breaks x86.. you need a patch
>
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system
>
Can you provide a little description in the form of a code comment near
update_cpu_power() as to wtf all that does? This O
On 06/13/2012 02:44 PM, Jean Pihet wrote:
> Hi Daniel,
>
> On Fri, Jun 8, 2012 at 11:34 PM, Daniel Lezcano
> wrote:
>> On 06/08/2012 07:33 PM, Deepthi Dharwar wrote:
>>> Hi Daniel,
>>
>> Hi Deepthi,
>>
>>> On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
>>>
We have the state index passed as pa
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> +#ifdef CONFIG_OF
That must really be the worst CONFIG_ name ever..
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wednesday 13 June 2012, Jassi Brar wrote:
>
> On 6 June 2012 12:41, Arnd Bergmann wrote:
> >
> > for i in 2 3 30 31 ; do
> >sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \
> >/dev/mmcblk0 --offset=$[24*1024*1024]
> > done
> >
> > The latest versio
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> +struct cpu_capacity cpu_capacity[NR_CPUS];
I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
reason to use a NR_CPUS array over a per-cpu variable?
___
linaro-dev mailing
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> + smp_wmb();
No cookies for Vince!
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> }
> smp_wmb();
> }
You know what.. we should make checkpatch report an error for memory
barriers that don't have a comment.
I know this isn't added by this patch, but every time I see something
like it I cry a little.
Hi Amit, Peter,
On Wed, Jun 13, 2012 at 2:47 PM, Peter Zijlstra wrote:
> On Wed, 2012-06-13 at 18:14 +0530, Amit Kucheria wrote:
>> Various discussions around power-aware scheduling have amplified the
>> need for the scheduler to have some knowledge of DVFS. This would then
>> require the schedul
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> Heteregeneous ARM platform uses arch_scale_freq_power function
> to reflect the relative capacity of each core
I think I've pointed out before that this breaks x86.. you need a patch
killing at that stuff before this.
> Signed-off-by: Vi
On Wed, 2012-06-13 at 18:14 +0530, Amit Kucheria wrote:
> Various discussions around power-aware scheduling have amplified the
> need for the scheduler to have some knowledge of DVFS. This would then
> require the scheduler to track 'cpu_power' ( = max power) and perhaps
> a new variable 'current_p
Hi Daniel,
On Fri, Jun 8, 2012 at 11:34 PM, Daniel Lezcano
wrote:
> On 06/08/2012 07:33 PM, Deepthi Dharwar wrote:
>> Hi Daniel,
>
> Hi Deepthi,
>
>> On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
>>
>>> We have the state index passed as parameter to the 'enter' function.
>>> Most of the drivers a
On Wed, Jun 13, 2012 at 3:14 PM, Vincent Guittot
wrote:
> On 13 June 2012 10:59, Jean Pihet wrote:
>> Vincent,
>>
>> On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
>> wrote:
>>> Use cpu compatibility field and clock-frequency field of DT to
>>> estimate the capacity of each core of the system
On 13 June 2012 10:59, Jean Pihet wrote:
> Vincent,
>
> On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
> wrote:
>> Use cpu compatibility field and clock-frequency field of DT to
>> estimate the capacity of each core of the system
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> arch/arm/kernel/
On 13 June 2012 10:50, Jean Pihet wrote:
> Hi Vincent,
>
> On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
> wrote:
>> Add infrastructure to be able to modify the cpu_power of each core
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> arch/arm/include/asm/topology.h | 2 ++
>> arch/arm/kernel
Vincent,
On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system
>
> Signed-off-by: Vincent Guittot
> ---
> arch/arm/kernel/topology.c | 122
> ++
Hi Vincent,
On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
wrote:
> Add infrastructure to be able to modify the cpu_power of each core
>
> Signed-off-by: Vincent Guittot
> ---
> arch/arm/include/asm/topology.h | 2 ++
> arch/arm/kernel/topology.c | 36 +++
On 6 June 2012 12:41, Arnd Bergmann wrote:
>
> for i in 2 3 30 31 ; do
> sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \
> /dev/mmcblk0 --offset=$[24*1024*1024]
> done
>
> The latest version of the code is at
> git://git.linaro.org/people/arnd/flashbenc
36 matches
Mail list logo
