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
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: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 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 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 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:
> 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
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
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
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
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
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 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
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 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 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
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 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
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 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
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 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-
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
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
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
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 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 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 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/
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 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
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-
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
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 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 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
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: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 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
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 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
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
43 matches
Mail list logo
