On 4 September 2014 13:29, Benjamin Herrenschmidt benh@kernel.crashing.org wrote:
What do you mean by "clock line" ? This is a very .... odd concept here.
We want to know which CPUs change their P-state together. As cpufreq considers that as a group (represented by a single struct cpufreq_policy). And while changing frequency of a core, cpufreq governors look at the load of all CPUs within that group and chooses the frequency that satisfies the CPU with highest load.
The architecture doesn't provide such a macro because the link between cpufreq entity is a cpufreq specific concept. For example we could have a chip where cores have pstate by pairs but otherwise are completely
You meant the possible p-states for CPUs are same but they change it separately?
If yes, then this isn't what I meant by a single clock-line..
I don't see how we could provide a "macro" ... we might be able to represent the pstate domains in some way and provide some kind of architecture function for that but it wouldn't be a macro. It happens that today on P8 we control the pstates per core but that might not be always the case for example.
I see. But a cpufreq-driver like "ppc-corenet-cpufreq.c" should be able to get which all CPUs change p-states together, just like powernv..
And that's what we wanted to know for this driver.
Btw, another powerpc driver is doing this: drivers/cpufreq/powernv-cpufreq.c
base = cpu_first_thread_sibling(policy->cpu); for (i = 0; i < threads_per_core; i++) cpumask_set_cpu(base + i, policy->cpus);
Will this work for you as
That's P8 native. It currently use the core as the entity but that probably needs to be improved based on some device-tree property for long term solidity.
I see..