Re: [PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Rafael J. Wysocki
On Wednesday, January 30, 2013 05:57:39 PM Fabio Baltieri wrote: > On Wed, Jan 30, 2013 at 10:21:03PM +0530, Viresh Kumar wrote: > > > I'm not sure about the name through, I like mentioning sw coordination in > > > it > > > because that's the comment in the declaration: > > > > > > cpumask

Re: [PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Fabio Baltieri
On Wed, Jan 30, 2013 at 10:21:03PM +0530, Viresh Kumar wrote: > > I'm not sure about the name through, I like mentioning sw coordination in it > > because that's the comment in the declaration: > > > > cpumask_var_t cpus; /* CPUs requiring sw coordination */ > > cpumask_

Re: [PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Viresh Kumar
On 30 January 2013 21:53, Fabio Baltieri wrote: > On Wed, Jan 30, 2013 at 08:32:38PM +0530, Viresh Kumar wrote: >> I believe this routine should be rather present in cpufreq core code, >> as their might >> be other users of it. Its really not related to dbs or governors. >> >> My ideas about the

Re: [PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Fabio Baltieri
Hi Viresh, On Wed, Jan 30, 2013 at 08:32:38PM +0530, Viresh Kumar wrote: > Hi Fabio, > > I know Rafael has asked you to send only the incremental patch, but i > am interested in reviewing whole series again, as i haven't reviewed > earlier stuff :) Sure, take your chance. [internal note] > I be

Re: [PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Viresh Kumar
Hi Fabio, I know Rafael has asked you to send only the incremental patch, but i am interested in reviewing whole series again, as i haven't reviewed earlier stuff :) I believe you are required to send patches to patc...@linaro.org too :) On 30 January 2013 18:30, Fabio Baltieri wrote: > From: R

[PATCH v7 1/4] cpufreq: handle SW coordinated CPUs

2013-01-30 Thread Fabio Baltieri
From: Rickard Andersson This patch fixes a bug that occurred when we had load on a secondary CPU and the primary CPU was sleeping. Only one sampling timer was spawned and it was spawned as a deferred timer on the primary CPU, so when a secondary CPU had a change in load this was not detected by t