> -----Original Message----- > From: Sudeep Holla <sudeep.ho...@arm.com> > Sent: Monday, May 21, 2018 16:05 > To: ilia...@codeaurora.org; mturque...@baylibre.com; sb...@kernel.org; > r...@kernel.org; mark.rutl...@arm.com; viresh.ku...@linaro.org; > n...@ti.com; lgirdw...@gmail.com; broo...@kernel.org; > andy.gr...@linaro.org; david.br...@linaro.org; catalin.mari...@arm.com; > will.dea...@arm.com; r...@rjwysocki.net; linux-...@vger.kernel.org > Cc: Sudeep Holla <sudeep.ho...@arm.com>; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux...@vger.kernel.org; linux-arm- > m...@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; rna...@codeaurora.org; > amit.kuche...@linaro.org; nicolas.deche...@linaro.org; > cels...@codeaurora.org; tfin...@codeaurora.org > Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver > > > > On 21/05/18 13:57, ilia...@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@0 { ... reg = <0x0 0x0>; ... }; CPU1: cpu@1 { ... reg = <0x0 0x1>; ... }; CPU2: cpu@100 { ... reg = <0x0 0x100>; ... }; CPU3: cpu@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