On 04/23/2013 10:19 AM, Viresh Kumar wrote:
On Tue, Apr 23, 2013 at 8:11 PM, John Blackwood <john.blackwood@xxxxxxxx> 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@xxxxxxxx> 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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
