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: ilia...@codeaurora.org <ilia...@codeaurora.org>
> Sent: Tuesday, May 22, 2018 09:56
> To: 'Sudeep Holla' <sudeep.ho...@arm.com>; 'mturque...@baylibre.com'
> <mturque...@baylibre.com>; 'sb...@kernel.org' <sb...@kernel.org>;
> 'r...@kernel.org' <r...@kernel.org>; 'mark.rutl...@arm.com'
> <mark.rutl...@arm.com>; 'viresh.ku...@linaro.org'
> <viresh.ku...@linaro.org>; 'n...@ti.com' <n...@ti.com>;
> 'lgirdw...@gmail.com' <lgirdw...@gmail.com>; 'broo...@kernel.org'
> <broo...@kernel.org>; 'andy.gr...@linaro.org' <andy.gr...@linaro.org>;
> 'david.br...@linaro.org' <david.br...@linaro.org>;
> 'catalin.mari...@arm.com' <catalin.mari...@arm.com>;
> 'will.dea...@arm.com' <will.dea...@arm.com>; 'r...@rjwysocki.net'
> <r...@rjwysocki.net>; 'linux-...@vger.kernel.org' <linux-
> c...@vger.kernel.org>
> Cc: 'devicet...@vger.kernel.org' <devicet...@vger.kernel.org>; 'linux-
> ker...@vger.kernel.org' <linux-kernel@vger.kernel.org>; 'linux-
> p...@vger.kernel.org' <linux...@vger.kernel.org>; 'linux-arm-
> m...@vger.kernel.org' <linux-arm-...@vger.kernel.org>; 'linux-
> s...@vger.kernel.org' <linux-...@vger.kernel.org>; 'linux-arm-
> ker...@lists.infradead.org' <linux-arm-ker...@lists.infradead.org>;
> 'rna...@codeaurora.org' <rna...@codeaurora.org>;
> 'amit.kuche...@linaro.org' <amit.kuche...@linaro.org>;
> 'nicolas.deche...@linaro.org' <nicolas.deche...@linaro.org>;
> 'cels...@codeaurora.org' <cels...@codeaurora.org>;
> 'tfin...@codeaurora.org' <tfin...@codeaurora.org>
> Subject: RE: [PATCH] cpufreq: Add Kryo CPU scaling driver
>
>
>
> > -----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
