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

[RFC PATCH v3 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.

v3:
* Use opp infrastructure
* Update documentation

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   |  79 ++++++
 drivers/cpufreq/Kconfig.arm                   |   9 +
 drivers/cpufreq/Makefile                      |   1 +
 drivers/cpufreq/krait-cache.c                 | 232 ++++++++++++++++++
 4 files changed, 321 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 v3 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 | 232 ++++++++++++++++++++++++++++++++++
 3 files changed, 242 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..0646fde9d920
--- /dev/null
+++ b/drivers/cpufreq/krait-cache.c
@@ -0,0 +1,232 @@
+// 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>
+#include <linux/pm_opp.h>
+
+struct krait_data {
+	struct device *dev;
+
+	unsigned int *l2_rates; /* L2 bus clock rate */
+	unsigned int *l2_cpufreq; /* L2 target CPU frequency */
+
+	struct notifier_block nb;
+};
+
+static int krait_cache_set_opp(struct dev_pm_set_opp_data *data)
+{
+	unsigned long old_freq = data->old_opp.rate, freq = data->new_opp.rate;
+	struct dev_pm_opp_supply *supply = &data->new_opp.supplies[0];
+	struct regulator *reg = data->regulators[0];
+	struct clk *clk = data->clk;
+	struct krait_data *kdata;
+	unsigned long idle_freq;
+	int ret;
+
+	kdata = (struct krait_data *)dev_get_drvdata(data->dev);
+
+	idle_freq = kdata->l2_rates[0];
+
+	ret = regulator_set_voltage_triplet(reg, supply->u_volt_min,
+					    supply->u_volt, supply->u_volt_max);
+	if (ret)
+		goto exit;
+
+	/*
+	 * 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(freq != idle_freq && old_freq != idle_freq)) {
+		ret = clk_set_rate(clk, idle_freq);
+		if (ret)
+			goto exit;
+	}
+
+	ret = clk_set_rate(clk, freq);
+	if (ret)
+		goto exit;
+
+exit:
+	return ret;
+}
+
+static int krait_cache_notifier(struct notifier_block *nb, unsigned long cmd,
+				void *v)
+{
+	unsigned int target_freq, cpu, cur_cpu;
+	unsigned int *freq_tbl, *freq_l2tbl;
+	struct cpufreq_freqs *freqs;
+	struct krait_data *data;
+	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);
+
+		freq_tbl = data->l2_cpufreq;
+		freq_l2tbl = data->l2_rates;
+
+		/* 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));
+
+		while (*(freq_tbl = freq_tbl + 1) && target_freq >= *freq_tbl)
+			freq_l2tbl = freq_l2tbl + 1;
+
+		ret = dev_pm_opp_set_rate(data->dev, *freq_l2tbl);
+		if (ret)
+			goto exit;
+	}
+
+exit:
+	return notifier_from_errno(ret);
+}
+
+static int krait_cache_probe(struct platform_device *pdev)
+{
+	struct clk *l2_clk;
+	int ret, i = 0, count;
+	unsigned long freq = 0;
+	struct dev_pm_opp *opp;
+	struct opp_table *table;
+	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->dev = dev;
+
+	l2_clk = devm_clk_get(dev, "l2");
+	if (IS_ERR(l2_clk)) {
+		ret = PTR_ERR(l2_clk);
+		goto exit;
+	}
+
+	vdd = of_parse_phandle(node, "l2-supply", 0);
+	if (!vdd) {
+		dev_err(dev, "missing L2 supply\n");
+		ret = -EINVAL;
+		goto exit;
+	}
+
+	table = dev_pm_opp_set_regulators(dev, (const char *[]){ vdd->name },
+					  1);
+	if (IS_ERR(table)) {
+		ret = PTR_ERR(table);
+		dev_err(dev, "failed to set regulators %d\n", ret);
+		goto exit_vdd;
+	}
+
+	dev_pm_opp_put(opp);
+
+	ret = PTR_ERR_OR_ZERO(
+		dev_pm_opp_register_set_opp_helper(dev, krait_cache_set_opp));
+	if (ret)
+		goto exit_vdd;
+
+	ret = dev_pm_opp_of_add_table(dev);
+	if (ret) {
+		dev_err(dev, "failed to parse L2 freq thresholds\n");
+		goto exit_vdd;
+	}
+
+	count = dev_pm_opp_get_opp_count(dev);
+
+	data->l2_cpufreq =
+		devm_kzalloc(dev, sizeof(unsigned int) * count, GFP_KERNEL);
+	if (!data->l2_cpufreq) {
+		ret = -ENOMEM;
+		goto exit_vdd;
+	}
+
+	ret = of_property_read_u32_array(node, "l2-cpufreq", data->l2_cpufreq,
+					 count);
+	if (ret) {
+		dev_err(dev, "failed to parse L2 cpufreq thresholds\n");
+		goto exit_vdd;
+	}
+
+	/* Allocate space for opp_count + 1, the last index is used as sentinel */
+	data->l2_rates =
+		devm_kzalloc(dev, sizeof(unsigned int) * count + 1, GFP_KERNEL);
+	if (!data->l2_rates) {
+		ret = -ENOMEM;
+		goto exit_vdd;
+	}
+
+	/* populate the table in increasing order */
+	while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) {
+		data->l2_rates[i] = freq;
+		freq++;
+		i++;
+		dev_pm_opp_put(opp);
+	}
+
+	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);
+
+	dev_pm_opp_remove_table(data->dev);
+	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 v3 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   | 79 +++++++++++++++++++
 1 file changed, 79 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..f5f1c9b76656
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
@@ -0,0 +1,79 @@
+# 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 thresholds can be set to 3+ frequency bin, idle, nominal and
+  high.
+
+properties:
+  compatible:
+    const: qcom,krait-cache
+
+  clocks:
+    $ref: "/schemas/types.yaml#/definitions/phandle"
+    description: Phandle to the L2 CPU clock
+
+  clock-names:
+    const: "l2"
+
+  voltage-tolerance:
+    description: Same voltage tollerance of the Krait CPU
+
+  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
+    minItems: 3
+    items:
+      - description: idle
+      - description: nominal
+      - description: high
+
+  l2-supply:
+    $ref: "/schemas/types.yaml#/definitions/phandle"
+    description: Phandle to the L2 regulator supply.
+
+  opp-table: true
+
+required:
+  - compatible
+  - clocks
+  - clock-names
+  - voltage-tolerance
+  - l2-cpufreq
+  - l2-supply
+
+examples:
+  - |
+    qcom-krait-cache {
+      compatible = "qcom,krait-cache";
+      clocks = <&kraitcc 4>;
+      clock-names = "l2";
+      voltage-tolerance = <5>;
+      l2-cpufreq = <384000 600000 1200000>;
+      l2-supply = <&smb208_s1a>;
+
+      operating-points = <
+        /* kHz    uV */
+        384000  1100000
+        1000000  1100000
+        1200000  1150000
+      >;
+    };
-- 
2.27.0

Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[Viresh Kumar]

+Vincent/Saravana/Sibi

On 21-08-20, 16:00, Ansuel Smith wrote:
> 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.

Saravana was doing something with devfreq to solve such issues if I
wasn't mistaken.

Sibi ?

-- 
viresh

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

[Rob Herring]

On Fri, 21 Aug 2020 16:00:21 +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   | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.example.dt.yaml: qcom-krait-cache: clocks:0:1: missing phandle tag in 4
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.example.dt.yaml: qcom-krait-cache: clocks:0: [4294967295, 4] is too long
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml


See https://patchwork.ozlabs.org/patch/1349260

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.

Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[Sibi Sankar]

On 2020-08-24 16:10, Viresh Kumar wrote:
> +Vincent/Saravana/Sibi
> 
> On 21-08-20, 16:00, Ansuel Smith wrote:
>> 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.
> 
> Saravana was doing something with devfreq to solve such issues if I
> wasn't mistaken.
> 
> Sibi ?

IIRC the final plan was to create a devfreq device
and devfreq-cpufreq based governor to scale them, this
way one can switch to a different governor if required.
(I don't see if ^^ applies well for l2 though). In the
interim until such a solution is acked on the list we
just scale the resources directly from the cpufreq
driver. On SDM845/SC7180 SoCs, L3 is modeled as a
interconnect provider and is directly scaled from the
cpufreq-hw driver.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[ansuelsmth]

> -----Messaggio originale-----
> Da: sibis=codeaurora.org@mg.codeaurora.org
> <sibis=codeaurora.org@mg.codeaurora.org> Per conto di Sibi Sankar
> Inviato: lunedì 31 agosto 2020 07:46
> A: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Ansuel Smith <ansuelsmth@gmail.com>; vincent.guittot@linaro.org;
> saravanak@google.com; Sudeep Holla <sudeep.holla@arm.com>; 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 v3 0/2] Add Krait Cache Scaling support
> 
> On 2020-08-24 16:10, Viresh Kumar wrote:
> > +Vincent/Saravana/Sibi
> >
> > On 21-08-20, 16:00, Ansuel Smith wrote:
> >> 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.
> >
> > Saravana was doing something with devfreq to solve such issues if I
> > wasn't mistaken.
> >
> > Sibi ?
> 
> IIRC the final plan was to create a devfreq device
> and devfreq-cpufreq based governor to scale them, this
> way one can switch to a different governor if required.

So in this case I should convert this patch to a devfreq driver- 
Isn't overkill to use a governor for such a task?
(3 range based on the cpufreq?)

> (I don't see if ^^ applies well for l2 though). In the
> interim until such a solution is acked on the list we
> just scale the resources directly from the cpufreq

In this case for this SoC we can't really scale the L2 freq
with the cpu since we observed a bug and we need to switch
back to the idle freq sometimes. Also this SoC use the generic
cpufreq-dt driver and doesn't have a dedicated driver. So we
must use a notifier.

> driver. On SDM845/SC7180 SoCs, L3 is modeled as a
> interconnect provider and is directly scaled from the
> cpufreq-hw driver.
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project.

Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[Viresh Kumar]

On 31-08-20, 09:41, ansuelsmth@gmail.com wrote:
> On 31-08-20, Sibi wrote:
> > On 2020-08-24 16:10, Viresh Kumar wrote:
> > > +Vincent/Saravana/Sibi
> > >
> > > On 21-08-20, 16:00, Ansuel Smith wrote:
> > >> 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.
> > >
> > > Saravana was doing something with devfreq to solve such issues if I
> > > wasn't mistaken.
> > >
> > > Sibi ?
> > 
> > IIRC the final plan was to create a devfreq device
> > and devfreq-cpufreq based governor to scale them, this
> > way one can switch to a different governor if required.
> 
> So in this case I should convert this patch to a devfreq driver- 

I think this should happen nevertheless. You are doing DVFS for a
device which isn't a CPU and devfreq looks to be the right place of
doing so.

> Isn't overkill to use a governor for such a task?
> (3 range based on the cpufreq?)

I am not sure about the governor part here, maybe it won't be required
?

-- 
viresh

Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[Sibi Sankar]

On 2020-09-03 12:23, Viresh Kumar wrote:
> On 31-08-20, 09:41, ansuelsmth@gmail.com wrote:
>> On 31-08-20, Sibi wrote:
>> > On 2020-08-24 16:10, Viresh Kumar wrote:
>> > > +Vincent/Saravana/Sibi
>> > >
>> > > On 21-08-20, 16:00, Ansuel Smith wrote:
>> > >> 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.
>> > >
>> > > Saravana was doing something with devfreq to solve such issues if I
>> > > wasn't mistaken.
>> > >
>> > > Sibi ?
>> >
>> > IIRC the final plan was to create a devfreq device
>> > and devfreq-cpufreq based governor to scale them, this
>> > way one can switch to a different governor if required.
>> 
>> So in this case I should convert this patch to a devfreq driver-
> 
> I think this should happen nevertheless. You are doing DVFS for a
> device which isn't a CPU and devfreq looks to be the right place of
> doing so.
> 
>> Isn't overkill to use a governor for such a task?
>> (3 range based on the cpufreq?)
> 
> I am not sure about the governor part here, maybe it won't be required
> ?

Yeah I don't see it being needed in ^^
case as well. I just mentioned them as
an advantage in case you wanted to switch
to a different governor in the future.

https://lore.kernel.org/lkml/d0bc8877-6d41-f54e-1c4c-2fadbb9dcd0b@samsung.com/

A devfreq governor tracking cpufreq was
generally accepted but using a cpufreq
notifier to achieve that was discouraged.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

R: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

[ansuelsmth]

> -----Messaggio originale-----
> Da: sibis=codeaurora.org@mg.codeaurora.org
> <sibis=codeaurora.org@mg.codeaurora.org> Per conto di Sibi Sankar
> Inviato: giovedì 3 settembre 2020 09:13
> A: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: ansuelsmth@gmail.com; vincent.guittot@linaro.org;
> saravanak@google.com; 'Sudeep Holla' <sudeep.holla@arm.com>; '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 v3 0/2] Add Krait Cache Scaling support
> 
> On 2020-09-03 12:23, Viresh Kumar wrote:
> > On 31-08-20, 09:41, ansuelsmth@gmail.com wrote:
> >> On 31-08-20, Sibi wrote:
> >> > On 2020-08-24 16:10, Viresh Kumar wrote:
> >> > > +Vincent/Saravana/Sibi
> >> > >
> >> > > On 21-08-20, 16:00, Ansuel Smith wrote:
> >> > >> 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.
> >> > >
> >> > > Saravana was doing something with devfreq to solve such issues if I
> >> > > wasn't mistaken.
> >> > >
> >> > > Sibi ?
> >> >
> >> > IIRC the final plan was to create a devfreq device
> >> > and devfreq-cpufreq based governor to scale them, this
> >> > way one can switch to a different governor if required.
> >>
> >> So in this case I should convert this patch to a devfreq driver-
> >
> > I think this should happen nevertheless. You are doing DVFS for a
> > device which isn't a CPU and devfreq looks to be the right place of
> > doing so.
> >
> >> Isn't overkill to use a governor for such a task?
> >> (3 range based on the cpufreq?)
> >
> > I am not sure about the governor part here, maybe it won't be required
> > ?
> 
> Yeah I don't see it being needed in ^^
> case as well. I just mentioned them as
> an advantage in case you wanted to switch
> to a different governor in the future.
> 
> https://lore.kernel.org/lkml/d0bc8877-6d41-f54e-1c4c-
> 2fadbb9dcd0b@samsung.com/
> 
> A devfreq governor tracking cpufreq was
> generally accepted but using a cpufreq
> notifier to achieve that was discouraged.
> 

I read the patch discussion and it looks like at the very end they
lost interest in pushing it. That would very fit what I need here so
I'm asking how should I proceed? Keep the cpufreq notifier?
Introduce a dedicated governor? Ask them to resume the pushing or
try to include the changes to the passive governor by myself? 

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project.