| Message ID | 51769DB3.7030404@ccur.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
On Tue, Apr 23, 2013 at 8:11 PM, John Blackwood <john.blackwood@ccur.com> wrote: > In the cpufreq conservative module, the cpu field in the cpu_dbs_info_s > structure was not being initialized, and thus all cpus were scheduling > their do_dbs_timer() delayed work processing on cpu 0. > > Signed-off-by: John Blackwood <john.blackwood@ccur.com> > Index: b/drivers/cpufreq/cpufreq_conservative.c > =================================================================== > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -506,6 +506,7 @@ static int cpufreq_governor_dbs(struct c > } > this_dbs_info->down_skip = 0; > this_dbs_info->requested_freq = policy->cur; > + this_dbs_info->cpu = cpu; > > mutex_init(&this_dbs_info->timer_mutex); > dbs_enable++; What have you rebased this on? I don't think its the latest code and is probably a bit old. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/23/2013 10:19 AM, Viresh Kumar wrote: > On Tue, Apr 23, 2013 at 8:11 PM, John Blackwood <john.blackwood@ccur.com> wrote: >> In the cpufreq conservative module, the cpu field in the cpu_dbs_info_s >> structure was not being initialized, and thus all cpus were scheduling >> their do_dbs_timer() delayed work processing on cpu 0. >> >> Signed-off-by: John Blackwood <john.blackwood@ccur.com> >> Index: b/drivers/cpufreq/cpufreq_conservative.c >> =================================================================== >> --- a/drivers/cpufreq/cpufreq_conservative.c >> +++ b/drivers/cpufreq/cpufreq_conservative.c >> @@ -506,6 +506,7 @@ static int cpufreq_governor_dbs(struct c >> } >> this_dbs_info->down_skip = 0; >> this_dbs_info->requested_freq = policy->cur; >> + this_dbs_info->cpu = cpu; >> >> mutex_init(&this_dbs_info->timer_mutex); >> dbs_enable++; > > What have you rebased this on? I don't think its the latest code and is probably > a bit old. > Hi Viresh, Yes, you are right. This has been fixed in a different way in the newer kernel source. My apologies. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: b/drivers/cpufreq/cpufreq_conservative.c =================================================================== --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -506,6 +506,7 @@ static int cpufreq_governor_dbs(struct c } this_dbs_info->down_skip = 0; this_dbs_info->requested_freq = policy->cur; + this_dbs_info->cpu = cpu; mutex_init(&this_dbs_info->timer_mutex); dbs_enable++;
In the cpufreq conservative module, the cpu field in the cpu_dbs_info_s structure was not being initialized, and thus all cpus were scheduling their do_dbs_timer() delayed work processing on cpu 0. Signed-off-by: John Blackwood <john.blackwood@ccur.com> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html