On 25 June 2013 12:24, Lan Tianyu <tianyu.lan@xxxxxxxxx> wrote:
> On 2013年06月25日 11:56, Viresh Kumar wrote:
>> This is generic file, don't add this information here. Add this in
>> acpi-cpufreq file.
> I don't find acpi-cpufreq.txt under
> Documentation/cpu-freq/acpi-cpufreq.txt. So I should create it?
I meant acpi-cpufreq.c file
> Please see the acpi_processor_preregister_performance() in the
> drivers/acpi/processor_perlib.c. All cpus in the same dependency domain
> are stored in the perf->shared_cpu_map(including the reference cpu the
> perf belongs to). Original code will copy shared_cpu_map to
> policy->related_cpus, do cpumask_or between policy->related_cpus and
> policy->cpus in the cpufreq_add_dev() and store the result into
> policy->related_cpus. Expose the data via related_cpus.
>
> For acpi-cpufreq driver, the shared_cpu_map is the biggest subset since
> it regardless the coordination type.
>
> After the commit aa77a5, only the cpus in the software or
> software&hardware coordination type dependency domain will copy to
> policy->cpus and finally store into policy->related_cpus in the
> cpufreq_add_dev() by cpumask_or. And then we miss the cpus in the
> hardware coordination type domain. But these info is still stored in the
> policy->shared_cpu_map. Does this make sense?
I was concerned about this code that was present earlier. That changes
related_cpus based on some conditions.
if (check_amd_hwpstate_cpu(cpu) && !acpi_pstate_strict) {
cpumask_clear(policy->cpus);
cpumask_set_cpu(cpu, policy->cpus);
cpumask_copy(policy->related_cpus, cpu_sibling_mask(cpu));
policy->shared_type = CPUFREQ_SHARED_TYPE_HW;
pr_info_once(PFX "overriding BIOS provided _PSD data\n");
}
--
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
