Thread (50 messages) 50 messages, 6 authors, 2018-05-23

[PATCH] cpufreq: Add Kryo CPU scaling driver

From: ilialin at codeaurora.org <hidden>
Date: 2018-05-22 06:56:42
Also in: linux-arm-msm, linux-clk, linux-devicetree, linux-pm, lkml

-----Original Message-----
From: Sudeep Holla <redacted>
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 <redacted>; 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:
quoted
[...]
quoted
quoted
quoted
+#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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help