On Mon, Aug 10, 2020 at 01:15:24PM +0200, ansuelsmth@gmail.com wrote:

quoted

-----Messaggio originale-----
Da: Sudeep Holla [off-list ref]
Inviato: lunedì 10 agosto 2020 10:02
A: Ansuel Smith [off-list ref]
Cc: Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
[off-list ref]; Rob Herring [off-list ref]; linux-
pm@vger.kernel.org; devicetree@vger.kernel.org; linux-
kernel@vger.kernel.org
Oggetto: Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU
Cache scaling

On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote:

quoted

Document dedicated Krait CPU Cache Scaling driver.

Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
 .../bindings/cpufreq/krait-cache-scale.yaml   | 92

+++++++++++++++++++

quoted

 1 file changed, 92 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-

cache-scale.yaml

quoted

diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-

scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
scale.yaml

quoted

new file mode 100644
index 000000000000..f10b1f386a99

--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-

scale.yaml

quoted

@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Cpu Cache Frequency Scaling dedicated driver
+
+maintainers:
+  - Ansuel Smith <ansuelsmth@gmail.com>
+
+description: |
+  This Scale the Krait CPU Cache Frequency and optionally voltage
+  when the Cpu Frequency is changed (using the cpufreq notifier).
+
+  Cache is scaled with the max frequency across all core and the cache
+  frequency will scale based on the configured threshold in the dts.
+
+  The cache is hardcoded to 3 frequency bin, idle, nominal and high.
+
+properties:
+  compatible:
+    const: qcom,krait-cache
+

How does this fit in the standard cache hierarchy nodes ? Extend the
example to cover that.

I think i didn't understand this question. You mean that I should put
in the example how the standard l2 cache nodes are defined?

I was referring to something like below which I found now in
arch/arm/boot/dts/qcom-msm8974.dtsi:
	L2: l2-cache {
		compatible = "cache";
		cache-level = <2>;
		qcom,saw = <&saw_l2>;
	};

quoted

quoted

+  clocks:
+    description: Phandle to the L2 CPU clock
+
+  clock-names:
+    const: "l2"
+
+  voltage-tolerance:
+    description: Same voltage tollerance of the Krait CPU
+
+  l2-rates:
+    description: |
+      Frequency the L2 cache will be scaled at.
+      Value is in Hz.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    items:
+      - description: idle
+      - description: nominal
+      - description: high
+

Why can't you re-use the standard OPP v2 bindings ?

Isn't overkill to use the OPP v2 bindings to represent the the microvolt
related to the le freq? Is the OPP v1 sufficient?

Should be fine if it is allowed. v2 came out in the flow of my thought
and was not intentional.

Also I can't find a way to reflect this specific case where the l2 rates
are changed based on the cpu freq value? Any idea about that?

OK, I am always opposed to giving such independent controls in the kernel
as one can play around say max cpu freq and lowest cache or vice-versa
and create instabilities. IMO this should be completely hidden from OS.
But I know these are old platforms, so I will shut my mouth ;)

--
Regards,
Sudeep