[PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
Sudeep Holla
sudeep.holla at arm.com
Wed Jan 10 03:34:22 PST 2018
On 10/01/18 04:19, Viresh Kumar wrote:
> On 09-01-18, 16:49, Sudeep Holla wrote:
>> +static int
>> +scpi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>> {
>> - return scpi_ops->get_transition_latency(cpu_dev);
>> + int cpu, domain, tdomain;
>> + struct device *tcpu_dev;
>> +
>> + domain = scpi_ops->device_domain_id(cpu_dev);
>> + if (domain < 0)
>> + return domain;
>> +
>> + for_each_possible_cpu(cpu) {
>> + if (cpu == cpu_dev->id)
>> + continue;
>> +
>> + tcpu_dev = get_cpu_device(cpu);
>> + if (!tcpu_dev)
>> + continue;
>> +
>> + tdomain = scpi_ops->device_domain_id(tcpu_dev);
>> + if (tdomain == domain)
>> + cpumask_set_cpu(cpu, cpumask);
>> + }
>> +
>> + return 0;
>> }
>
> So this is the main thing you want to achieve ? i.e. get the
> policy->cpus from scpi_ops, right ?
>
>From the looks of it yes, but...
> Why can't we update .init_opp_table() to include policy as a parameter
> and let individual stub drivers update policy->cpus then ?
>
Possible, again but ...
There are few reasons why I would like remove scpi dependency on bL driver:
1. It has a notion of big and little which may not be true but that not
much of a problem.
2. MAX_CLUSTER = 2 and scpi is getting used on multi-cluster systems
though it was first tested on Juno which was bL system. There are
quite a few internal FVP platforms that can manage to run with just
proper DT with this change.
3. raw_cpu_to_cluster still calls topology_physical_package_id which
breaks on these platforms and also with introduction of ACPI PPTT it
will break on all ARM64 platforms.
4. We can still leave usage of topology_physical_package_id as is in
arm_big_little.c worst case if it's going to be used only on ARM32
For ARM64, topology_physical_package_id will be changed to give
actual physical socket number which will be 0 for all multi-cluster
(including bL) systems as along as they are single chip.
--
Regards,
Sudeep
More information about the linux-arm-kernel
mailing list