Skip to contentSkip to conversation

cpufreq_conservative: initialize the cpu_dbs_info_s cpu field

PATCH In review John Blackwood 2 participants 3 messages Apr 23, 2013 CPU frequency scaling framework

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 cpufreq_conservative: initialize the cpu_dbs_info_s cpu field

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.

drivers/cpufreq/cpufreq_conservative.c +1 -0
Index: 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++;
maintainer
#1 lore raw
Quoted 10 lines · John Blackwood

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.

Index: b/drivers/cpufreq/cpufreq_conservative.c
===================================================================

drivers/cpufreq/cpufreq_conservative.c static int cpufreq_governor_dbs(struct c · line 512

Quoted 7 lines
drivers/cpufreq/cpufreq_conservative.c +1 -0
@@ -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.

#2 lore raw
Quoted 16 lines · Viresh Kumar
Quoted 15 lines · John Blackwood

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.

Index: b/drivers/cpufreq/cpufreq_conservative.c
===================================================================

drivers/cpufreq/cpufreq_conservative.c +1 -0
@@ -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;
 
Quoted 6 lines

drivers/cpufreq/cpufreq_conservative.c static int cpufreq_governor_dbs(struct c · line 512

Quoted 2 lines
drivers/cpufreq/cpufreq_conservative.c +0 -0
                 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.