Subject: [PATCH] cpufreq: Add Kryo CPU scaling driver

From: [email-masked] (ilialin at codeaurora.org)
Date: Tue, 22 May 2018 10:59:07 +0300

OK, I think I found out the way. Would this be correct?
-----------------------------------------------------------------------------------------------
extern struct cpu_topology cpu_topology[NR_CPUS];

static struct device *qcom_cpufreq_kryo_get_cluster_lead(int cluster)
{
	unsigned cpu;

	for_each_possible_cpu(cpu) {
		if ((cluster == cpu_topology[cpu].cluster_id) &&
			(0 == cpu_topology[cpu].core_id))
			return get_cpu_device(cpu);
	}

	return NULL;
}
-----------------------------------------------------------------------------------------------

> -----Original Message-----
> From: ilialin at codeaurora.org <[email-masked]>
> Sent: Tuesday, May 22, 2018 09:56
> To: 'Sudeep Holla' <[email-masked]>; 'mturquette at baylibre.com'
> <[email-masked]>; 'sboyd at kernel.org' <[email-masked]>;
> 'robh at kernel.org' <[email-masked]>; 'mark.rutland at arm.com'
> <[email-masked]>; 'viresh.kumar at linaro.org'
> <[email-masked]>; 'nm at ti.com' <[email-masked]>;
> 'lgirdwood at gmail.com' <[email-masked]>; 'broonie at kernel.org'
> <[email-masked]>; 'andy.gross at linaro.org' <[email-masked]>;
> 'david.brown at linaro.org' <[email-masked]>;
> 'catalin.marinas at arm.com' <[email-masked]>;
> 'will.deacon at arm.com' <[email-masked]>; 'rjw at rjwysocki.net'
> <[email-masked]>; 'linux-clk at vger.kernel.org' <linux-
> clk at vger.kernel.org>
> Cc: 'devicetree at vger.kernel.org' <[email-masked]>; 'linux-
> kernel at vger.kernel.org' <[email-masked]>; 'linux-
> pm at vger.kernel.org' <[email-masked]>; 'linux-arm-
> msm at vger.kernel.org' <[email-masked]>; 'linux-
> soc at vger.kernel.org' <[email-masked]>; 'linux-arm-
> kernel at lists.infradead.org' <[email-masked]>;
> 'rnayak at codeaurora.org' <[email-masked]>;
> 'amit.kucheria at linaro.org' <[email-masked]>;
> 'nicolas.dechesne at linaro.org' <[email-masked]>;
> 'celster at codeaurora.org' <[email-masked]>;
> 'tfinkel at codeaurora.org' <[email-masked]>
> Subject: RE: [PATCH] cpufreq: Add Kryo CPU scaling driver
> 
> 
> 
> > -----Original Message-----
> > From: Sudeep Holla <[email-masked]>
> > Sent: Monday, May 21, 2018 16:05
> > To: ilialin at codeaurora.org; mturquette at baylibre.com; sboyd at kernel.org;
> > robh at kernel.org; mark.rutland at arm.com; viresh.kumar at linaro.org;
> > nm at ti.com; lgirdwood at gmail.com; broonie at kernel.org;
> > andy.gross at linaro.org; david.brown at linaro.org;
> > catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net;
> > linux-clk at vger.kernel.org
> > Cc: Sudeep Holla <[email-masked]>; devicetree at vger.kernel.org;
> > linux-kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> > msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; rnayak at codeaurora.org;
> > amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> > celster at codeaurora.org; tfinkel at codeaurora.org
> > Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
> >
> >
> >
> > On 21/05/18 13:57, ilialin at codeaurora.org wrote:
> > >
> > [...]
> >
> > >>> +#include <linux/cpu.h>
> > >>> +#include <linux/err.h>
> > >>> +#include <linux/init.h>
> > >>> +#include <linux/kernel.h>
> > >>> +#include <linux/module.h>
> > >>> +#include <linux/nvmem-consumer.h> #include <linux/of.h> #include
> > >>> +<linux/platform_device.h> #include <linux/pm_opp.h> #include
> > >>> +<linux/slab.h> #include <linux/soc/qcom/smem.h>
> > >>> +
> > >>> +#define MSM_ID_SMEM	137
> > >>> +#define SILVER_LEAD	0
> > >>> +#define GOLD_LEAD	2
> > >>> +
> > >>
> > >> So I gather form other emails, that these are physical cpu
> > >> number(not even unique identifier like MPIDR). Will this work on
> > >> parts or platforms that need to boot in GOLD LEAD cpus.
> > >
> > > The driver is for Kryo CPU, which (and AFAIK all multicore MSMs)
> > > always boots on the CPU0.
> >
> >
> > That may be true and I am not that bothered about it. But assuming
> > physical ordering from the logical cpu number is *incorrect* and will
> > break if kernel decides to change the allocation algorithm. Kernel
> > provides no guarantee on that, so you need to depend on some physical
> > ID or may be DT to achieve what your want. But the current code as it
> stands is wrong.
> 
> Got your point. In fact CPUs are numbered 0-3 and ordered into 2 clusters in
> the DT:
> 
> cpus {
> 	#address-cells = <2>;
> 	#size-cells = <0>;
> 
> 	CPU0: cpu at 0 {
> 		...
> 		reg = <0x0 0x0>;
> 		...
> 	};
> 
> 	CPU1: cpu at 1 {
> 		...
> 		reg = <0x0 0x1>;
> 		...
> 	};
> 
> 	CPU2: cpu at 100 {
> 		...
> 		reg = <0x0 0x100>;
> 		...
> 	};
> 
> 	CPU3: cpu at 101 {
> 		...
> 		reg = <0x0 0x101>;
> 		...
> 	};
> 
> 	cpu-map {
> 		cluster0 {
> 			core0 {
> 				cpu = <&CPU0>;
> 			};
> 
> 			core1 {
> 				cpu = <&CPU1>;
> 			};
> 		};
> 
> 		cluster1 {
> 			core0 {
> 				cpu = <&CPU2>;
> 			};
> 
> 			core1 {
> 				cpu = <&CPU3>;
> 			};
> 		};
> 	};
> };
> 
> As far, as I understand, they are probed in the same order. However, to be
> certain that the physical CPU is the one I intend to configure, I have to fetch
> the device structure pointer for the cpu-map -> clusterX -> core0 -> cpu path.
> Could you suggest a kernel API to do that?
> 
> 
> 
> >
> > --
> > Regards,
> > Sudeep