With the recent changes in cpufreq core, we just need to set mask of all
possible cpus into policy->cpus. Rest would be done by core.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/exynos-cpufreq.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/cpufre
Documentation related to cpus and related_cpus is confusing and not very clear.
Over that CPUFreq core has seen much changes recently. Lets update documentation
and comments for cpus and related_cpus.
Signed-off-by: Viresh Kumar
---
Documentation/cpu-freq/cpu-drivers.txt | 6 ++
Documentatio
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
On 30 January 2013 22:23, Fabio Baltieri wrote:
> On Wed, Jan 30, 2013 at 09:23:22PM +0530, Viresh Kumar wrote:
> Can't argue with this, but the two had some subdle differences (namely
> th two dbs_info structures) and I opted to not mess up forcing some
> non-obvious common code.
>
> Feel free t
On 30 January 2013 22:16, Fabio Baltieri wrote:
> Isn't that how it works now? The current cpu ktime is not checked
> against its own, but against the "leader" cpu (dbs_info_local->cdbs.cpu),
> that's why it's initialized only for the first.
>
> Maybe I should have used dbs_info_leader/dbs_info i
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_
On Wed, Jan 30, 2013 at 09:23:22PM +0530, Viresh Kumar wrote:
> On 30 January 2013 18:30, Fabio Baltieri wrote:
> > Modify conservative timer to not resample CPU utilization if recently
> > sampled from another SW coordinated core.
> >
> > Signed-off-by: Fabio Baltieri
>
> We are again doing the
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
On Wed, Jan 30, 2013 at 09:21:41PM +0530, Viresh Kumar wrote:
> On 30 January 2013 18:30, Fabio Baltieri wrote:
> > Modify ondemand timer to not resample CPU utilization if recently
> > sampled from another SW coordinated core.
> >
> > Signed-off-by: Fabio Baltieri
>
> I might be wrong but i hav
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
On 30 January 2013 18:30, Fabio Baltieri wrote:
> Modify conservative timer to not resample CPU utilization if recently
> sampled from another SW coordinated core.
>
> Signed-off-by: Fabio Baltieri
We are again doing the same mistake which i fixed with:
commit 4471a34f9a1f2da220272e823bdb8e8fa8
On 30 January 2013 18:30, Fabio Baltieri wrote:
> Modify ondemand timer to not resample CPU utilization if recently
> sampled from another SW coordinated core.
>
> Signed-off-by: Fabio Baltieri
I might be wrong but i have some real concerns over this patch.
This is what i believe is your idea:
Hi Hongbo,
On Wed, Jan 30, 2013 at 06:21:27PM +0800, Hongbo Zhang wrote:
> We are using a generic abx500 hwmon layer, so rename specific ab8500 to
> generic
> abx500 for hwmon device and driver matching.
>
> Signed-off-by: Hongbo Zhang
> ---
> drivers/mfd/ab8500-core.c | 6 +++---
> 1 file cha
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
Drop unused arguments from dbs_timer_init and clean dbs_timer_exit and
cpufreq_governor_dbs to remove non necessary special cases.
Reported-by: Viresh Kumar
Signed-off-by: Fabio Baltieri
---
Hello Rafael,
that's the cleanup on top of "cpufreq: handle SW coordinated CPUs".
Thanks,
Fabio
driv
On Wednesday, January 30, 2013 11:44:32 AM Fabio Baltieri wrote:
> Hi Viresh,
>
> On Wed, Jan 30, 2013 at 10:22:37AM +0530, Viresh Kumar wrote:
> > Hi Fabio,
> >
> > Sorry for waking up very late :)
> >
> > The reason why i am starting this thread again is due to problem
> > reported by Joseph,
Hello Rafael,
this is the v7 for the cpufreq SW coordinated CPU bug fix, developed
after the discussion with Viresh about some issues that appeared after
the merge of both mine and his patches.
Changes from v6:
* Dropped the cpu hotplug patch, as it was solving part of problem
addressed by Vires
Modify ondemand timer to not resample CPU utilization if recently
sampled from another SW coordinated core.
Signed-off-by: Fabio Baltieri
---
drivers/cpufreq/cpufreq_governor.c | 3 ++
drivers/cpufreq/cpufreq_governor.h | 1 +
drivers/cpufreq/cpufreq_ondemand.c | 58 +++
Modify conservative timer to not resample CPU utilization if recently
sampled from another SW coordinated core.
Signed-off-by: Fabio Baltieri
---
drivers/cpufreq/cpufreq_conservative.c | 47 +-
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers
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
Modify update_sampling_rate() to check, and eventually immediately
schedule, all CPU's do_dbs_timer delayed work.
This is required in case of software coordinated CPUs, as we now have a
separate delayed work for each CPU.
Signed-off-by: Fabio Baltieri
---
drivers/cpufreq/cpufreq_ondemand.c | 5
On Wed, Jan 30, 2013 at 04:47:58PM +0530, Viresh Kumar wrote:
> On 30 January 2013 16:34, Fabio Baltieri wrote:
> > Small sidenote, actually what I'm going to drop here i *cdbs, as I need
> > cpu for schedule_delayed_work_on and can't use cdbs->cpu for that as
> > it's the master's one.
>
> I can
On 30 January 2013 16:34, Fabio Baltieri wrote:
> Small sidenote, actually what I'm going to drop here i *cdbs, as I need
> cpu for schedule_delayed_work_on and can't use cdbs->cpu for that as
> it's the master's one.
I can't find code which would do j_cdbs->cpu = j and so j_cdbs->cpu is
un-initi
On Wed, Jan 30, 2013 at 10:14:53AM +0100, Fabio Baltieri wrote:
> Hello Viresh,
>
> On Wed, Jan 30, 2013 at 12:33:40PM +0530, Viresh Kumar wrote:
> > I am starting to follow cpufreq patches religiously now and so have to come
> > back to this old thread due to some crash we got :)
> >
> > Its sti
Hi Viresh,
On Wed, Jan 30, 2013 at 10:22:37AM +0530, Viresh Kumar wrote:
> Hi Fabio,
>
> Sorry for waking up very late :)
>
> The reason why i am starting this thread again is due to problem
> reported by Joseph,
> with latest linux-next/master branch (which contains few big patches
> from me :)
Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the
We are using a generic abx500 hwmon layer, so rename specific ab8500 to generic
abx500 for hwmon device and driver matching.
Signed-off-by: Hongbo Zhang
---
drivers/mfd/ab8500-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd
These patches are against the v3.8-rc4.
Guenter Roeck, Jean Delvare,
Please help to have a look at this.
Samuel Ortiz,
Please review 1/2 and leave your Acked-by: if no problem, I think these patches
should be merged into HWMON tree.
Thanks for all.
Hongbo Zhang (2):
ARM: ux500: rename ab8500
On 30 January 2013 17:45, Linus Walleij wrote:
> On Wed, Jan 30, 2013 at 8:42 AM, Hongbo Zhang wrote:
>
>> We are using a generic abx500 hwmon layer, so rename specific ab8500 to
>> generic
>> abx500 for hwmon device and driver matching.
>>
>> Signed-off-by: Hongbo Zhang
>
> You need to have th
On Wed, Jan 30, 2013 at 10:21 AM, Hongbo Zhang wrote:
> EXT4 file system and LBDAF are used commonly, should be enabled by default.
>
> Signed-off-by: Hongbo Zhang
Thanks!
Applied to my defconfig branch.
Yours,
Linus Walleij
___
linaro-dev mailing
On Wed, Jan 30, 2013 at 8:42 AM, Hongbo Zhang wrote:
> We are using a generic abx500 hwmon layer, so rename specific ab8500 to
> generic
> abx500 for hwmon device and driver matching.
>
> Signed-off-by: Hongbo Zhang
You need to have the ACK:ed by the MFD subsystem maintainer
so that Günther ca
Hi Vincent,
Thanks for a very fast response.
> On 30 January 2013 09:35, Lukasz Majewski
> wrote:
> > Dear All,
> >
> >
> > I'd like to ask about the power aware scheduler development:
> >
> > https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
> > scheduler
> >
> >
> >
> > W
EXT4 file system and LBDAF are used commonly, should be enabled by default.
Signed-off-by: Hongbo Zhang
---
arch/arm/configs/u8500_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 231dca6..746c
Hello Viresh,
On Wed, Jan 30, 2013 at 12:33:40PM +0530, Viresh Kumar wrote:
> I am starting to follow cpufreq patches religiously now and so have to come
> back to this old thread due to some crash we got :)
>
> Its still not pushed upstream, so better to get it resolved before 3.9.
Definitely,
On 30 January 2013 09:35, Lukasz Majewski wrote:
> Dear All,
>
>
> I'd like to ask about the power aware scheduler development:
>
> https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
> scheduler
>
>
>
> Why I'm interested?
>
>
>
> I'd like to test and further develop methods t
On 30 January 2013 14:19, Alex Shi wrote:
> On 01/30/2013 04:35 PM, Lukasz Majewski wrote:
>> Dear All,
>>
>>
>> I'd like to ask about the power aware scheduler development:
>>
>> https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
>> scheduler
>>
>
> The latest code released i
On 01/30/2013 04:35 PM, Lukasz Majewski wrote:
> Dear All,
>
>
> I'd like to ask about the power aware scheduler development:
>
> https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
> scheduler
>
The latest code released in LKML:
https://lkml.org/lkml/2013/1/23/620
Commen
On 30 January 2013 14:05, Lukasz Majewski wrote:
> I'd like to ask about the power aware scheduler development:
>
> https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
> scheduler
It is present as pack small task in MP tree.
> Why I'm interested?
>
>
>
> I'd like to test and
Dear All,
I'd like to ask about the power aware scheduler development:
https://blueprints.launchpad.net/linaro-power-kernel/+spec/power-aware-
scheduler
Why I'm interested?
I'd like to test and further develop methods to put CPU to IDLE or
changing its operating frequency. I'm especiall
39 matches
Mail list logo
