-----Messaggio originale-----
Da: Sudeep Holla [off-list ref]
Inviato: lunedì 10 agosto 2020 14:45
A: ansuelsmth@gmail.com
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: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait
CPU Cache scaling

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

quoted

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

quoted

quoted

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-

quoted

quoted

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

quoted

quoted

quoted

+  frequency will scale based on the configured threshold in the

dts.

quoted

quoted

quoted

+
+  The cache is hardcoded to 3 frequency bin, idle, nominal and

high.

quoted

quoted

quoted

+
+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

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.

quoted

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 ;)

If we really want to deny this practice, I can add a check in the probe
function to fail if the l2 freq threshold is less than the cpu freq. 

--
Regards,
Sudeep