Implement a generic helper function policy_is_shared() to replace the
current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be
used by code other than cpufreq governors.
Suggested-by: Viresh Kumar
Signed-off-by: Fabio Baltieri
---
drivers/cpufreq/cpufreq_conservative.c | 2 +-
driv
On 31 January 2013 13:44, Fabio Baltieri wrote:
> Implement a generic helper function policy_is_shared() to replace the
> current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be
> used by code other than cpufreq governors.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Fabio Baltie
Hello Viresh,
On Wed, Jan 30, 2013 at 10:41:08PM +0530, Viresh Kumar wrote:
> 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 in
On 31 January 2013 14:09, Fabio Baltieri wrote:
> Ok, now I see the problem: cdbs->cpu is initialized only on the leader
> cpu and this is working by coincidence on my system, while
> cdbs->time_stamp is initialized only on the leader cpu, and that should
> be correct even when cpu hotplugging as
On Thu, Jan 31, 2013 at 02:01:27PM +0530, Viresh Kumar wrote:
> On 31 January 2013 13:44, Fabio Baltieri wrote:
> > Implement a generic helper function policy_is_shared() to replace the
> > current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be
> > used by code other than cpufreq go
On Thu, Jan 31, 2013 at 2:25 PM, Fabio Baltieri
wrote:
> On Thu, Jan 31, 2013 at 02:01:27PM +0530, Viresh Kumar wrote:
>> On 31 January 2013 13:44, Fabio Baltieri wrote:
>> > Implement a generic helper function policy_is_shared() to replace the
>> > current dbs_sw_coordinated_cpus() at cpufreq le
On Thu, Jan 31, 2013 at 02:12:29PM +0530, Viresh Kumar wrote:
> On 31 January 2013 14:09, Fabio Baltieri wrote:
> > Ok, now I see the problem: cdbs->cpu is initialized only on the leader
> > cpu and this is working by coincidence on my system, while
> > cdbs->time_stamp is initialized only on the
Hi Botao,
On 31 January 2013 10:58, Botao Sun wrote:
> Linaro 13.01 Release (Calendar Week 5, 2013): Here is test result summary
> for Linux Linaro ubuntu Quantal image on following boards:
>
> 1) ARM Versatile Express A9;
> 2) Samsung Origen;
> 3) Samsung Arndale;
> 4) TI Panda 4430;
> 5) TI Pan
On 31 January 2013 14:36, Fabio Baltieri wrote:
> Current code uses ->cpu to track policy->cpu and get the timestamp, I
> can modify it to point to the current cpu and use it in timer_init *and*
> add a new field just to track leader_cpu but I don't see the benefits.
> Am I missing something?
Cur
Hi Fathi,
This report is just for the release images, not for the latest ones. For TI
Panda board, it means the test result is for build 58. I will test the DS5
in our next weekly test cycle for new Panda images.
For STE Snowball, the release image is build 58, which contains kernel
3.8.0-1, and
Implement a generic helper function policy_is_shared() to replace the
current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be
used by code other than cpufreq governors.
Suggested-by: Viresh Kumar
Signed-off-by: Fabio Baltieri
---
Changes from v1:
- replaced cpumask_weight in acpi-
On 31 January 2013 15:14, Fabio Baltieri wrote:
> Implement a generic helper function policy_is_shared() to replace the
> current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be
> used by code other than cpufreq governors.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Fabio Baltie
Fix governors code to set all cpu's cdbs->cpu to the the actual cpu id
and use cur_policy->cpu istead of cdbs->cpu to track current governor's
leader cpu.
Reported-by: Viresh Kumar
Signed-off-by: Fabio Baltieri
---
drivers/cpufreq/cpufreq_conservative.c | 5 +++--
drivers/cpufreq/cpufreq_govern
On 31 January 2013 16:09, Fabio Baltieri wrote:
> Fix governors code to set all cpu's cdbs->cpu to the the actual cpu id
> and use cur_policy->cpu istead of cdbs->cpu to track current governor's
> leader cpu.
>
> Reported-by: Viresh Kumar
> Signed-off-by: Fabio Baltieri
> ---
> drivers/cpufreq/
On 30 January 2013 19:23, Fabio Baltieri wrote:
> 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
As discussed over IRC, you will fix following in f
On Thu, Jan 31, 2013 at 04:23:06PM +0530, Viresh Kumar wrote:
> On 30 January 2013 19:23, Fabio Baltieri wrote:
> > 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-o
On 30 January 2013 23:45, Samuel Ortiz wrote:
> 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
>>
On Thursday, January 31, 2013 12:06:13 PM Fabio Baltieri wrote:
> On Thu, Jan 31, 2013 at 04:23:06PM +0530, Viresh Kumar wrote:
> > On 30 January 2013 19:23, Fabio Baltieri wrote:
> > > Drop unused arguments from dbs_timer_init and clean dbs_timer_exit and
> > > cpufreq_governor_dbs to remove non
With the inclusion of following patches:
9f4eb10 cpufreq: conservative: call dbs_check_cpu only when necessary
772b4b1 cpufreq: ondemand: call dbs_check_cpu only when necessary
code redundancy is introduced again. Get rid of it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_conservat
CPUFREQ_GOV_START/STOP are called only once for all policy->cpus and hence we
don't need to adapt cpufreq_governor_dbs() routine for multiple calls.
So, this patch removes dbs_data->enable field entirely. And rearrange code a
bit.
Signed-off-by: Viresh Kumar
---
Hi Fabio,
I have fixed all the p
On 31 January 2013 22:58, Viresh Kumar wrote:
> CPUFREQ_GOV_START/STOP are called only once for all policy->cpus and hence we
> don't need to adapt cpufreq_governor_dbs() routine for multiple calls.
>
> So, this patch removes dbs_data->enable field entirely. And rearrange code a
> bit.
>
> Signed-
On Thu, Jan 31, 2013 at 10:58:01PM +0530, Viresh Kumar wrote:
> CPUFREQ_GOV_START/STOP are called only once for all policy->cpus and hence we
> don't need to adapt cpufreq_governor_dbs() routine for multiple calls.
>
> So, this patch removes dbs_data->enable field entirely. And rearrange code a
>
On Thu, Jan 31, 2013 at 10:58:02PM +0530, Viresh Kumar wrote:
> With the inclusion of following patches:
>
> 9f4eb10 cpufreq: conservative: call dbs_check_cpu only when necessary
> 772b4b1 cpufreq: ondemand: call dbs_check_cpu only when necessary
>
> code redundancy is introduced again. Get rid o
Hi,
Calendar Week 5, 2013: Here is test result summary for big.LITTLE MP
Scheduler test on TC2 platform with Android image
sched_tests.git No of Test Cases Tests Run Tests Pass Tests Fail Absolute
pass rate (%) Failure Analysis/Comments
Regression 20 20 20 0 100 -
mpbasicsuite 14 14 14
On Thursday, January 31, 2013 07:50:04 PM Fabio Baltieri wrote:
> On Thu, Jan 31, 2013 at 10:58:02PM +0530, Viresh Kumar wrote:
> > With the inclusion of following patches:
> >
> > 9f4eb10 cpufreq: conservative: call dbs_check_cpu only when necessary
> > 772b4b1 cpufreq: ondemand: call dbs_check_c
Hello Rafael,
On Thu, Jan 31, 2013 at 11:23:54PM +0100, Rafael J. Wysocki wrote:
> On Thursday, January 31, 2013 07:50:04 PM Fabio Baltieri wrote:
> > On Thu, Jan 31, 2013 at 10:58:02PM +0530, Viresh Kumar wrote:
> > > With the inclusion of following patches:
> > >
> > > 9f4eb10 cpufreq: conserva
On 1 February 2013 04:21, Fabio Baltieri wrote:
> On Thu, Jan 31, 2013 at 11:23:54PM +0100, Rafael J. Wysocki wrote:
>> This time I was *really* confused as to what patches I was supposed to take,
>> from whom and in what order, so I applied a number of them in the order given
>> by patchwork. Th
On 1 February 2013 08:01, Viresh Kumar wrote:
> Really!! I see bleeding edge as df0e3f4 and i don't see the $(subject) patch
> in it :)
Well it might have been dropped by Rafael due to build error, which would
be fixed by:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq
On 1 February 2013 00:14, Fabio Baltieri wrote:
> Hello Viresh, thanks for getting this done... looks much cleaner now!
>
> I tested both patches on my ux500 setup (dual Cortex-A9) and it seems to
> run correctly on both CPU load changes and CPU hotplug, so:
>
> Tested-by: Fabio Baltieri
Thanks.
On 31 January 2013 18:36, Rafael J. Wysocki wrote:
> On Thursday, January 31, 2013 12:06:13 PM Fabio Baltieri wrote:
>> On Thu, Jan 31, 2013 at 04:23:06PM +0530, Viresh Kumar wrote:
>> > As discussed over IRC, you will fix following in few days:
>> > - Code redundancy within governors
>> > - Remo
Currently, whenever governor->governor() is called for CPUFRREQ_GOV_START event
we reset few tunables of governor. Which isn't correct, as this routine is
called for every cpu hot-[un]plugging event. We should actually be resetting
these only when the governor module is removed and re-installed.
S
On 1 February 2013 11:12, Viresh Kumar wrote:
> Currently, whenever governor->governor() is called for CPUFRREQ_GOV_START
> event
> we reset few tunables of governor. Which isn't correct, as this routine is
> called for every cpu hot-[un]plugging event. We should actually be resetting
> these onl
Guenter,
Thank you so much for all the comments, will re-send a v2 iteration soon.
On 31 January 2013 02:37, Guenter Roeck wrote:
> On Wed, Jan 30, 2013 at 06:21:28PM +0800, Hongbo Zhang wrote:
>> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
>> chips. This is ABX500
With following patch, we need to set policy->cpus with mask of all possible cpus
and policy->related_cpus would be filled automatically by the core.
commit 4948b355e90080cd5ec1e91189f65a01e4186ef2
Author: Viresh Kumar
Date: Tue Jan 29 14:39:08 2013 +
cpufreq: Simplify cpufreq_add_dev()
Le
policy->shared_type field was added only for SoCs with ACPI support:
commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
Author: Venkatesh Pallipadi
Date: Wed Dec 14 15:05:00 2005 -0500
P-state software coordination for ACPI core
http://bugzilla.kernel.org/show_bug.cgi?id=5737
Many non-A
For multicore SoC's, with cores sharing clock line, we are required to set
policy->cpus and policy->related_cpus with mask of cpus.
With following patch, we need to set policy->cpus with mask of all possible cpus
and policy->related_cpus would be filled automatically by the cpufreq core.
commit 4
On 1 February 2013 12:10, Viresh Kumar wrote:
> For multicore SoC's, with cores sharing clock line, we are required to set
> policy->cpus and policy->related_cpus with mask of cpus.
>
> With following patch, we need to set policy->cpus with mask of all possible
> cpus
> and policy->related_cpus w
On 1 February 2013 12:10, Viresh Kumar wrote:
> policy->shared_type field was added only for SoCs with ACPI support:
>
> commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
> Author: Venkatesh Pallipadi
> Date: Wed Dec 14 15:05:00 2005 -0500
>
> P-state software coordination for ACPI core
>
>
On 1 February 2013 12:10, Viresh Kumar wrote:
> With following patch, we need to set policy->cpus with mask of all possible
> cpus
> and policy->related_cpus would be filled automatically by the core.
>
> commit 4948b355e90080cd5ec1e91189f65a01e4186ef2
> Author: Viresh Kumar
> Date: Tue Jan 29
On 1 February 2013 09:22, Viresh Kumar wrote:
> On 1 February 2013 00:14, Fabio Baltieri wrote:
>> As a sidenote, I noticed just now that since:
>>
>> bc92bea cpufreq: Notify governors when cpus are hot-[un]plugged
>>
>> governor's sampling_rate gets reset to default every time you hotplug a
>>
On Friday 01 February 2013 12:10 PM, Viresh Kumar wrote:
policy->shared_type field was added only for SoCs with ACPI support:
commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
Author: Venkatesh Pallipadi
Date: Wed Dec 14 15:05:00 2005 -0500
P-state software coordination for ACPI core
On 1 February 2013 12:17, Santosh Shilimkar wrote:
> I haven't looked at the cpufreq code recently but remember
> that it was needed to ensure that all the CPU which
> share clock/voltage gets updated (affected cpus) on
> freq change. The CPUs which needs SW co-ordination, should
> have this flag
On Friday 01 February 2013 12:43 PM, Viresh Kumar wrote:
On 1 February 2013 12:17, Santosh Shilimkar wrote:
I haven't looked at the cpufreq code recently but remember
that it was needed to ensure that all the CPU which
share clock/voltage gets updated (affected cpus) on
freq change. The CPUs wh
43 matches
Mail list logo
