[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