On 11 September 2013 16:44, Srivatsa S. Bhat <srivatsa.b...@linux.vnet.ibm.com> wrote: > Hmm? The problem is not about merely updating the policy->cpu field; the > main issue is that the existing code was not letting the cpufreq-stats > code know that we updated the policy->cpu under the hood. It is important > for cpufreq-stats to know this because it maintains the reference to its > stats structure by associating it with the policy->cpu. So if policy->cpu > changes under the hood, it loses track of its reference. So we need to > keep that code informed about changes to policy->cpu. Thus, we need to call > update_policy_cpu() in the CPU online path (during resume). I don't see > how we can skip that.
Okay.. There are two different ways in which cpufreq_add_dev() work currently.. Boot cluster (i.e. policy with boot CPU) --------------- Here cpufreq_remove_dev() is never called for boot cpu but all others. And similarly cpufreq_add_dev() is never called for boot cpu but all others. Now policy->cpu contains meaningful cpu at beginning of resume and we don't need to modify that at all.. For all the remaining CPUs we better call cpufreq_add_policy_cpu() rather.. Non-boot Cluster --------------------- All CPUs here are removed and at the end policy->cpu contains the last cpu removed.. So, for a cluster with cpu 2 and 3.... it will contain 3.. Not at resume we will add cpu2 first and so need to update policy->cpu to 2.. But for all other CPUs in this cluster we return early from cpufreq_add_dev() and call cpufreq_add_policy_cpu() as policy->cpus was fixed by call to ->init() for the first cpu of this cluster.. And so we never reach the line: policy->cpu = cpu; For the first cpu of non-boot cluster we need to call update_policy_cpu() and not for others.. But for the boot cluster if we can call ->init() somehow at resume time, then things would be fairly similar in both cases.. I am running of time now, as need to leave office now... I hope I made the problem more clear or probably the way I see it :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
