On 3/25/2013 2:15 PM, Viresh Kumar wrote: > On 25 March 2013 14:06, Sekhar Nori <nsek...@ti.com> wrote: >> There is a line in the code a little above the ones you deleted that >> also sets these same variables. I guess you were relying on that line to >> set policy->cur, but that also sets policy->{min, max} which can be >> cleaned up. > > This code is rather confusing or wrong, this was the state of code before > this patch: > > policy->cur = policy->min = policy->max = davinci_getspeed(0); > > if (freq_table) { > result = cpufreq_frequency_table_cpuinfo(policy, freq_table); > if (!result) > cpufreq_frequency_table_get_attr(freq_table, > policy->cpu); > } else { > policy->cpuinfo.min_freq = policy->min; > policy->cpuinfo.max_freq = policy->max; > } > > policy->min = policy->cpuinfo.min_freq; > policy->max = policy->cpuinfo.max_freq; > policy->cur = davinci_getspeed(0); > > > The tricky part is if/else, where if don't return error if > cpufreq_frequency_table_cpuinfo() fails. We want to set ->min[max] > and cpuinfo.min[max] always. And i can see this code not doing that for some > case even with my patch. > > Possible scenarios: > 1. Valid freq_table: My patch + what you suggested is required. > 2. Invalid freq_table: We never set cpuinfo.min[max] with or without my patch > 3. No freq_table: Only my patch is required. > > If i do what you suggested then 2 and 3 would fail... If you want to > return error > in case cpufreq_frequency_table_cpuinfo(), then i can fix it properly.
So down in the cpufreq driver probe below, we bail out if freq_table is not provided. So all this checking for freq_table in the code you pasted above is superfluous. If you can clean that part up and add checking for cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to test it out ;) Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html