[RFC PATCH v2 0/2] Add Krait Cache Scaling support

[RFC PATCH v2 0/2] Add Krait Cache Scaling support

[Ansuel Smith]

This adds Krait Cache scaling support using the cpufreq notifier.
I have some doubt about where this should be actually placed (clk or cpufreq)?
Also the original idea was to create a dedicated cpufreq driver (like it's done in
the codeaurora qcom repo) by copying the cpufreq-dt driver and adding the cache
scaling logic but i still don't know what is better. Have a very similar driver or
add a dedicated driver only for the cache using the cpufreq notifier and do the
scale on every freq transition.
Thanks to everyone who will review or answer these questions.

v2:
* Fix Documentation error reported by bot
* Rework code to fail probe on missing required params
* Optimize notifier callback to reduce CPU cycle

Ansuel Smith (2):
  cpufreq: qcom: Add Krait Cache Scaling support
  dt-bindings: cpufreq: Document Krait CPU Cache scaling

 .../bindings/cpufreq/krait-cache-scale.yaml   |  92 ++++++++
 drivers/cpufreq/Kconfig.arm                   |   9 +
 drivers/cpufreq/Makefile                      |   1 +
 drivers/cpufreq/krait-cache.c                 | 214 ++++++++++++++++++
 4 files changed, 316 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
 create mode 100644 drivers/cpufreq/krait-cache.c

-- 
2.27.0

[RFC PATCH v2 1/2] cpufreq: qcom: Add Krait Cache Scaling support

[Ansuel Smith]

Qcom Krait CPUs use the generic cpufreq-dt driver and doesn't actually
scale the Cache frequency when the CPU frequency is changed. This
companion driver register with the cpu notifier and scale the Cache
based on the max Freq across all core as the CPU cache is shared across
all of them. If provided this also scale the voltage of the regulator
attached to the CPU cache. The scaling logic is based on the CPU freq
and the 3 scaling interval are set by the device dts.

Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
 drivers/cpufreq/Kconfig.arm   |   9 ++
 drivers/cpufreq/Makefile      |   1 +
 drivers/cpufreq/krait-cache.c | 213 ++++++++++++++++++++++++++++++++++
 3 files changed, 223 insertions(+)
 create mode 100644 drivers/cpufreq/krait-cache.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index c6cbfc8baf72..4ed5e73051df 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -126,6 +126,15 @@ config ARM_OMAP2PLUS_CPUFREQ
 	depends on ARCH_OMAP2PLUS
 	default ARCH_OMAP2PLUS
 
+config ARM_QCOM_KRAIT_CACHE_SCALE
+	tristate "Scaling support for Krait CPU Cache"
+	depends on ARCH_QCOM || COMPILE_TEST
+	help
+	  This adds the Scaling support for the Krait CPU Cache shared by
+	  all cores.
+
+	  If in doubt, say N.
+
 config ARM_QCOM_CPUFREQ_NVMEM
 	tristate "Qualcomm nvmem based CPUFreq"
 	depends on ARCH_QCOM
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f6670c4abbb0..eee53d7e8b09 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)			+= pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_KRAIT_CACHE_SCALE) += krait-cache.o
 obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)	+= qcom-cpufreq-hw.o
 obj-$(CONFIG_ARM_QCOM_CPUFREQ_NVMEM)	+= qcom-cpufreq-nvmem.o
 obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ) 	+= raspberrypi-cpufreq.o
diff --git a/drivers/cpufreq/krait-cache.c b/drivers/cpufreq/krait-cache.c
new file mode 100644
index 000000000000..a2a14eb38dc0
--- /dev/null
+++ b/drivers/cpufreq/krait-cache.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/cpufreq.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+#include <linux/regulator/consumer.h>
+
+struct krait_data {
+	struct clk *l2_clk; /* L2 clock */
+	unsigned int l2_volt_tol; /* L2 voltage tolerance */
+
+	struct regulator *l2_regulator; /* L2 supply */
+	unsigned int l2_rate[3]; /* L2 bus clock rate */
+
+	unsigned int l2_cpufreq[3]; /* L2 target CPU frequency */
+	unsigned int l2_volt[3]; /* L2 voltage array */
+
+	unsigned long curr_l2_freq;
+	unsigned long curr_l2_volt;
+
+	struct notifier_block nb;
+};
+
+static int krait_cache_notifier(struct notifier_block *nb, unsigned long cmd,
+				void *v)
+{
+	unsigned int target_freq, cpu, cur_cpu, l2_index, tol;
+	unsigned long curr_l2_freq, target_l2_freq;
+	unsigned long curr_l2_vol, target_l2_volt;
+	struct cpufreq_freqs *freqs;
+	struct krait_data *data;
+	struct clk *l2_clk;
+	int ret = 0;
+
+	if (cmd == CPUFREQ_PRECHANGE) {
+		freqs = (struct cpufreq_freqs *)v;
+		target_freq = freqs->new;
+		cur_cpu = freqs->policy->cpu;
+
+		data = container_of(nb, struct krait_data, nb);
+
+		l2_clk = data->l2_clk;
+
+		/* find the max freq across all core */
+		for_each_present_cpu(cpu)
+			if (cpu != cur_cpu)
+				target_freq = max(target_freq,
+						  cpufreq_quick_get(cpu));
+
+		/* find l2_freq and l2_volt  */
+		for (l2_index = 0;
+		     l2_index < 2 && target_freq <= data->l2_cpufreq[l2_index];
+		     l2_index++)
+			break;
+
+		curr_l2_freq = data->curr_l2_freq;
+		target_l2_freq = data->l2_rate[l2_index];
+
+		/* scale only if needed */
+		if (curr_l2_freq != target_l2_freq) {
+			/*
+			 * Set to idle bin if switching from normal to high bin
+			 * or vice versa. It has been notice that a bug is triggered
+			 * in cache scaling when more than one bin is scaled, to fix
+			 * this we first need to transition to the base rate and then
+			 * to target rate
+			 */
+			if (likely(l2_index > 0 &&
+				   curr_l2_freq != data->l2_rate[0])) {
+				ret = clk_set_rate(l2_clk, data->l2_rate[0]);
+				if (ret)
+					goto exit;
+			}
+
+			ret = clk_set_rate(l2_clk, target_l2_freq);
+			if (ret)
+				goto exit;
+
+			data->curr_l2_freq = target_l2_freq;
+
+			curr_l2_vol = data->curr_l2_volt;
+			target_l2_volt = data->l2_volt[l2_index];
+
+			if (curr_l2_vol != target_l2_volt) {
+				tol = target_l2_volt * data->l2_volt_tol / 100;
+				ret = regulator_set_voltage_tol(
+					data->l2_regulator, target_l2_volt,
+					tol);
+				if (ret)
+					goto exit;
+
+				data->curr_l2_volt = target_l2_volt;
+			}
+		}
+	}
+
+exit:
+	return notifier_from_errno(ret);
+}
+
+static int krait_cache_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct clk *l2_clk;
+	struct device_node *vdd;
+	struct krait_data *data;
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->l2_clk = clk_get(dev, "l2");
+	if (IS_ERR(l2_clk)) {
+		ret = PTR_ERR(l2_clk);
+		goto exit;
+	}
+
+	ret = of_property_read_u32(node, "voltage-tolerance",
+				   &data->l2_volt_tol);
+	if (ret) {
+		dev_err(dev, "missing voltage tolerance\n");
+		goto exit;
+	}
+
+	ret = of_property_read_u32_array(node, "l2-rates", data->l2_rate, 3);
+	if (ret) {
+		dev_err(dev, "failed to parse L2 rates\n");
+		goto exit;
+	}
+
+	ret = of_property_read_u32_array(node, "l2-cpufreq", data->l2_cpufreq,
+					 3);
+	if (ret) {
+		dev_err(dev, "failed to parse L2 cpufreq range\n");
+		goto exit;
+	}
+
+	ret = of_property_read_u32_array(node, "l2-volt", data->l2_volt, 3);
+	if (ret) {
+		dev_err(dev, "failed to parse L2 volt range\n");
+		goto exit;
+	}
+
+	vdd = of_parse_phandle(node, "l2-supply", 0);
+	if (!vdd) {
+		dev_err(dev, "missing L2 supply\n");
+		ret = -EINVAL;
+		goto exit;
+	}
+
+	data->l2_regulator = devm_regulator_get(dev, vdd->name);
+	if (IS_ERR(data->l2_regulator)) {
+		dev_err(dev, "failed to get l2 supply, error=%pe\n",
+			data->l2_regulator);
+		ret = PTR_ERR(data->l2_regulator);
+		goto exit_vdd;
+	}
+
+	platform_set_drvdata(pdev, data);
+
+	data->nb.notifier_call = krait_cache_notifier;
+	cpufreq_register_notifier(&data->nb, CPUFREQ_TRANSITION_NOTIFIER);
+
+exit_vdd:
+	of_node_put(vdd);
+exit:
+	return ret;
+}
+
+static int krait_cache_remove(struct platform_device *pdev)
+{
+	struct krait_data *data = platform_get_drvdata(pdev);
+
+	cpufreq_unregister_notifier(&data->nb, CPUFREQ_TRANSITION_NOTIFIER);
+
+	return 0;
+}
+
+static const struct of_device_id krait_cache_match_table[] = {
+	{ .compatible = "qcom,krait-cache" },
+	{}
+};
+
+static struct platform_driver krait_cache_driver = {
+	.probe		= krait_cache_probe,
+	.remove		= krait_cache_remove,
+	.driver		= {
+		.name   = "krait-cache-scaling",
+		.of_match_table = krait_cache_match_table,
+	},
+};
+
+static int __init krait_cache_init(void)
+{
+	return platform_driver_register(&krait_cache_driver);
+}
+late_initcall(krait_cache_init);
+
+static void __exit krait_cache_exit(void)
+{
+	platform_driver_unregister(&krait_cache_driver);
+}
+module_exit(krait_cache_exit);
+
+MODULE_DESCRIPTION("Krait CPU Cache Scaling driver");
+MODULE_LICENSE("GPL v2");
-- 
2.27.0

[RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling

[Ansuel Smith]

Document dedicated Krait CPU Cache Scaling driver.

Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
 .../bindings/cpufreq/krait-cache-scale.yaml   | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml

diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
new file mode 100644
index 000000000000..f10b1f386a99
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
@@ -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
+
+  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
+
+  l2-cpufreq:
+    description: |
+      Threshold used by the driver to scale the L2 cache.
+      If the max CPU Frequency is more than the set frequency,
+      the driver will transition to the next frequency bin.
+      Value is in kHz
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    items:
+      - description: idle
+      - description: nominal
+      - description: high
+
+  l2-volt:
+    description: |
+      Threshold used by the driver to scale the L2 cache.
+      If the max CPU Frequency is more than the set frequency,
+      the driver will transition to the next frequency bin.
+      Value is in microvolt.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    items:
+      - description: idle
+      - description: nominal
+      - description: high
+
+  l2-supply:
+    description: Phandle to the L2 regulator supply.
+
+required:
+  - compatible
+  - clocks
+  - clock-names
+  - voltage-tolerance
+  - l2-rates
+  - l2-cpufreq
+  - l2-supply
+  - l2-volt
+
+examples:
+  - |
+    qcom-krait-cache {
+      compatible = "qcom,krait-cache";
+      clocks = <&kraitcc 4>;
+      clock-names = "l2";
+      voltage-tolerance = <5>;
+      l2-rates = <384000000 1000000000 1200000000>;
+      l2-cpufreq = <384000 600000 1200000>;
+      l2-volt = <1100000 1100000 1150000>;
+      l2-supply = <&smb208_s1a>;
+    };
-- 
2.27.0

Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling

[Sudeep Holla]

On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote:
> Document dedicated Krait CPU Cache Scaling driver.
> 
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
>  .../bindings/cpufreq/krait-cache-scale.yaml   | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
> new file mode 100644
> index 000000000000..f10b1f386a99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
> @@ -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.

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

--
Regards,
Sudeep

R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling

[ansuelsmth]

> -----Messaggio originale-----
> Da: Sudeep Holla <sudeep.holla@arm.com>
> Inviato: lunedì 10 agosto 2020 10:02
> A: Ansuel Smith <ansuelsmth@gmail.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Rob Herring <robh+dt@kernel.org>; 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:
> > Document dedicated Krait CPU Cache Scaling driver.
> >
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> >  .../bindings/cpufreq/krait-cache-scale.yaml   | 92
> +++++++++++++++++++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-
> cache-scale.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-
> scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> scale.yaml
> > new file mode 100644
> > index 000000000000..f10b1f386a99
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> scale.yaml
> > @@ -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?

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

> --
> Regards,
> Sudeep

Re: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling

[Sudeep Holla]

On Mon, Aug 10, 2020 at 01:15:24PM +0200, ansuelsmth@gmail.com wrote:
>
>
> > -----Messaggio originale-----
> > Da: Sudeep Holla <sudeep.holla@arm.com>
> > Inviato: lunedì 10 agosto 2020 10:02
> > A: Ansuel Smith <ansuelsmth@gmail.com>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> > <rjw@rjwysocki.net>; Rob Herring <robh+dt@kernel.org>; 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:
> > > Document dedicated Krait CPU Cache Scaling driver.
> > >
> > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > > ---
> > >  .../bindings/cpufreq/krait-cache-scale.yaml   | 92
> > +++++++++++++++++++
> > >  1 file changed, 92 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-
> > cache-scale.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml
> > > new file mode 100644
> > > index 000000000000..f10b1f386a99
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml
> > > @@ -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>;
	};

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

R: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling

[ansuelsmth]

> -----Messaggio originale-----
> Da: Sudeep Holla <sudeep.holla@arm.com>
> Inviato: lunedì 10 agosto 2020 14:45
> A: ansuelsmth@gmail.com
> Cc: 'Viresh Kumar' <viresh.kumar@linaro.org>; 'Rafael J. Wysocki'
> <rjw@rjwysocki.net>; 'Rob Herring' <robh+dt@kernel.org>; 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:
> >
> >
> > > -----Messaggio originale-----
> > > Da: Sudeep Holla <sudeep.holla@arm.com>
> > > Inviato: lunedì 10 agosto 2020 10:02
> > > A: Ansuel Smith <ansuelsmth@gmail.com>
> > > Cc: Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> > > <rjw@rjwysocki.net>; Rob Herring <robh+dt@kernel.org>; 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:
> > > > Document dedicated Krait CPU Cache Scaling driver.
> > > >
> > > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > > > ---
> > > >  .../bindings/cpufreq/krait-cache-scale.yaml   | 92
> > > +++++++++++++++++++
> > > >  1 file changed, 92 insertions(+)
> > > >  create mode 100644
> Documentation/devicetree/bindings/cpufreq/krait-
> > > cache-scale.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml
> > > > new file mode 100644
> > > > index 000000000000..f10b1f386a99
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml
> > > > @@ -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>;
> 	};
> 
> > > > +  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 ;)
> 

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