Re: [PATCH 15/18] ARM: dts: qcom: apq8064: provide voltage scaling tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/06/2023 16:59, Stephan Gerhold wrote:
On Mon, Jun 12, 2023 at 04:33:09PM +0300, Dmitry Baryshkov wrote:
On 12/06/2023 12:01, Stephan Gerhold wrote:
On Mon, Jun 12, 2023 at 08:39:19AM +0300, Dmitry Baryshkov wrote:
APQ8064 has 4 speed bins, each of them having from 4 to 6 categorization
kinds. Provide tables necessary to handle voltage scaling on this SoC.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
---
   arch/arm/boot/dts/qcom-apq8064.dtsi | 1017 +++++++++++++++++++++++++++
   1 file changed, 1017 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 4ef13f3d702b..f35853b59544 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -49,6 +49,9 @@ CPU0: cpu@0 {
   			clocks = <&kraitcc KRAIT_CPU_0>;
   			clock-names = "cpu";
   			clock-latency = <100000>;
+			vdd-mem-supply = <&pm8921_l24>;
+			vdd-dig-supply = <&pm8921_s3>;
+			vdd-core-supply = <&saw0_vreg>;
   			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
   			operating-points-v2 = <&cpu_opp_table>;
   			#cooling-cells = <2>;
@@ -66,6 +69,9 @@ CPU1: cpu@1 {
   			clocks = <&kraitcc KRAIT_CPU_1>;
   			clock-names = "cpu";
   			clock-latency = <100000>;
+			vdd-mem-supply = <&pm8921_l24>;
+			vdd-dig-supply = <&pm8921_s3>;
+			vdd-core-supply = <&saw1_vreg>;
   			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
   			operating-points-v2 = <&cpu_opp_table>;
   			#cooling-cells = <2>;
@@ -83,6 +89,9 @@ CPU2: cpu@2 {
   			clocks = <&kraitcc KRAIT_CPU_2>;
   			clock-names = "cpu";
   			clock-latency = <100000>;
+			vdd-mem-supply = <&pm8921_l24>;
+			vdd-dig-supply = <&pm8921_s3>;
+			vdd-core-supply = <&saw2_vreg>;
   			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
   			operating-points-v2 = <&cpu_opp_table>;
   			#cooling-cells = <2>;
@@ -100,6 +109,9 @@ CPU3: cpu@3 {
   			clocks = <&kraitcc KRAIT_CPU_3>;
   			clock-names = "cpu";
   			clock-latency = <100000>;
+			vdd-mem-supply = <&pm8921_l24>;
+			vdd-dig-supply = <&pm8921_s3>;
+			vdd-core-supply = <&saw3_vreg>;
   			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
   			operating-points-v2 = <&cpu_opp_table>;
   			#cooling-cells = <2>;
@@ -132,6 +144,81 @@ cpu_opp_table: opp-table-cpu {
   		opp-384000000 {
   			opp-hz = /bits/ 64 <384000000>;
   			opp-peak-kBps = <384000>;
+			opp-microvolt-speed0-pvs0 = <1050000 1050000 1150000>,
+						    <950000 950000 1150000>,
+						    <950000 950000 975000>;


[skipped the OPP voltage vs bw ordering]



The alternative that I've already argued for on IRC in #linux-msm a
couple of days ago would be to give the L2 cache (here: "interconnect")
an own OPP table where it can describe its voltage requirements,
independent from the CPU. That way the icc_set_bw() would be guaranteed
to apply the correct voltage before adjusting the L2 cache clock. It
looks like the "l2_level" voltages for vdd_dig and vdd_mem are not
speedbin/PVS-specific [2] so this would also significantly reduce the DT
size, since you wouldn't need to repeat the same vdd_dig/vdd_mem
voltages for all of them.

Yes. I fact our discussion triggered me to do this patchset.

So, another option would be to have something like the following snippet. Do
you know if we are allowed to squish additional data into the L2 cache DT
node?


I suspect no one has tried this before, so only the DT maintainers could
answer this. I would say that it just follows the existing design of
clocks/-supply/OPPs on the CPU nodes. vdd-mem-supply isn't a property of
the CPU, it's a property of the L2 cache so it actually fits better there. >
I think the more controversial questions might be:

   - Is a L2 cache really an "interconnect"? I suppose one could argue it
     connects multiple CPU cores to a cluster (similar how a CCI connects
     multiple clusters to a system).

Yes. This was my reasoning for CBF clock as well as for this L2 clock. The separate L2 cache device is also an interconnect from my POV. It connects all CPU cores and we have to vote on its frequency.

   - What would bind to the l2-cache node? A separate driver? Does that
     work if it sits below the /cpus node?

In the worst case we'd have to populate that manually. E.g. from the qcom-cpufreq-nvmem.c

--
With best wishes
Dmitry




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux