* [RFC PATCH v3 0/2] Add Krait Cache Scaling support
@ 2020-08-21 14:00 Ansuel Smith
2020-08-21 14:00 ` [RFC PATCH v3 1/2] cpufreq: qcom: " Ansuel Smith
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Ansuel Smith @ 2020-08-21 14:00 UTC (permalink / raw)
To: Sudeep Holla
Cc: Ansuel Smith, Rafael J. Wysocki, Viresh Kumar, Rob Herring,
linux-pm, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [RFC PATCH v3 1/2] cpufreq: qcom: Add Krait Cache Scaling support 2020-08-21 14:00 [RFC PATCH v3 0/2] Add Krait Cache Scaling support Ansuel Smith @ 2020-08-21 14:00 ` Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling Ansuel Smith 2020-08-24 10:40 ` [RFC PATCH v3 0/2] Add Krait Cache Scaling support Viresh Kumar 2 siblings, 0 replies; 10+ messages in thread From: Ansuel Smith @ 2020-08-21 14:00 UTC (permalink / raw) To: Sudeep Holla Cc: Ansuel Smith, Rafael J. Wysocki, Viresh Kumar, Rob Herring, linux-pm, devicetree, linux-kernel 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling 2020-08-21 14:00 [RFC PATCH v3 0/2] Add Krait Cache Scaling support Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 1/2] cpufreq: qcom: " Ansuel Smith @ 2020-08-21 14:00 ` Ansuel Smith 2020-08-24 17:28 ` Rob Herring 2020-08-24 10:40 ` [RFC PATCH v3 0/2] Add Krait Cache Scaling support Viresh Kumar 2 siblings, 1 reply; 10+ messages in thread From: Ansuel Smith @ 2020-08-21 14:00 UTC (permalink / raw) To: Sudeep Holla Cc: Ansuel Smith, Rafael J. Wysocki, Viresh Kumar, Rob Herring, linux-pm, devicetree, linux-kernel 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling 2020-08-21 14:00 ` [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling Ansuel Smith @ 2020-08-24 17:28 ` Rob Herring 0 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2020-08-24 17:28 UTC (permalink / raw) To: Ansuel Smith Cc: Sudeep Holla, linux-kernel, Rafael J. Wysocki, Rob Herring, linux-pm, devicetree, Viresh Kumar 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-08-21 14:00 [RFC PATCH v3 0/2] Add Krait Cache Scaling support Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 1/2] cpufreq: qcom: " Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling Ansuel Smith @ 2020-08-24 10:40 ` Viresh Kumar 2020-08-31 5:45 ` Sibi Sankar 2 siblings, 1 reply; 10+ messages in thread From: Viresh Kumar @ 2020-08-24 10:40 UTC (permalink / raw) To: Ansuel Smith, vincent.guittot, saravanak, sibis Cc: Sudeep Holla, Rafael J. Wysocki, Rob Herring, linux-pm, devicetree, linux-kernel +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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-08-24 10:40 ` [RFC PATCH v3 0/2] Add Krait Cache Scaling support Viresh Kumar @ 2020-08-31 5:45 ` Sibi Sankar 2020-08-31 7:41 ` R: " ansuelsmth 0 siblings, 1 reply; 10+ messages in thread From: Sibi Sankar @ 2020-08-31 5:45 UTC (permalink / raw) To: Viresh Kumar Cc: Ansuel Smith, vincent.guittot, saravanak, Sudeep Holla, Rafael J. Wysocki, Rob Herring, linux-pm, devicetree, linux-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-08-31 5:45 ` Sibi Sankar @ 2020-08-31 7:41 ` ansuelsmth 2020-09-03 6:53 ` Viresh Kumar 0 siblings, 1 reply; 10+ messages in thread From: ansuelsmth @ 2020-08-31 7:41 UTC (permalink / raw) To: 'Sibi Sankar', 'Viresh Kumar' Cc: vincent.guittot, saravanak, 'Sudeep Holla', 'Rafael J. Wysocki', 'Rob Herring', linux-pm, devicetree, linux-kernel > -----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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-08-31 7:41 ` R: " ansuelsmth @ 2020-09-03 6:53 ` Viresh Kumar 2020-09-03 7:13 ` Sibi Sankar 0 siblings, 1 reply; 10+ messages in thread From: Viresh Kumar @ 2020-09-03 6:53 UTC (permalink / raw) To: ansuelsmth Cc: 'Sibi Sankar', vincent.guittot, saravanak, 'Sudeep Holla', 'Rafael J. Wysocki', 'Rob Herring', linux-pm, devicetree, linux-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-09-03 6:53 ` Viresh Kumar @ 2020-09-03 7:13 ` Sibi Sankar 2020-09-03 11:00 ` R: " ansuelsmth 0 siblings, 1 reply; 10+ messages in thread From: Sibi Sankar @ 2020-09-03 7:13 UTC (permalink / raw) To: Viresh Kumar Cc: ansuelsmth, vincent.guittot, saravanak, 'Sudeep Holla', 'Rafael J. Wysocki', 'Rob Herring', linux-pm, devicetree, linux-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* R: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support 2020-09-03 7:13 ` Sibi Sankar @ 2020-09-03 11:00 ` ansuelsmth 0 siblings, 0 replies; 10+ messages in thread From: ansuelsmth @ 2020-09-03 11:00 UTC (permalink / raw) To: 'Sibi Sankar', 'Viresh Kumar' Cc: vincent.guittot, saravanak, 'Sudeep Holla', 'Rafael J. Wysocki', 'Rob Herring', linux-pm, devicetree, linux-kernel > -----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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-09-03 11:15 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-21 14:00 [RFC PATCH v3 0/2] Add Krait Cache Scaling support Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 1/2] cpufreq: qcom: " Ansuel Smith 2020-08-21 14:00 ` [RFC PATCH v3 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling Ansuel Smith 2020-08-24 17:28 ` Rob Herring 2020-08-24 10:40 ` [RFC PATCH v3 0/2] Add Krait Cache Scaling support Viresh Kumar 2020-08-31 5:45 ` Sibi Sankar 2020-08-31 7:41 ` R: " ansuelsmth 2020-09-03 6:53 ` Viresh Kumar 2020-09-03 7:13 ` Sibi Sankar 2020-09-03 11:00 ` R: " ansuelsmth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).