* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support [not found] ` <20200520034307.20435-1-andrew-sh.cheng@mediatek.com> @ 2020-05-20 4:10 ` Chanwoo Choi [not found] ` <1589953015.8243.2.camel@mtksdaap41> [not found] ` <20200520034307.20435-10-andrew-sh.cheng@mediatek.com> ` (4 subsequent siblings) 5 siblings, 1 reply; 15+ messages in thread From: Chanwoo Choi @ 2020-05-20 4:10 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream Hi Andrew, Could you explain the base commit of these patches? When I tried to apply them to v5.7-rc1 for testing, the merge conflict occurs. Thanks, Chanwoo Choi On 5/20/20 12:42 PM, Andrew-sh.Cheng wrote: > MT8183 supports CPU DVFS and CCI DVFS, and LITTLE cpus and CCI are in the same voltage domain. > So, this series is to add drivers to handle the voltage coupling between CPU and CCI DVFS. > > For SVS support, need OPP_EVENT_ADJUST_VOLTAGE and corresponding reaction. > > Change since v5: > - Changing dt-binding format to yaml. > - Extending current devfreq passive_governor instead of create a new one. > - Resend depending patches of Sravana Kannan base on kernel-5.7 > > > Andrew-sh.Cheng (6): > cpufreq: mediatek: add clock and regulator enable for intermediate > clock > dt-bindings: devfreq: add compatible for mt8183 cci devfreq > devfreq: add mediatek cci devfreq > opp: Modify opp API, dev_pm_opp_get_freq(), find freq in opp, even it > is disabled > cpufreq: mediatek: add opp notification for SVS support > devfreq: mediatek: cci devfreq register opp notification for SVS > support > > Saravana Kannan (6): > OPP: Allow required-opps even if the device doesn't have power-domains > OPP: Add function to look up required OPP's for a given OPP > OPP: Improve required-opps linking > PM / devfreq: Cache OPP table reference in devfreq > PM / devfreq: Add required OPPs support to passive governor > PM / devfreq: Add cpu based scaling support to passive_governor > > .../devicetree/bindings/devfreq/mt8183-cci.yaml | 51 ++++ > drivers/cpufreq/mediatek-cpufreq.c | 122 ++++++++- > drivers/devfreq/Kconfig | 12 + > drivers/devfreq/Makefile | 1 + > drivers/devfreq/devfreq.c | 6 + > drivers/devfreq/governor_passive.c | 298 +++++++++++++++++++-- > drivers/devfreq/mt8183-cci-devfreq.c | 233 ++++++++++++++++ > drivers/opp/core.c | 85 +++++- > drivers/opp/of.c | 108 ++++---- > drivers/opp/opp.h | 5 + > include/linux/devfreq.h | 42 ++- > include/linux/pm_opp.h | 11 + > 12 files changed, 874 insertions(+), 100 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml > create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c > ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <1589953015.8243.2.camel@mtksdaap41>]
* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support [not found] ` <1589953015.8243.2.camel@mtksdaap41> @ 2020-05-20 6:24 ` Chanwoo Choi [not found] ` <1589958625.23971.2.camel@mtksdaap41> 0 siblings, 1 reply; 15+ messages in thread From: Chanwoo Choi @ 2020-05-20 6:24 UTC (permalink / raw) To: andrew-sh.cheng Cc: MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream Hi, On 5/20/20 2:36 PM, andrew-sh.cheng wrote: > On Wed, 2020-05-20 at 13:10 +0900, Chanwoo Choi wrote: >> Hi Andrew, >> >> Could you explain the base commit of these patches? >> When I tried to apply them to v5.7-rc1 for testing, >> the merge conflict occurs. >> >> Thanks, >> Chanwoo Choi > > Hi Chanwoo Choi, > > My base commit is > commit 8f3d9f354286745c751374f5f1fcafee6b3f3136 > Author: Linus Torvalds <torvalds@linux-foundation.org> > Date: Sun Apr 12 12:35:55 2020 -0700 > > Linux 5.7-rc1 > > Could you show me the conflict error? When I tried to apply first patch with 'git am', the merge conflict occurred. git am \[PATCH\ 01_12\]\ OPP\:\ Allow\ required-opps\ even\ if\ the\ device\ doesn\'t\ have\ power-domains.eml Applying: OPP: Allow required-opps even if the device doesn't have power-domains error: patch failed: drivers/opp/core.c:755 error: drivers/opp/core.c: patch does not apply error: patch failed: drivers/opp/of.c:195 error: drivers/opp/of.c: patch does not apply Patch failed at 0001 OPP: Allow required-opps even if the device doesn't have power-domains Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Regards, Chanwoo Choi > > BR, > Andrew-sh.Cheng >> >> On 5/20/20 12:42 PM, Andrew-sh.Cheng wrote: >>> MT8183 supports CPU DVFS and CCI DVFS, and LITTLE cpus and CCI are in the same voltage domain. >>> So, this series is to add drivers to handle the voltage coupling between CPU and CCI DVFS. >>> >>> For SVS support, need OPP_EVENT_ADJUST_VOLTAGE and corresponding reaction. >>> >>> Change since v5: >>> - Changing dt-binding format to yaml. >>> - Extending current devfreq passive_governor instead of create a new one. >>> - Resend depending patches of Sravana Kannan base on kernel-5.7 >>> >>> >>> Andrew-sh.Cheng (6): >>> cpufreq: mediatek: add clock and regulator enable for intermediate >>> clock >>> dt-bindings: devfreq: add compatible for mt8183 cci devfreq >>> devfreq: add mediatek cci devfreq >>> opp: Modify opp API, dev_pm_opp_get_freq(), find freq in opp, even it >>> is disabled >>> cpufreq: mediatek: add opp notification for SVS support >>> devfreq: mediatek: cci devfreq register opp notification for SVS >>> support >>> >>> Saravana Kannan (6): >>> OPP: Allow required-opps even if the device doesn't have power-domains >>> OPP: Add function to look up required OPP's for a given OPP >>> OPP: Improve required-opps linking >>> PM / devfreq: Cache OPP table reference in devfreq >>> PM / devfreq: Add required OPPs support to passive governor >>> PM / devfreq: Add cpu based scaling support to passive_governor >>> >>> .../devicetree/bindings/devfreq/mt8183-cci.yaml | 51 ++++ >>> drivers/cpufreq/mediatek-cpufreq.c | 122 ++++++++- >>> drivers/devfreq/Kconfig | 12 + >>> drivers/devfreq/Makefile | 1 + >>> drivers/devfreq/devfreq.c | 6 + >>> drivers/devfreq/governor_passive.c | 298 +++++++++++++++++++-- >>> drivers/devfreq/mt8183-cci-devfreq.c | 233 ++++++++++++++++ >>> drivers/opp/core.c | 85 +++++- >>> drivers/opp/of.c | 108 ++++---- >>> drivers/opp/opp.h | 5 + >>> include/linux/devfreq.h | 42 ++- >>> include/linux/pm_opp.h | 11 + >>> 12 files changed, 874 insertions(+), 100 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml >>> create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c >>> > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <1589958625.23971.2.camel@mtksdaap41>]
* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support [not found] ` <1589958625.23971.2.camel@mtksdaap41> @ 2020-05-20 14:53 ` Matthias Brugger 0 siblings, 0 replies; 15+ messages in thread From: Matthias Brugger @ 2020-05-20 14:53 UTC (permalink / raw) To: andrew-sh.cheng, Chanwoo Choi Cc: MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream On 20/05/2020 09:10, andrew-sh.cheng wrote: > On Wed, 2020-05-20 at 15:24 +0900, Chanwoo Choi wrote: >> Hi, >> >> On 5/20/20 2:36 PM, andrew-sh.cheng wrote: >>> On Wed, 2020-05-20 at 13:10 +0900, Chanwoo Choi wrote: >>>> Hi Andrew, >>>> >>>> Could you explain the base commit of these patches? >>>> When I tried to apply them to v5.7-rc1 for testing, >>>> the merge conflict occurs. >>>> >>>> Thanks, >> >>>> Chanwoo Choi >>> >>> Hi Chanwoo Choi, >>> >>> My base commit is >>> commit 8f3d9f354286745c751374f5f1fcafee6b3f3136 >>> Author: Linus Torvalds <torvalds@linux-foundation.org> >>> Date: Sun Apr 12 12:35:55 2020 -0700 >>> >>> Linux 5.7-rc1 >>> >>> Could you show me the conflict error? >> >> >> When I tried to apply first patch with 'git am', >> the merge conflict occurred. >> >> git am \[PATCH\ 01_12\]\ OPP\:\ Allow\ required-opps\ even\ if\ the\ device\ doesn\'t\ have\ power-domains.eml >> Applying: OPP: Allow required-opps even if the device doesn't have power-domains >> error: patch failed: drivers/opp/core.c:755 >> error: drivers/opp/core.c: patch does not apply >> error: patch failed: drivers/opp/of.c:195 >> error: drivers/opp/of.c: patch does not apply >> Patch failed at 0001 OPP: Allow required-opps even if the device doesn't have power-domains >> Use 'git am --show-current-patch' to see the failed patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> >> Regards, >> Chanwoo Choi > > Hi Chanwoo, > > I just make a new folder to get code and check. > Below is my command list. > Please help check the different with you. > 505 repo init -u http://gerrit.mediatek.inc:8080/cros-kernel/manifest > -b upstream > 506 repo sync -j8 > 507 repo start kern-dev --all > 508 git remote add main > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > 509 git remote add main > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > 510 ls > 511 cd kernel/mediatek/ > 512 git remote add main > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > 513 git fetch main > 514 git checkout v5.7-rc1 > 515 git am > Add-cpufreq-and-cci-devfreq-for-mt8183-and-SVS-support.patch > 516 history > For reference I just tried with b4.sh [1]: # b4.sh am -l -o /tmp -n patch 1589958625.23971.2.camel@mtksdaap41 # git am -3 -s /tmp/patch.mbx Applies without conflicts. Regards, Matthias [1] https://git.kernel.org/pub/scm/utils/b4/b4.git ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200520034307.20435-10-andrew-sh.cheng@mediatek.com>]
* Re: [PATCH 09/12] devfreq: add mediatek cci devfreq [not found] ` <20200520034307.20435-10-andrew-sh.cheng@mediatek.com> @ 2020-05-20 12:31 ` Mark Brown 2020-05-21 8:52 ` andrew-sh.cheng 2020-05-28 7:35 ` Chanwoo Choi 1 sibling, 1 reply; 15+ messages in thread From: Mark Brown @ 2020-05-20 12:31 UTC (permalink / raw) To: Andrew-sh.Cheng Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream [-- Attachment #1: Type: text/plain, Size: 502 bytes --] On Wed, May 20, 2020 at 11:43:04AM +0800, Andrew-sh.Cheng wrote: > + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc"); > + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg); > + if (ret) { > + if (ret != -EPROBE_DEFER) > + dev_err(cci_dev, "failed to get regulator for CCI: %d\n", > + ret); > + return ret; > + } > + ret = regulator_enable(cci_df->proc_reg); The code appears to require a regulator (and I'm guessing the device needs power) so why is this using regulator_get_optional()? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 09/12] devfreq: add mediatek cci devfreq 2020-05-20 12:31 ` [PATCH 09/12] devfreq: add mediatek cci devfreq Mark Brown @ 2020-05-21 8:52 ` andrew-sh.cheng 0 siblings, 0 replies; 15+ messages in thread From: andrew-sh.cheng @ 2020-05-21 8:52 UTC (permalink / raw) Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream On Wed, 2020-05-20 at 13:31 +0100, Mark Brown wrote: > On Wed, May 20, 2020 at 11:43:04AM +0800, Andrew-sh.Cheng wrote: > > > + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc"); > > + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg); > > + if (ret) { > > + if (ret != -EPROBE_DEFER) > > + dev_err(cci_dev, "failed to get regulator for CCI: %d\n", > > + ret); > > + return ret; > > + } > > + ret = regulator_enable(cci_df->proc_reg); > > The code appears to require a regulator (and I'm guessing the device > needs power) so why is this using regulator_get_optional()? Hi Mark, Do you mean, why not use regulator_get_exclusive() or regulator_get()? Because cci and cpu litter core shared buck, it cannot use regulator_get_exclusive(). Because both cci and cpu want to tune voltage, it cannot use regulator_get(), otherwise it will get dummy regulator even this buck doesn't register.as regulator. BR, Andrew-sh.Cheng ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 09/12] devfreq: add mediatek cci devfreq [not found] ` <20200520034307.20435-10-andrew-sh.cheng@mediatek.com> 2020-05-20 12:31 ` [PATCH 09/12] devfreq: add mediatek cci devfreq Mark Brown @ 2020-05-28 7:35 ` Chanwoo Choi 2020-05-28 8:00 ` Chanwoo Choi 1 sibling, 1 reply; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 7:35 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream Hi Andrew-sh.Cheng, On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: > This adds a devfreq driver for the Cache Coherent Interconnect (CCI) > of the Mediatek MT8183. > > On the MT8183 the CCI is supplied by the same regulator as the LITTLE > cores. The driver is notified when the regulator voltage changes > (driven by cpufreq) and adjusts the CCI frequency to the maximum > possible value. > > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > drivers/devfreq/Kconfig | 10 ++ > drivers/devfreq/Makefile | 1 + > drivers/devfreq/mt8183-cci-devfreq.c | 206 +++++++++++++++++++++++++++++++++++ The mt8183-cci.c is enough for driver name. > 3 files changed, 217 insertions(+) > create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index d9067950af6a..4ed7116271ee 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -103,6 +103,16 @@ config ARM_IMX8M_DDRC_DEVFREQ > This adds the DEVFREQ driver for the i.MX8M DDR Controller. It allows > adjusting DRAM frequency. > > +config ARM_MT8183_CCI_DEVFREQ > + tristate "MT8183 CCI DEVFREQ Driver" > + depends on ARM_MEDIATEK_CPUFREQ > + help > + This adds a devfreq driver for Cache Coherent Interconnect > + of Mediatek MT8183, which is shared the same regulator > + with cpu cluster. > + It can track buck voltage and update a proper cci frequency. s/cci/CCI > + Use notification to get regulator status. > + > config ARM_TEGRA_DEVFREQ > tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver" > depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \ > diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile > index 3eb4d5e6635c..5b1b670c954d 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -10,6 +10,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o > # DEVFREQ Drivers > obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o > obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o > +obj-$(CONFIG_ARM_MT8183_CCI_DEVFREQ) += mt8183-cci-devfreq.o > obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o > obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o > obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o > diff --git a/drivers/devfreq/mt8183-cci-devfreq.c b/drivers/devfreq/mt8183-cci-devfreq.c > new file mode 100644 > index 000000000000..cd7929a83bf8 > --- /dev/null > +++ b/drivers/devfreq/mt8183-cci-devfreq.c > @@ -0,0 +1,206 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. s/2019/2020 > + > + * Author: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > + */ > + > +#include <linux/clk.h> > +#include <linux/devfreq.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/regulator/consumer.h> > +#include <linux/time.h> > + > +#include "governor.h" It is not needed. Please remove it. > + > +#define MAX_VOLT_LIMIT (1150000) > + > +struct cci_devfreq { > + struct devfreq *devfreq; > + struct regulator *proc_reg; 'proc' means the 'processor'? Instead of 'proc_reg', you better to use 'cpu_reg'. > + struct clk *cci_clk; > + int old_vproc; > + unsigned long old_freq; > +}; > + > +static int mtk_cci_set_voltage(struct cci_devfreq *cci_df, int vproc) > +{ > + int ret; > + > + ret = regulator_set_voltage(cci_df->proc_reg, vproc, > + MAX_VOLT_LIMIT); > + if (!ret) > + cci_df->old_vproc = vproc; > + return ret; > +} > + > +static int mtk_cci_devfreq_target(struct device *dev, unsigned long *freq, > + u32 flags) > +{ > + int ret; > + struct cci_devfreq *cci_df = dev_get_drvdata(dev); > + struct dev_pm_opp *opp; > + unsigned long opp_rate, opp_voltage, old_voltage; > + > + if (!cci_df) > + return -EINVAL; > + > + if (cci_df->old_freq == *freq) > + return 0; > + > + opp_rate = *freq; > + opp = dev_pm_opp_find_freq_floor(dev, &opp_rate); > + opp_voltage = dev_pm_opp_get_voltage(opp); > + dev_pm_opp_put(opp); You can use the helper function for getting the rate with devfreq_recommended_opp(). You can refer the following code in drivers/devfreq/exynos-bus.c opp = devfreq_recommended_opp(dev, freq, flags); if (IS_ERR(opp)) { dev_err(dev, "failed to get recommended opp instance\n"); return PTR_ERR(opp); } dev_pm_opp_put(opp); > + > + old_voltage = cci_df->old_vproc; > + if (old_voltage == 0) > + old_voltage = regulator_get_voltage(cci_df->proc_reg); > + > + // scale up: set voltage first then freq > + if (opp_voltage > old_voltage) { > + ret = mtk_cci_set_voltage(cci_df, opp_voltage); > + if (ret) { > + pr_err("cci: failed to scale up voltage\n"); > + return ret; > + } > + } > + > + ret = clk_set_rate(cci_df->cci_clk, *freq); > + if (ret) { > + pr_err("%s: failed cci to set rate: %d\n", __func__, > + ret); > + mtk_cci_set_voltage(cci_df, old_voltage); > + return ret; > + } > + > + // scale down: set freq first then voltage > + if (opp_voltage < old_voltage) { > + ret = mtk_cci_set_voltage(cci_df, opp_voltage); > + if (ret) { > + pr_err("cci: failed to scale down voltage\n"); > + clk_set_rate(cci_df->cci_clk, cci_df->old_freq); > + return ret; > + } > + } I recommend that dev_pm_opp_set_rate() and dev_pm_opp_set_regulator() instead of 'clk_set_rate' and 'regulator_set_voltage'. In the dev_pm_opp_set_rate(), handle the these sequence. You can refer the merged patch[1]. [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68 - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate() > + > + cci_df->old_freq = *freq; > + > + return 0; > +} > + > +static struct devfreq_dev_profile cci_devfreq_profile = { > + .target = mtk_cci_devfreq_target, Need to add '.exit' for calling dev_pm_opp_of_remove_table(). You can refer the merged devfreq patches like exynos_bus.c, imx-bus.c. > +}; > + > +static int mtk_cci_devfreq_probe(struct platform_device *pdev) > +{ > + struct device *cci_dev = &pdev->dev; > + struct cci_devfreq *cci_df; > + struct devfreq_passive_data *passive_data; > + int ret; > + > + cci_df = devm_kzalloc(cci_dev, sizeof(*cci_df), GFP_KERNEL); > + if (!cci_df) > + return -ENOMEM; > + > + cci_df->cci_clk = devm_clk_get(cci_dev, "cci_clock"); > + ret = PTR_ERR_OR_ZERO(cci_df->cci_clk); > + if (ret) { > + if (ret != -EPROBE_DEFER) > + dev_err(cci_dev, "failed to get clock for CCI: %d\n", > + ret); > + return ret; > + } > + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc"); > + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg); > + if (ret) { > + if (ret != -EPROBE_DEFER) > + dev_err(cci_dev, "failed to get regulator for CCI: %d\n", > + ret); > + return ret; > + } I recommend that use dev_pm_opp_set_regulators. You can refer the merged patch[1]. [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68 - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate() > + ret = regulator_enable(cci_df->proc_reg); > + if (ret) { > + pr_warn("enable buck for cci fail\n"); Use dev_err instead of 'pr_warn'. > + return ret; > + } > + > + ret = dev_pm_opp_of_add_table(cci_dev); > + if (ret) { > + dev_err(cci_dev, "Fail to init CCI OPP table: %d\n", ret); How about changing the error log as following because in this driver, use the 'failed to' sentence for error handling? failed to get OPP table for CCI:L %d > + return ret; > + } > + > + platform_set_drvdata(pdev, cci_df); > + > + passive_data = devm_kzalloc(cci_dev, sizeof(*passive_data), GFP_KERNEL); > + if (!passive_data) > + return -ENOMEM; On this error case, you have to call dev_pm_opp_of_remove_table(). You better to make the 'err_opp' jump lable and then add 'goto err_opp'. > + > + passive_data->parent_type = CPUFREQ_PARENT_DEV; > + > + cci_df->devfreq = devm_devfreq_add_device(cci_dev, > + &cci_devfreq_profile, > + DEVFREQ_GOV_PASSIVE, > + passive_data); > + if (IS_ERR(cci_df->devfreq)) { > + ret = PTR_ERR(cci_df->devfreq); > + dev_err(cci_dev, "cannot create cci devfreq device:%d\n", ret); > + dev_pm_opp_of_remove_table(cci_dev); Instead of direct call, use 'goto err_opp'. > + return ret; > + } > + > + return 0; > +} > + > +static int mtk_cci_devfreq_remove(struct platform_device *pdev) > +{ > + struct device *cci_dev = &pdev->dev; > + struct cci_devfreq *cci_df; > + struct notifier_block *opp_nb; > + > + cci_df = platform_get_drvdata(pdev); > + opp_nb = &cci_df->opp_nb; > + > + dev_pm_opp_unregister_notifier(cci_dev, opp_nb); This patch doesn't call the dev_pm_opp_register_notifier. Please remove it. > + devm_devfreq_remove_device(cci_dev, cci_df->devfreq); Don't need to call this function because you used devm_devfreq_add_device(). > + dev_pm_opp_of_remove_table(cci_dev)> + regulator_disable(cci_df->proc_reg); > + > + return 0; > +} > + > +static const __maybe_unused struct of_device_id > + mediatek_cci_devfreq_of_match[] = { Make it on one line and remove '__maybe_unused' keyword. - mediatek_cci_devfreq_of_match-> mediatek_cci_of_match > + { .compatible = "mediatek,mt8183-cci" }, > + { }, > +}; > +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match); ditto. > + > +static struct platform_driver cci_devfreq_driver = { > + .probe = mtk_cci_devfreq_probe, > + .remove = mtk_cci_devfreq_remove, > + .driver = { > + .name = "mediatek-cci-devfreq", > + .of_match_table = of_match_ptr(mediatek_cci_devfreq_of_match), ditto. > + }, > +}; > + > +static int __init mtk_cci_devfreq_init(void) > +{ > + return platform_driver_register(&cci_devfreq_driver); > +} > +module_init(mtk_cci_devfreq_init) > + > +static void __exit mtk_cci_devfreq_exit(void) > +{ > + platform_driver_unregister(&cci_devfreq_driver); > +} > +module_exit(mtk_cci_devfreq_exit) Use 'module_platform_driver' instead of module_init and module_exit. > + > +MODULE_DESCRIPTION("Mediatek CCI devfreq driver"); > +MODULE_AUTHOR("Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>"); > +MODULE_LICENSE("GPL v2"); > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 09/12] devfreq: add mediatek cci devfreq 2020-05-28 7:35 ` Chanwoo Choi @ 2020-05-28 8:00 ` Chanwoo Choi 0 siblings, 0 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 8:00 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream Hi Andrew-sh.Cheng, On 5/28/20 4:35 PM, Chanwoo Choi wrote: > Hi Andrew-sh.Cheng, > > On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: >> This adds a devfreq driver for the Cache Coherent Interconnect (CCI) >> of the Mediatek MT8183. >> >> On the MT8183 the CCI is supplied by the same regulator as the LITTLE >> cores. The driver is notified when the regulator voltage changes >> (driven by cpufreq) and adjusts the CCI frequency to the maximum >> possible value. I understood that the mt8183-cci.c and mt8183 cpufreq driver (ARM_MEDIATEK_CPUFREQ) shared the same regulator. So, when mt8183 cpufreq driver changes the CPU frequency and voltage, the mt8183-cci.c changes the CCI frequency according to the new mt8183 frequency with passive governor. I think that mt8183-cci.c don't need to change the voltage because already mt8183 cpufreq changed the voltage of shared regulator. Why do you change the voltage in this driver? >> >> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> >> --- >> drivers/devfreq/Kconfig | 10 ++ >> drivers/devfreq/Makefile | 1 + >> drivers/devfreq/mt8183-cci-devfreq.c | 206 +++++++++++++++++++++++++++++++++++ > > The mt8183-cci.c is enough for driver name. > >> 3 files changed, 217 insertions(+) >> create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c >> >> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >> index d9067950af6a..4ed7116271ee 100644 >> --- a/drivers/devfreq/Kconfig >> +++ b/drivers/devfreq/Kconfig >> @@ -103,6 +103,16 @@ config ARM_IMX8M_DDRC_DEVFREQ >> This adds the DEVFREQ driver for the i.MX8M DDR Controller. It allows >> adjusting DRAM frequency. >> >> +config ARM_MT8183_CCI_DEVFREQ >> + tristate "MT8183 CCI DEVFREQ Driver" >> + depends on ARM_MEDIATEK_CPUFREQ >> + help >> + This adds a devfreq driver for Cache Coherent Interconnect >> + of Mediatek MT8183, which is shared the same regulator >> + with cpu cluster. >> + It can track buck voltage and update a proper cci frequency. > > s/cci/CCI > >> + Use notification to get regulator status. >> + >> config ARM_TEGRA_DEVFREQ >> tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver" >> depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \ >> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >> index 3eb4d5e6635c..5b1b670c954d 100644 >> --- a/drivers/devfreq/Makefile >> +++ b/drivers/devfreq/Makefile >> @@ -10,6 +10,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o >> # DEVFREQ Drivers >> obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o >> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o >> +obj-$(CONFIG_ARM_MT8183_CCI_DEVFREQ) += mt8183-cci-devfreq.o >> obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o >> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o >> obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o >> diff --git a/drivers/devfreq/mt8183-cci-devfreq.c b/drivers/devfreq/mt8183-cci-devfreq.c >> new file mode 100644 >> index 000000000000..cd7929a83bf8 >> --- /dev/null >> +++ b/drivers/devfreq/mt8183-cci-devfreq.c >> @@ -0,0 +1,206 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) 2019 MediaTek Inc. > > s/2019/2020 > >> + >> + * Author: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> >> + */ >> + >> +#include <linux/clk.h> >> +#include <linux/devfreq.h> >> +#include <linux/module.h> >> +#include <linux/of.h> >> +#include <linux/platform_device.h> >> +#include <linux/regulator/consumer.h> >> +#include <linux/time.h> >> + >> +#include "governor.h" > > It is not needed. Please remove it. > >> + >> +#define MAX_VOLT_LIMIT (1150000) >> + >> +struct cci_devfreq { >> + struct devfreq *devfreq; >> + struct regulator *proc_reg; > > 'proc' means the 'processor'? > Instead of 'proc_reg', you better to use 'cpu_reg'. > >> + struct clk *cci_clk; >> + int old_vproc; >> + unsigned long old_freq; >> +}; >> + >> +static int mtk_cci_set_voltage(struct cci_devfreq *cci_df, int vproc) >> +{ >> + int ret; >> + >> + ret = regulator_set_voltage(cci_df->proc_reg, vproc, >> + MAX_VOLT_LIMIT); >> + if (!ret) >> + cci_df->old_vproc = vproc; >> + return ret; >> +} >> + >> +static int mtk_cci_devfreq_target(struct device *dev, unsigned long *freq, >> + u32 flags) >> +{ >> + int ret; >> + struct cci_devfreq *cci_df = dev_get_drvdata(dev); >> + struct dev_pm_opp *opp; >> + unsigned long opp_rate, opp_voltage, old_voltage; >> + >> + if (!cci_df) >> + return -EINVAL; >> + >> + if (cci_df->old_freq == *freq) >> + return 0; >> + >> + opp_rate = *freq; >> + opp = dev_pm_opp_find_freq_floor(dev, &opp_rate); >> + opp_voltage = dev_pm_opp_get_voltage(opp); >> + dev_pm_opp_put(opp); > > > You can use the helper function for getting the rate > with devfreq_recommended_opp(). You can refer the following code > in drivers/devfreq/exynos-bus.c > > opp = devfreq_recommended_opp(dev, freq, flags); > if (IS_ERR(opp)) { > dev_err(dev, "failed to get recommended opp instance\n"); > return PTR_ERR(opp); > } > dev_pm_opp_put(opp); > >> + >> + old_voltage = cci_df->old_vproc; >> + if (old_voltage == 0) >> + old_voltage = regulator_get_voltage(cci_df->proc_reg); >> + >> + // scale up: set voltage first then freq >> + if (opp_voltage > old_voltage) { >> + ret = mtk_cci_set_voltage(cci_df, opp_voltage); >> + if (ret) { >> + pr_err("cci: failed to scale up voltage\n"); >> + return ret; >> + } >> + } >> + >> + ret = clk_set_rate(cci_df->cci_clk, *freq); >> + if (ret) { >> + pr_err("%s: failed cci to set rate: %d\n", __func__, >> + ret); >> + mtk_cci_set_voltage(cci_df, old_voltage); >> + return ret; >> + } >> + >> + // scale down: set freq first then voltage >> + if (opp_voltage < old_voltage) { >> + ret = mtk_cci_set_voltage(cci_df, opp_voltage); >> + if (ret) { >> + pr_err("cci: failed to scale down voltage\n"); >> + clk_set_rate(cci_df->cci_clk, cci_df->old_freq); >> + return ret; >> + } >> + } > > > I recommend that dev_pm_opp_set_rate() and dev_pm_opp_set_regulator() > instead of 'clk_set_rate' and 'regulator_set_voltage'. > In the dev_pm_opp_set_rate(), handle the these sequence. > You can refer the merged patch[1]. > > [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68 > - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate() > > >> + >> + cci_df->old_freq = *freq; >> + >> + return 0; >> +} >> + >> +static struct devfreq_dev_profile cci_devfreq_profile = { >> + .target = mtk_cci_devfreq_target, > > Need to add '.exit' for calling dev_pm_opp_of_remove_table(). > You can refer the merged devfreq patches like exynos_bus.c, imx-bus.c. > >> +}; >> + >> +static int mtk_cci_devfreq_probe(struct platform_device *pdev) >> +{ >> + struct device *cci_dev = &pdev->dev; >> + struct cci_devfreq *cci_df; >> + struct devfreq_passive_data *passive_data; >> + int ret; >> + >> + cci_df = devm_kzalloc(cci_dev, sizeof(*cci_df), GFP_KERNEL); >> + if (!cci_df) >> + return -ENOMEM; >> + >> + cci_df->cci_clk = devm_clk_get(cci_dev, "cci_clock"); >> + ret = PTR_ERR_OR_ZERO(cci_df->cci_clk); >> + if (ret) { >> + if (ret != -EPROBE_DEFER) >> + dev_err(cci_dev, "failed to get clock for CCI: %d\n", >> + ret); >> + return ret; >> + } >> + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc"); >> + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg); >> + if (ret) { >> + if (ret != -EPROBE_DEFER) >> + dev_err(cci_dev, "failed to get regulator for CCI: %d\n", >> + ret); >> + return ret; >> + } > > I recommend that use dev_pm_opp_set_regulators. > You can refer the merged patch[1]. > > [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68 > - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate() > > >> + ret = regulator_enable(cci_df->proc_reg); >> + if (ret) { >> + pr_warn("enable buck for cci fail\n"); > > Use dev_err instead of 'pr_warn'. > >> + return ret; >> + } >> + >> + ret = dev_pm_opp_of_add_table(cci_dev); >> + if (ret) { >> + dev_err(cci_dev, "Fail to init CCI OPP table: %d\n", ret); > > How about changing the error log as following > because in this driver, use the 'failed to' sentence for error handling? > > failed to get OPP table for CCI:L %d > >> + return ret; >> + } >> + >> + platform_set_drvdata(pdev, cci_df); >> + >> + passive_data = devm_kzalloc(cci_dev, sizeof(*passive_data), GFP_KERNEL); >> + if (!passive_data) >> + return -ENOMEM; > > On this error case, you have to call dev_pm_opp_of_remove_table(). > You better to make the 'err_opp' jump lable and then add 'goto err_opp'. > >> + >> + passive_data->parent_type = CPUFREQ_PARENT_DEV; >> + >> + cci_df->devfreq = devm_devfreq_add_device(cci_dev, >> + &cci_devfreq_profile, >> + DEVFREQ_GOV_PASSIVE, >> + passive_data); >> + if (IS_ERR(cci_df->devfreq)) { >> + ret = PTR_ERR(cci_df->devfreq); >> + dev_err(cci_dev, "cannot create cci devfreq device:%d\n", ret); >> + dev_pm_opp_of_remove_table(cci_dev); > > Instead of direct call, use 'goto err_opp'. > >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int mtk_cci_devfreq_remove(struct platform_device *pdev) >> +{ >> + struct device *cci_dev = &pdev->dev; >> + struct cci_devfreq *cci_df; >> + struct notifier_block *opp_nb; >> + >> + cci_df = platform_get_drvdata(pdev); >> + opp_nb = &cci_df->opp_nb; >> + >> + dev_pm_opp_unregister_notifier(cci_dev, opp_nb); > > This patch doesn't call the dev_pm_opp_register_notifier. > Please remove it. > >> + devm_devfreq_remove_device(cci_dev, cci_df->devfreq); > > Don't need to call this function because you used devm_devfreq_add_device(). > >> + dev_pm_opp_of_remove_table(cci_dev)> + regulator_disable(cci_df->proc_reg); >> + >> + return 0; >> +} >> + >> +static const __maybe_unused struct of_device_id >> + mediatek_cci_devfreq_of_match[] = { > > Make it on one line and remove '__maybe_unused' keyword. > - mediatek_cci_devfreq_of_match-> mediatek_cci_of_match > >> + { .compatible = "mediatek,mt8183-cci" }, >> + { }, >> +}; >> +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match); > > ditto. > >> + >> +static struct platform_driver cci_devfreq_driver = { >> + .probe = mtk_cci_devfreq_probe, >> + .remove = mtk_cci_devfreq_remove, >> + .driver = { >> + .name = "mediatek-cci-devfreq", >> + .of_match_table = of_match_ptr(mediatek_cci_devfreq_of_match), > > ditto. > >> + }, >> +}; >> + >> +static int __init mtk_cci_devfreq_init(void) >> +{ >> + return platform_driver_register(&cci_devfreq_driver); >> +} >> +module_init(mtk_cci_devfreq_init) >> + >> +static void __exit mtk_cci_devfreq_exit(void) >> +{ >> + platform_driver_unregister(&cci_devfreq_driver); >> +} >> +module_exit(mtk_cci_devfreq_exit) > > Use 'module_platform_driver' instead of module_init and module_exit. > >> + >> +MODULE_DESCRIPTION("Mediatek CCI devfreq driver"); >> +MODULE_AUTHOR("Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>"); >> +MODULE_LICENSE("GPL v2"); >> > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200520034307.20435-2-andrew-sh.cheng@mediatek.com>]
* Re: [PATCH 01/12] OPP: Allow required-opps even if the device doesn't have power-domains [not found] ` <20200520034307.20435-2-andrew-sh.cheng@mediatek.com> @ 2020-05-20 14:54 ` Matthias Brugger 0 siblings, 0 replies; 15+ messages in thread From: Matthias Brugger @ 2020-05-20 14:54 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Saravana Kannan On 20/05/2020 05:42, Andrew-sh.Cheng wrote: > From: Saravana Kannan <saravanak@google.com> > > A Device-A can have a (minimum) performance requirement on another > Device-B to be able to function correctly. This performance requirement > on Device-B can also change based on the current performance level of > Device-A. > > The existing required-opps feature fits well to describe this need. So, > instead of limiting required-opps to point to only PM-domain devices, > allow it to point to any device. > > Signed-off-by: Saravana Kannan <saravanak@google.com> Please check all patches, they are missing your Signed-off-by Regards, Matthias > --- > drivers/opp/core.c | 2 +- > drivers/opp/of.c | 11 ----------- > 2 files changed, 1 insertion(+), 12 deletions(-) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index ba43e6a3dc0a..51403c1f2481 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -755,7 +755,7 @@ static int _set_required_opps(struct device *dev, > return 0; > > /* Single genpd case */ > - if (!genpd_virt_devs) { > + if (!genpd_virt_devs && required_opp_tables[0]->is_genpd) { > pstate = likely(opp) ? opp->required_opps[0]->pstate : 0; > ret = dev_pm_genpd_set_performance_state(dev, pstate); > if (ret) { > diff --git a/drivers/opp/of.c b/drivers/opp/of.c > index 9cd8f0adacae..6d33de668a7b 100644 > --- a/drivers/opp/of.c > +++ b/drivers/opp/of.c > @@ -195,17 +195,6 @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table, > > if (IS_ERR(required_opp_tables[i])) > goto free_required_tables; > - > - /* > - * We only support genpd's OPPs in the "required-opps" for now, > - * as we don't know how much about other cases. Error out if the > - * required OPP doesn't belong to a genpd. > - */ > - if (!required_opp_tables[i]->is_genpd) { > - dev_err(dev, "required-opp doesn't belong to genpd: %pOF\n", > - required_np); > - goto free_required_tables; > - } > } > > goto put_np; > ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CGME20200520034335epcas1p45a321a1a878fb7cd7b9c9ada0a474ef7@epcas1p4.samsung.com>]
[parent not found: <20200520034307.20435-7-andrew-sh.cheng@mediatek.com>]
* Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor [not found] ` <20200520034307.20435-7-andrew-sh.cheng@mediatek.com> @ 2020-05-28 5:03 ` Chanwoo Choi 2020-05-28 6:14 ` Chanwoo Choi 1 sibling, 0 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 5:03 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Saravana Kannan, Sibi Sankar Hi Andrew-sh.Cheng, Thanks for your posting. I like this approach absolutely. I think that it is necessary. When I developed the embedded product, I needed this feature always. I add the comments on below. On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: > From: Saravana Kannan <skannan@codeaurora.org> > > Many CPU architectures have caches that can scale independent of the > CPUs. Frequency scaling of the caches is necessary to make sure that the > cache is not a performance bottleneck that leads to poor performance and > power. The same idea applies for RAM/DDR. > > To achieve this, this patch adds support for cpu based scaling to the > passive governor. This is accomplished by taking the current frequency > of each CPU frequency domain and then adjust the frequency of the cache > (or any devfreq device) based on the frequency of the CPUs. It listens > to CPU frequency transition notifiers to keep itself up to date on the > current CPU frequency. > > To decide the frequency of the device, the governor does one of the > following: > * Derives the optimal devfreq device opp from required-opps property of > the parent cpu opp_table. > > * Scales the device frequency in proportion to the CPU frequency. So, if > the CPUs are running at their max frequency, the device runs at its > max frequency. If the CPUs are running at their min frequency, the > device runs at its min frequency. It is interpolated for frequencies > in between. > > Andrew-sh.Cheng change > dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq > to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value > for kernel-5.7 > > Signed-off-by: Saravana Kannan <skannan@codeaurora.org> > [Sibi: Integrated cpu-freqmap governor into passive_governor] > Signed-off-by: Sibi Sankar <sibis@codeaurora.org> > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > drivers/devfreq/Kconfig | 2 + > drivers/devfreq/governor_passive.c | 278 ++++++++++++++++++++++++++++++++++--- > include/linux/devfreq.h | 40 +++++- > 3 files changed, 299 insertions(+), 21 deletions(-) > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index 0b1df12e0f21..d9067950af6a 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE > device. This governor does not change the frequency by itself > through sysfs entries. The passive governor recommends that > devfreq device uses the OPP table to get the frequency/voltage. > + Alternatively the governor can also be chosen to scale based on > + the online CPUs current frequency. > > comment "DEVFREQ Drivers" > > diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c > index 2d67d6c12dce..7dcda02a5bb7 100644 > --- a/drivers/devfreq/governor_passive.c > +++ b/drivers/devfreq/governor_passive.c > @@ -8,11 +8,89 @@ > */ > > #include <linux/module.h> > +#include <linux/cpu.h> > +#include <linux/cpufreq.h> > +#include <linux/cpumask.h> > #include <linux/device.h> > #include <linux/devfreq.h> > +#include <linux/slab.h> > #include "governor.h" > > -static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data, Need to change 'unsigned int' to 'unsigned long'. > + unsigned int cpu) > +{ > + unsigned int cpu_min, cpu_max, dev_min, dev_max, cpu_percent, max_state; Better to define them separately as following and then need to rename the variable. Usually, use the 'min_freq' and 'max_freq' word for the minimum/maximum frequency. unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq, cpu_percent; unsigned long dev_min_freq, dev_max_freq, dev_max_state, The devfreq used 'unsigned long'. The cpufreq used 'unsigned long' and 'unsigned int'. You need to handle them properly. > + struct devfreq_cpu_state *cpu_state = data->cpu_state[cpu]; > + struct devfreq *devfreq = (struct devfreq *)data->this; > + unsigned long *freq_table = devfreq->profile->freq_table; In this function, use 'cpu' work for cpufreq and use 'dev' for devfreq. So, I think 'dev_freq_table' is proper name instead of 'freq_table' for the readability. freq_table -> dev_freq_table > + struct dev_pm_opp *opp = NULL, *cpu_opp = NULL; In the get_target_freq_with_devfreq(), use 'p_opp' indicating the OPP of parent device. For the consistency, I think that use 'p_opp' instead of 'cpu_opp'. > + unsigned long cpu_freq, freq; Define the 'cpu_freq' on above with cpu_min_freq/cpu_max_freq definition. cpu_freq -> cpu_curr_freq. > + > + if (!cpu_state || cpu_state->first_cpu != cpu || > + !cpu_state->opp_table || !devfreq->opp_table) > + return 0; > + > + cpu_freq = cpu_state->freq * 1000; > + cpu_opp = devfreq_recommended_opp(cpu_state->dev, &cpu_freq, 0); > + if (IS_ERR(cpu_opp)) > + return 0; > + > + opp = dev_pm_opp_xlate_required_opp(cpu_state->opp_table, > + devfreq->opp_table, cpu_opp); > + dev_pm_opp_put(cpu_opp); > + > + if (!IS_ERR(opp)) { > + freq = dev_pm_opp_get_freq(opp); > + dev_pm_opp_put(opp); Better to add the 'out' goto statement. If you use 'goto out', you can reduce the one indentation without 'else' statement. > + } else { As I commented, when dev_pm_opp_xlate_required_opp() return successfully , use 'goto out'. We can remove 'else' and then reduce the unneeded indentation. > + /* Use Interpolation if required opps is not available */ > + cpu_min = cpu_state->min_freq; > + cpu_max = cpu_state->max_freq; > + cpu_freq = cpu_state->freq; > + > + if (freq_table) { > + /* Get minimum frequency according to sorting order */ > + max_state = freq_table[devfreq->profile->max_state - 1]; > + if (freq_table[0] < max_state) { > + dev_min = freq_table[0]; > + dev_max = max_state; > + } else { > + dev_min = max_state; > + dev_max = freq_table[0]; > + } > + } else { > + if (devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value > + <= devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value) > + return 0; > + dev_min = > + devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value; > + dev_max = > + devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value; I think it is not proper to access the variable of pm_qos structure directly. Instead of direct access, you have to use the exported PM QoS function such as - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MIN_FREQUENCY); - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MAX_FREQUENCY); > + } > + cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min; > + freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100); > + } I think that you better to add 'out' jump label as following: out: > + > + return freq; > +} > + > +static int get_target_freq_with_cpufreq(struct devfreq *devfreq, > + unsigned long *freq) > +{ > + struct devfreq_passive_data *p_data = > + (struct devfreq_passive_data *)devfreq->data; > + unsigned int cpu, target_freq = 0; Need to define 'target_freq' with 'unsigned long' type. > + > + for_each_online_cpu(cpu) > + target_freq = max(target_freq, > + xlate_cpufreq_to_devfreq(p_data, cpu)); > + > + *freq = target_freq; > + > + return 0; > +} > + > +static int get_target_freq_with_devfreq(struct devfreq *devfreq, > unsigned long *freq) > { > struct devfreq_passive_data *p_data > @@ -23,16 +101,6 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > int i, count, ret = 0; > > /* > - * If the devfreq device with passive governor has the specific method > - * to determine the next frequency, should use the get_target_freq() > - * of struct devfreq_passive_data. > - */ > - if (p_data->get_target_freq) { > - ret = p_data->get_target_freq(devfreq, freq); > - goto out; > - } > - > - /* > * If the parent and passive devfreq device uses the OPP table, > * get the next frequency by using the OPP table. > */ > @@ -102,6 +170,37 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > return ret; > } > > +static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > + unsigned long *freq) > +{ > + struct devfreq_passive_data *p_data = > + (struct devfreq_passive_data *)devfreq->data; > + int ret; > + > + /* > + * If the devfreq device with passive governor has the specific method > + * to determine the next frequency, should use the get_target_freq() > + * of struct devfreq_passive_data. > + */ > + if (p_data->get_target_freq) > + return p_data->get_target_freq(devfreq, freq); > + > + switch (p_data->parent_type) { > + case DEVFREQ_PARENT_DEV: > + ret = get_target_freq_with_devfreq(devfreq, freq); > + break; > + case CPUFREQ_PARENT_DEV: > + ret = get_target_freq_with_cpufreq(devfreq, freq); > + break; > + default: > + ret = -EINVAL; > + dev_err(&devfreq->dev, "Invalid parent type\n"); > + break; > + } > + > + return ret; > +} > + > static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq) > { > int ret; > @@ -156,6 +255,140 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb, > return NOTIFY_DONE; > } > > +static int cpufreq_passive_notifier_call(struct notifier_block *nb, > + unsigned long event, void *ptr) > +{ > + struct devfreq_passive_data *data = > + container_of(nb, struct devfreq_passive_data, nb); > + struct devfreq *devfreq = (struct devfreq *)data->this; > + struct devfreq_cpu_state *cpu_state; > + struct cpufreq_freqs *freq = ptr; How about changing 'freq' to 'cpu_freqs'? In the drivers/cpufreq/cpufreq.c, use 'freqs' name indicating the instance of 'struct cpufreq_freqs'. And in order to identfy, how about adding 'cpu_' prefix for variable name? > + unsigned int current_freq; Need to define curr_freq with 'unsigned long' type and better to use 'curr_freq' variable name. > + int ret; > + > + if (event != CPUFREQ_POSTCHANGE || !freq || > + !data->cpu_state[freq->policy->cpu]) > + return 0; > + > + cpu_state = data->cpu_state[freq->policy->cpu]; > + if (cpu_state->freq == freq->new) > + return 0; > + > + /* Backup current freq and pre-update cpu state freq*/ > + current_freq = cpu_state->freq; > + cpu_state->freq = freq->new; > + > + mutex_lock(&devfreq->lock); > + ret = update_devfreq(devfreq); > + mutex_unlock(&devfreq->lock); > + if (ret) { > + cpu_state->freq = current_freq; > + dev_err(&devfreq->dev, "Couldn't update the frequency.\n"); > + return ret; > + } > + > + return 0; > +} > + > +static int cpufreq_passive_register(struct devfreq_passive_data **p_data) > +{ > + struct devfreq_passive_data *data = *p_data; > + struct devfreq *devfreq = (struct devfreq *)data->this; > + struct device *dev = devfreq->dev.parent; > + struct opp_table *opp_table = NULL; > + struct devfreq_cpu_state *state; For the readability, I thinkt 'cpu_state' is proper instead of 'state'. > + struct cpufreq_policy *policy; > + struct device *cpu_dev; > + unsigned int cpu; > + int ret; > + > + get_online_cpus(); Add blank line. > + data->nb.notifier_call = cpufreq_passive_notifier_call; > + ret = cpufreq_register_notifier(&data->nb, > + CPUFREQ_TRANSITION_NOTIFIER); > + if (ret) { > + dev_err(dev, "Couldn't register cpufreq notifier.\n"); > + data->nb.notifier_call = NULL; > + goto out; > + } > + > + /* Populate devfreq_cpu_state */ > + for_each_online_cpu(cpu) { > + if (data->cpu_state[cpu]) > + continue; > + > + policy = cpufreq_cpu_get(cpu); cpufreq_cpu_get() might return 'NULL'. I think you need to handle return value as following: if (!policy) { ret = -EINVAL; goto out; } else if (PTR_ERR(policy) == -EPROBE_DEFER) { goto out; } else if (IS_ERR(policy) { ret = PTR_ERR(policy); dev_err(dev, "Couldn't get the cpufreq_poliy.\n"); goto out; } If cpufreq_cpu_get() return successfully, to do next. It reduces the one indentaion. > + if (policy) { > + state = kzalloc(sizeof(*state), GFP_KERNEL); > + if (!state) { > + ret = -ENOMEM; > + goto out; > + } > + > + cpu_dev = get_cpu_device(cpu); > + if (!cpu_dev) { > + dev_err(dev, "Couldn't get cpu device.\n"); > + ret = -ENODEV; > + goto out; > + } > + > + opp_table = dev_pm_opp_get_opp_table(cpu_dev); > + if (IS_ERR(devfreq->opp_table)) { > + ret = PTR_ERR(opp_table); > + goto out; > + } > + > + state->dev = cpu_dev; > + state->opp_table = opp_table; > + state->first_cpu = cpumask_first(policy->related_cpus); > + state->freq = policy->cur; > + state->min_freq = policy->cpuinfo.min_freq; > + state->max_freq = policy->cpuinfo.max_freq; > + data->cpu_state[cpu] = state; Add blank line. > + cpufreq_cpu_put(policy); > + } else { > + ret = -EPROBE_DEFER; > + goto out; > + } > + } Add blank line. > +out: > + put_online_cpus(); > + if (ret) > + return ret; > + > + /* Update devfreq */ > + mutex_lock(&devfreq->lock); > + ret = update_devfreq(devfreq); > + mutex_unlock(&devfreq->lock); > + if (ret) > + dev_err(dev, "Couldn't update the frequency.\n"); > + > + return ret; > +} > + > +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data) > +{ > + struct devfreq_passive_data *data = *p_data; > + struct devfreq_cpu_state *cpu_state; > + int cpu; > + > + if (data->nb.notifier_call) > + cpufreq_unregister_notifier(&data->nb, > + CPUFREQ_TRANSITION_NOTIFIER); > + > + for_each_possible_cpu(cpu) { > + cpu_state = data->cpu_state[cpu]; > + if (cpu_state) { > + if (cpu_state->opp_table) > + dev_pm_opp_put_opp_table(cpu_state->opp_table); > + kfree(cpu_state); > + cpu_state = NULL; > + } > + } > + > + return 0; > +} > + > static int devfreq_passive_event_handler(struct devfreq *devfreq, > unsigned int event, void *data) > { > @@ -165,7 +398,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, > struct notifier_block *nb = &p_data->nb; > int ret = 0; > > - if (!parent) > + if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent) > return -EPROBE_DEFER; If you modify the devfreq_passive_event_handler() as following, you can move this condition for DEVFREQ_PARENT_DEV into (register|unregister)_parent_dev_notifier. switch (event) { case DEVFREQ_GOV_START: ret = register_parent_dev_notifier(p_data); break; case DEVFREQ_GOV_STOP: ret = unregister_parent_dev_notifier(p_data); break; default: ret = -EINVAL; break; } return ret; > > switch (event) { > @@ -173,13 +406,24 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, > if (!p_data->this) > p_data->this = devfreq; > > - nb->notifier_call = devfreq_passive_notifier_call; > - ret = devfreq_register_notifier(parent, nb, > - DEVFREQ_TRANSITION_NOTIFIER); > + if (p_data->parent_type == DEVFREQ_PARENT_DEV) { > + nb->notifier_call = devfreq_passive_notifier_call; > + ret = devfreq_register_notifier(parent, nb, > + DEVFREQ_TRANSITION_NOTIFIER); > + } else if (p_data->parent_type == CPUFREQ_PARENT_DEV) { > + ret = cpufreq_passive_register(&p_data); I think that we better to collect the code related to notifier registration into one function like devfreq_pass_register_notifier() instead of cpufreq_passive_register() as following: I think it is more simple and readable. If you have more proper function name of register_parent_dev_notifier, please give your opinion. int register_parent_dev_notifier(struct devfreq_passive_data **p_data) switch (p_data->parent_type) { case DEVFREQ_PARENT_DEV: nb->notifier_call = devfreq_passive_notifier_call; ret = devfreq_register_notifier(parent, nb, break; case CPUFREQ_PARENT_DEV: cpufreq_register_notifier(...) ... break; } > + } else { > + ret = -EINVAL; > + } > break; > case DEVFREQ_GOV_STOP: > - WARN_ON(devfreq_unregister_notifier(parent, nb, > - DEVFREQ_TRANSITION_NOTIFIER)); > + if (p_data->parent_type == DEVFREQ_PARENT_DEV) > + WARN_ON(devfreq_unregister_notifier(parent, nb, > + DEVFREQ_TRANSITION_NOTIFIER)); > + else if (p_data->parent_type == CPUFREQ_PARENT_DEV) > + cpufreq_passive_unregister(&p_data); > + else > + ret = -EINVAL; ditto. unregister_parent_dev_notifier(struct devfreq_passive_data **p_data) > break; > default: > break; > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h > index a4b19d593151..04ce576fd6f1 100644 > --- a/include/linux/devfreq.h > +++ b/include/linux/devfreq.h > @@ -278,6 +278,32 @@ struct devfreq_simple_ondemand_data { > > #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE) > /** > + * struct devfreq_cpu_state - holds the per-cpu state > + * @freq: the current frequency of the cpu. > + * @min_freq: the min frequency of the cpu. > + * @max_freq: the max frequency of the cpu. > + * @first_cpu: the cpumask of the first cpu of a policy. > + * @dev: reference to cpu device. > + * @opp_table: reference to cpu opp table. > + * > + * This structure stores the required cpu_state of a cpu. > + * This is auto-populated by the governor. > + */ > +struct devfreq_cpu_state {> + unsigned int freq; It is better to change from 'freq' to 'curr_freq' for more correct expression. > + unsigned int min_freq; > + unsigned int max_freq; > + unsigned int first_cpu; > + struct device *dev; How about changing the name 'dev' to 'cpu_dev'? > + struct opp_table *opp_table; > +}; devfreq_cpu_state is only handled by within driver/devfreq/governor_passive.c. So, you can move it into drivers/devfreq/governor_passive.c and just add the definition into include/linux/devfreq.h as following: It is able to prevent the access of variable of 'struct devfreq_cpu_state' outside. struct devfreq_cpu_state; > + > +enum devfreq_parent_dev_type { > + DEVFREQ_PARENT_DEV, > + CPUFREQ_PARENT_DEV, > +}; > + > +/** > * struct devfreq_passive_data - ``void *data`` fed to struct devfreq > * and devfreq_add_device > * @parent: the devfreq instance of parent device. > @@ -288,13 +314,15 @@ struct devfreq_simple_ondemand_data { > * using governors except for passive governor. > * If the devfreq device has the specific method to decide > * the next frequency, should use this callback. > - * @this: the devfreq instance of own device. > - * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list > + * @parent_type parent type of the device Need to add ':' at the end of word. -> "parent_type:". > + * @this: the devfreq instance of own device. > + * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list I knew that you make them with same indentation. But, actually, it is not related to this patch like clean-up code. Even if it is not pretty, you better to don't touch 'this' and 'nb' indentaion. > + * @cpu_state: the state min/max/current frequency of all online cpu's > * > * The devfreq_passive_data have to set the devfreq instance of parent > * device with governors except for the passive governor. But, don't need to > - * initialize the 'this' and 'nb' field because the devfreq core will handle > - * them. > + * initialize the 'this', 'nb' and 'cpu_state' field because the devfreq core > + * will handle them. > */ > struct devfreq_passive_data { > /* Should set the devfreq instance of parent device */ > @@ -303,9 +331,13 @@ struct devfreq_passive_data { > /* Optional callback to decide the next frequency of passvice device */ > int (*get_target_freq)(struct devfreq *this, unsigned long *freq); > > + /* Should set the type of parent device */ > + enum devfreq_parent_dev_type parent_type; > + > /* For passive governor's internal use. Don't need to set them */ > struct devfreq *this; > struct notifier_block nb; > + struct devfreq_cpu_state *cpu_state[NR_CPUS]; > }; > #endif > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor [not found] ` <20200520034307.20435-7-andrew-sh.cheng@mediatek.com> 2020-05-28 5:03 ` [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor Chanwoo Choi @ 2020-05-28 6:14 ` Chanwoo Choi 2020-05-28 7:17 ` Chanwoo Choi [not found] ` <1591098190.30729.15.camel@mtksdaap41> 1 sibling, 2 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 6:14 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Sibi Sankar Hi Andrew-sh.Cheng, Thanks for your posting. I like this approach absolutely. I think that it is necessary. When I developed the embedded product, I needed this feature always. I add the comments on below. And the following email is not valid. So, I dropped this email from Cc list. Saravana Kannan <skannan@codeaurora.org> On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: > From: Saravana Kannan <skannan@codeaurora.org> > > Many CPU architectures have caches that can scale independent of the > CPUs. Frequency scaling of the caches is necessary to make sure that the > cache is not a performance bottleneck that leads to poor performance and > power. The same idea applies for RAM/DDR. > > To achieve this, this patch adds support for cpu based scaling to the > passive governor. This is accomplished by taking the current frequency > of each CPU frequency domain and then adjust the frequency of the cache > (or any devfreq device) based on the frequency of the CPUs. It listens > to CPU frequency transition notifiers to keep itself up to date on the > current CPU frequency. > > To decide the frequency of the device, the governor does one of the > following: > * Derives the optimal devfreq device opp from required-opps property of > the parent cpu opp_table. > > * Scales the device frequency in proportion to the CPU frequency. So, if > the CPUs are running at their max frequency, the device runs at its > max frequency. If the CPUs are running at their min frequency, the > device runs at its min frequency. It is interpolated for frequencies > in between. > > Andrew-sh.Cheng change > dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq > to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value > for kernel-5.7 > > Signed-off-by: Saravana Kannan <skannan@codeaurora.org> > [Sibi: Integrated cpu-freqmap governor into passive_governor] > Signed-off-by: Sibi Sankar <sibis@codeaurora.org> > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > drivers/devfreq/Kconfig | 2 + > drivers/devfreq/governor_passive.c | 278 ++++++++++++++++++++++++++++++++++--- > include/linux/devfreq.h | 40 +++++- > 3 files changed, 299 insertions(+), 21 deletions(-) > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index 0b1df12e0f21..d9067950af6a 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE > device. This governor does not change the frequency by itself > through sysfs entries. The passive governor recommends that > devfreq device uses the OPP table to get the frequency/voltage. > + Alternatively the governor can also be chosen to scale based on > + the online CPUs current frequency. > > comment "DEVFREQ Drivers" > > diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c > index 2d67d6c12dce..7dcda02a5bb7 100644 > --- a/drivers/devfreq/governor_passive.c > +++ b/drivers/devfreq/governor_passive.c > @@ -8,11 +8,89 @@ > */ > > #include <linux/module.h> > +#include <linux/cpu.h> > +#include <linux/cpufreq.h> > +#include <linux/cpumask.h> > #include <linux/device.h> > #include <linux/devfreq.h> > +#include <linux/slab.h> > #include "governor.h" > > -static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data, Need to change 'unsigned int' to 'unsigned long'. > + unsigned int cpu) > +{ > + unsigned int cpu_min, cpu_max, dev_min, dev_max, cpu_percent, max_state; Better to define them separately as following and then need to rename the variable. Usually, use the 'min_freq' and 'max_freq' word for the minimum/maximum frequency. unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq, cpu_percent; unsigned long dev_min_freq, dev_max_freq, dev_max_state, The devfreq used 'unsigned long'. The cpufreq used 'unsigned long' and 'unsigned int'. You need to handle them properly. > + struct devfreq_cpu_state *cpu_state = data->cpu_state[cpu]; > + struct devfreq *devfreq = (struct devfreq *)data->this; > + unsigned long *freq_table = devfreq->profile->freq_table; In this function, use 'cpu' work for cpufreq and use 'dev' for devfreq. So, I think 'dev_freq_table' is proper name instead of 'freq_table' for the readability. freq_table -> dev_freq_table > + struct dev_pm_opp *opp = NULL, *cpu_opp = NULL; In the get_target_freq_with_devfreq(), use 'p_opp' indicating the OPP of parent device. For the consistency, I think that use 'p_opp' instead of 'cpu_opp'. > + unsigned long cpu_freq, freq; Define the 'cpu_freq' on above with cpu_min_freq/cpu_max_freq definition. cpu_freq -> cpu_curr_freq. > + > + if (!cpu_state || cpu_state->first_cpu != cpu || > + !cpu_state->opp_table || !devfreq->opp_table) > + return 0; > + > + cpu_freq = cpu_state->freq * 1000; > + cpu_opp = devfreq_recommended_opp(cpu_state->dev, &cpu_freq, 0); > + if (IS_ERR(cpu_opp)) > + return 0; > + > + opp = dev_pm_opp_xlate_required_opp(cpu_state->opp_table, > + devfreq->opp_table, cpu_opp); > + dev_pm_opp_put(cpu_opp); > + > + if (!IS_ERR(opp)) { > + freq = dev_pm_opp_get_freq(opp); > + dev_pm_opp_put(opp); Better to add the 'out' goto statement. If you use 'goto out', you can reduce the one indentation without 'else' statement. > + } else { As I commented, when dev_pm_opp_xlate_required_opp() return successfully , use 'goto out'. We can remove 'else' and then reduce the unneeded indentation. > + /* Use Interpolation if required opps is not available */ > + cpu_min = cpu_state->min_freq; > + cpu_max = cpu_state->max_freq; > + cpu_freq = cpu_state->freq; > + > + if (freq_table) { > + /* Get minimum frequency according to sorting order */ > + max_state = freq_table[devfreq->profile->max_state - 1]; > + if (freq_table[0] < max_state) { > + dev_min = freq_table[0]; > + dev_max = max_state; > + } else { > + dev_min = max_state; > + dev_max = freq_table[0]; > + } > + } else { > + if (devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value > + <= devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value) > + return 0; > + dev_min = > + devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value; > + dev_max = > + devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value; I think it is not proper to access the variable of pm_qos structure directly. Instead of direct access, you have to use the exported PM QoS function such as - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MIN_FREQUENCY); - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MAX_FREQUENCY); > + } > + cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min; > + freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100); > + } I think that you better to add 'out' jump label as following: out: > + > + return freq; > +} > + > +static int get_target_freq_with_cpufreq(struct devfreq *devfreq, > + unsigned long *freq) > +{ > + struct devfreq_passive_data *p_data = > + (struct devfreq_passive_data *)devfreq->data; > + unsigned int cpu, target_freq = 0; Need to define 'target_freq' with 'unsigned long' type. > + > + for_each_online_cpu(cpu) > + target_freq = max(target_freq, > + xlate_cpufreq_to_devfreq(p_data, cpu)); > + > + *freq = target_freq; > + > + return 0; > +} > + > +static int get_target_freq_with_devfreq(struct devfreq *devfreq, > unsigned long *freq) > { > struct devfreq_passive_data *p_data > @@ -23,16 +101,6 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > int i, count, ret = 0; > > /* > - * If the devfreq device with passive governor has the specific method > - * to determine the next frequency, should use the get_target_freq() > - * of struct devfreq_passive_data. > - */ > - if (p_data->get_target_freq) { > - ret = p_data->get_target_freq(devfreq, freq); > - goto out; > - } > - > - /* > * If the parent and passive devfreq device uses the OPP table, > * get the next frequency by using the OPP table. > */ > @@ -102,6 +170,37 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > return ret; > } > > +static int devfreq_passive_get_target_freq(struct devfreq *devfreq, > + unsigned long *freq) > +{ > + struct devfreq_passive_data *p_data = > + (struct devfreq_passive_data *)devfreq->data; > + int ret; > + > + /* > + * If the devfreq device with passive governor has the specific method > + * to determine the next frequency, should use the get_target_freq() > + * of struct devfreq_passive_data. > + */ > + if (p_data->get_target_freq) > + return p_data->get_target_freq(devfreq, freq); > + > + switch (p_data->parent_type) { > + case DEVFREQ_PARENT_DEV: > + ret = get_target_freq_with_devfreq(devfreq, freq); > + break; > + case CPUFREQ_PARENT_DEV: > + ret = get_target_freq_with_cpufreq(devfreq, freq); > + break; > + default: > + ret = -EINVAL; > + dev_err(&devfreq->dev, "Invalid parent type\n"); > + break; > + } > + > + return ret; > +} > + > static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq) > { > int ret; > @@ -156,6 +255,140 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb, > return NOTIFY_DONE; > } > > +static int cpufreq_passive_notifier_call(struct notifier_block *nb, > + unsigned long event, void *ptr) > +{ > + struct devfreq_passive_data *data = > + container_of(nb, struct devfreq_passive_data, nb); > + struct devfreq *devfreq = (struct devfreq *)data->this; > + struct devfreq_cpu_state *cpu_state; > + struct cpufreq_freqs *freq = ptr; How about changing 'freq' to 'cpu_freqs'? In the drivers/cpufreq/cpufreq.c, use 'freqs' name indicating the instance of 'struct cpufreq_freqs'. And in order to identfy, how about adding 'cpu_' prefix for variable name? > + unsigned int current_freq; Need to define curr_freq with 'unsigned long' type and better to use 'curr_freq' variable name. > + int ret; > + > + if (event != CPUFREQ_POSTCHANGE || !freq || > + !data->cpu_state[freq->policy->cpu]) > + return 0; > + > + cpu_state = data->cpu_state[freq->policy->cpu]; > + if (cpu_state->freq == freq->new) > + return 0; > + > + /* Backup current freq and pre-update cpu state freq*/ > + current_freq = cpu_state->freq; > + cpu_state->freq = freq->new; > + > + mutex_lock(&devfreq->lock); > + ret = update_devfreq(devfreq); > + mutex_unlock(&devfreq->lock); > + if (ret) { > + cpu_state->freq = current_freq; > + dev_err(&devfreq->dev, "Couldn't update the frequency.\n"); > + return ret; > + } > + > + return 0; > +} > + > +static int cpufreq_passive_register(struct devfreq_passive_data **p_data) > +{ > + struct devfreq_passive_data *data = *p_data; > + struct devfreq *devfreq = (struct devfreq *)data->this; > + struct device *dev = devfreq->dev.parent; > + struct opp_table *opp_table = NULL; > + struct devfreq_cpu_state *state; For the readability, I thinkt 'cpu_state' is proper instead of 'state'. > + struct cpufreq_policy *policy; > + struct device *cpu_dev; > + unsigned int cpu; > + int ret; > + > + get_online_cpus(); Add blank line. > + data->nb.notifier_call = cpufreq_passive_notifier_call; > + ret = cpufreq_register_notifier(&data->nb, > + CPUFREQ_TRANSITION_NOTIFIER); > + if (ret) { > + dev_err(dev, "Couldn't register cpufreq notifier.\n"); > + data->nb.notifier_call = NULL; > + goto out; > + } > + > + /* Populate devfreq_cpu_state */ > + for_each_online_cpu(cpu) { > + if (data->cpu_state[cpu]) > + continue; > + > + policy = cpufreq_cpu_get(cpu); cpufreq_cpu_get() might return 'NULL'. I think you need to handle return value as following: if (!policy) { ret = -EINVAL; goto out; } else if (PTR_ERR(policy) == -EPROBE_DEFER) { goto out; } else if (IS_ERR(policy) { ret = PTR_ERR(policy); dev_err(dev, "Couldn't get the cpufreq_poliy.\n"); goto out; } If cpufreq_cpu_get() return successfully, to do next. It reduces the one indentaion. > + if (policy) { > + state = kzalloc(sizeof(*state), GFP_KERNEL); > + if (!state) { > + ret = -ENOMEM; > + goto out; > + } > + > + cpu_dev = get_cpu_device(cpu); > + if (!cpu_dev) { > + dev_err(dev, "Couldn't get cpu device.\n"); > + ret = -ENODEV; > + goto out; > + } > + > + opp_table = dev_pm_opp_get_opp_table(cpu_dev); > + if (IS_ERR(devfreq->opp_table)) { > + ret = PTR_ERR(opp_table); > + goto out; > + } > + > + state->dev = cpu_dev; > + state->opp_table = opp_table; > + state->first_cpu = cpumask_first(policy->related_cpus); > + state->freq = policy->cur; > + state->min_freq = policy->cpuinfo.min_freq; > + state->max_freq = policy->cpuinfo.max_freq; > + data->cpu_state[cpu] = state; Add blank line. > + cpufreq_cpu_put(policy); > + } else { > + ret = -EPROBE_DEFER; > + goto out; > + } > + } Add blank line. > +out: > + put_online_cpus(); > + if (ret) > + return ret; > + > + /* Update devfreq */ > + mutex_lock(&devfreq->lock); > + ret = update_devfreq(devfreq); > + mutex_unlock(&devfreq->lock); > + if (ret) > + dev_err(dev, "Couldn't update the frequency.\n"); > + > + return ret; > +} > + > +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data) > +{ > + struct devfreq_passive_data *data = *p_data; > + struct devfreq_cpu_state *cpu_state; > + int cpu; > + > + if (data->nb.notifier_call) > + cpufreq_unregister_notifier(&data->nb, > + CPUFREQ_TRANSITION_NOTIFIER); > + > + for_each_possible_cpu(cpu) { > + cpu_state = data->cpu_state[cpu]; > + if (cpu_state) { > + if (cpu_state->opp_table) > + dev_pm_opp_put_opp_table(cpu_state->opp_table); > + kfree(cpu_state); > + cpu_state = NULL; > + } > + } > + > + return 0; > +} > + > static int devfreq_passive_event_handler(struct devfreq *devfreq, > unsigned int event, void *data) > { > @@ -165,7 +398,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, > struct notifier_block *nb = &p_data->nb; > int ret = 0; > > - if (!parent) > + if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent) > return -EPROBE_DEFER; If you modify the devfreq_passive_event_handler() as following, you can move this condition for DEVFREQ_PARENT_DEV into (register|unregister)_parent_dev_notifier. switch (event) { case DEVFREQ_GOV_START: ret = register_parent_dev_notifier(p_data); break; case DEVFREQ_GOV_STOP: ret = unregister_parent_dev_notifier(p_data); break; default: ret = -EINVAL; break; } return ret; > > switch (event) { > @@ -173,13 +406,24 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, > if (!p_data->this) > p_data->this = devfreq; > > - nb->notifier_call = devfreq_passive_notifier_call; > - ret = devfreq_register_notifier(parent, nb, > - DEVFREQ_TRANSITION_NOTIFIER); > + if (p_data->parent_type == DEVFREQ_PARENT_DEV) { > + nb->notifier_call = devfreq_passive_notifier_call; > + ret = devfreq_register_notifier(parent, nb, > + DEVFREQ_TRANSITION_NOTIFIER); > + } else if (p_data->parent_type == CPUFREQ_PARENT_DEV) { > + ret = cpufreq_passive_register(&p_data); I think that we better to collect the code related to notifier registration into one function like devfreq_pass_register_notifier() instead of cpufreq_passive_register() as following: I think it is more simple and readable. If you have more proper function name of register_parent_dev_notifier, please give your opinion. int register_parent_dev_notifier(struct devfreq_passive_data **p_data) switch (p_data->parent_type) { case DEVFREQ_PARENT_DEV: nb->notifier_call = devfreq_passive_notifier_call; ret = devfreq_register_notifier(parent, nb, break; case CPUFREQ_PARENT_DEV: cpufreq_register_notifier(...) ... break; } > + } else { > + ret = -EINVAL; > + } > break; > case DEVFREQ_GOV_STOP: > - WARN_ON(devfreq_unregister_notifier(parent, nb, > - DEVFREQ_TRANSITION_NOTIFIER)); > + if (p_data->parent_type == DEVFREQ_PARENT_DEV) > + WARN_ON(devfreq_unregister_notifier(parent, nb, > + DEVFREQ_TRANSITION_NOTIFIER)); > + else if (p_data->parent_type == CPUFREQ_PARENT_DEV) > + cpufreq_passive_unregister(&p_data); > + else > + ret = -EINVAL; ditto. unregister_parent_dev_notifier(struct devfreq_passive_data **p_data) > break; > default: > break; > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h > index a4b19d593151..04ce576fd6f1 100644 > --- a/include/linux/devfreq.h > +++ b/include/linux/devfreq.h > @@ -278,6 +278,32 @@ struct devfreq_simple_ondemand_data { > > #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE) > /** > + * struct devfreq_cpu_state - holds the per-cpu state > + * @freq: the current frequency of the cpu. > + * @min_freq: the min frequency of the cpu. > + * @max_freq: the max frequency of the cpu. > + * @first_cpu: the cpumask of the first cpu of a policy. > + * @dev: reference to cpu device. > + * @opp_table: reference to cpu opp table. > + * > + * This structure stores the required cpu_state of a cpu. > + * This is auto-populated by the governor. > + */ > +struct devfreq_cpu_state {> + unsigned int freq; It is better to change from 'freq' to 'curr_freq' for more correct expression. > + unsigned int min_freq; > + unsigned int max_freq; > + unsigned int first_cpu; > + struct device *dev; How about changing the name 'dev' to 'cpu_dev'? > + struct opp_table *opp_table; > +}; devfreq_cpu_state is only handled by within driver/devfreq/governor_passive.c. So, you can move it into drivers/devfreq/governor_passive.c and just add the definition into include/linux/devfreq.h as following: It is able to prevent the access of variable of 'struct devfreq_cpu_state' outside. struct devfreq_cpu_state; > + > +enum devfreq_parent_dev_type { > + DEVFREQ_PARENT_DEV, > + CPUFREQ_PARENT_DEV, > +}; > + > +/** > * struct devfreq_passive_data - ``void *data`` fed to struct devfreq > * and devfreq_add_device > * @parent: the devfreq instance of parent device. > @@ -288,13 +314,15 @@ struct devfreq_simple_ondemand_data { > * using governors except for passive governor. > * If the devfreq device has the specific method to decide > * the next frequency, should use this callback. > - * @this: the devfreq instance of own device. > - * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list > + * @parent_type parent type of the device Need to add ':' at the end of word. -> "parent_type:". > + * @this: the devfreq instance of own device. > + * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list I knew that you make them with same indentation. But, actually, it is not related to this patch like clean-up code. Even if it is not pretty, you better to don't touch 'this' and 'nb' indentaion. > + * @cpu_state: the state min/max/current frequency of all online cpu's > * > * The devfreq_passive_data have to set the devfreq instance of parent > * device with governors except for the passive governor. But, don't need to > - * initialize the 'this' and 'nb' field because the devfreq core will handle > - * them. > + * initialize the 'this', 'nb' and 'cpu_state' field because the devfreq core > + * will handle them. > */ > struct devfreq_passive_data { > /* Should set the devfreq instance of parent device */ > @@ -303,9 +331,13 @@ struct devfreq_passive_data { > /* Optional callback to decide the next frequency of passvice device */ > int (*get_target_freq)(struct devfreq *this, unsigned long *freq); > > + /* Should set the type of parent device */ > + enum devfreq_parent_dev_type parent_type; > + > /* For passive governor's internal use. Don't need to set them */ > struct devfreq *this; > struct notifier_block nb; > + struct devfreq_cpu_state *cpu_state[NR_CPUS]; > }; > #endif > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor 2020-05-28 6:14 ` Chanwoo Choi @ 2020-05-28 7:17 ` Chanwoo Choi [not found] ` <1591100614.1804.1.camel@mtksdaap41> [not found] ` <1591098190.30729.15.camel@mtksdaap41> 1 sibling, 1 reply; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 7:17 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Sibi Sankar Hi Andrew-sh.Cheng, The exynos-bus.c used the passive governor. Even if don't make the problem because DEVFREQ_PARENT_DEV is zero, you need to initialize the parent_type with DEVFREQ_PARENT_DEV as following: diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c index 8fa8eb541373..1c71c47bc2ac 100644 --- a/drivers/devfreq/exynos-bus.c +++ b/drivers/devfreq/exynos-bus.c @@ -369,6 +369,7 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus, return -ENOMEM; passive_data->parent = parent_devfreq; + passive_data->parent_type = DEVFREQ_PARENT_DEV; /* Add devfreq device for exynos bus with passive governor */ bus->devfreq = devm_devfreq_add_device(dev, profile, DEVFREQ_GOV_PASSIVE, On 5/28/20 3:14 PM, Chanwoo Choi wrote: > Hi Andrew-sh.Cheng, > > Thanks for your posting. I like this approach absolutely. > I think that it is necessary. When I developed the embedded product, > I needed this feature always. > > I add the comments on below. > > > And the following email is not valid. So, I dropped this email > from Cc list. > Saravana Kannan <skannan@codeaurora.org> > > > On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: >> From: Saravana Kannan <skannan@codeaurora.org> >> >> Many CPU architectures have caches that can scale independent of the >> CPUs. Frequency scaling of the caches is necessary to make sure that the >> cache is not a performance bottleneck that leads to poor performance and >> power. The same idea applies for RAM/DDR. >> >> To achieve this, this patch adds support for cpu based scaling to the >> passive governor. This is accomplished by taking the current frequency >> of each CPU frequency domain and then adjust the frequency of the cache >> (or any devfreq device) based on the frequency of the CPUs. It listens >> to CPU frequency transition notifiers to keep itself up to date on the >> current CPU frequency. >> >> To decide the frequency of the device, the governor does one of the >> following: >> * Derives the optimal devfreq device opp from required-opps property of >> the parent cpu opp_table. >> >> * Scales the device frequency in proportion to the CPU frequency. So, if >> the CPUs are running at their max frequency, the device runs at its >> max frequency. If the CPUs are running at their min frequency, the >> device runs at its min frequency. It is interpolated for frequencies >> in between. >> >> Andrew-sh.Cheng change >> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq >> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value >> for kernel-5.7 >> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >> [Sibi: Integrated cpu-freqmap governor into passive_governor] >> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> >> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> >> --- >> drivers/devfreq/Kconfig | 2 + >> drivers/devfreq/governor_passive.c | 278 ++++++++++++++++++++++++++++++++++--- >> include/linux/devfreq.h | 40 +++++- >> 3 files changed, 299 insertions(+), 21 deletions(-) >> >> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >> index 0b1df12e0f21..d9067950af6a 100644 >> --- a/drivers/devfreq/Kconfig >> +++ b/drivers/devfreq/Kconfig >> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE >> device. This governor does not change the frequency by itself >> through sysfs entries. The passive governor recommends that >> devfreq device uses the OPP table to get the frequency/voltage. >> + Alternatively the governor can also be chosen to scale based on >> + the online CPUs current frequency. >> >> comment "DEVFREQ Drivers" >> >> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c >> index 2d67d6c12dce..7dcda02a5bb7 100644 >> --- a/drivers/devfreq/governor_passive.c >> +++ b/drivers/devfreq/governor_passive.c >> @@ -8,11 +8,89 @@ >> */ >> >> #include <linux/module.h> >> +#include <linux/cpu.h> >> +#include <linux/cpufreq.h> >> +#include <linux/cpumask.h> >> #include <linux/device.h> >> #include <linux/devfreq.h> >> +#include <linux/slab.h> >> #include "governor.h" >> >> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data, > > Need to change 'unsigned int' to 'unsigned long'. > >> + unsigned int cpu) >> +{ >> + unsigned int cpu_min, cpu_max, dev_min, dev_max, cpu_percent, max_state; > > Better to define them separately as following and then need to rename > the variable. Usually, use the 'min_freq' and 'max_freq' word for > the minimum/maximum frequency. > > unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq, cpu_percent; > unsigned long dev_min_freq, dev_max_freq, dev_max_state, > > The devfreq used 'unsigned long'. The cpufreq used 'unsigned long' > and 'unsigned int'. You need to handle them properly. > > >> + struct devfreq_cpu_state *cpu_state = data->cpu_state[cpu]; >> + struct devfreq *devfreq = (struct devfreq *)data->this; >> + unsigned long *freq_table = devfreq->profile->freq_table; > > In this function, use 'cpu' work for cpufreq and use 'dev' for devfreq. > So, I think 'dev_freq_table' is proper name instead of 'freq_table' > for the readability. > > freq_table -> dev_freq_table > >> + struct dev_pm_opp *opp = NULL, *cpu_opp = NULL; > > In the get_target_freq_with_devfreq(), use 'p_opp' indicating > the OPP of parent device. For the consistency, I think that > use 'p_opp' instead of 'cpu_opp'. > >> + unsigned long cpu_freq, freq; > > Define the 'cpu_freq' on above with cpu_min_freq/cpu_max_freq definition. > cpu_freq -> cpu_curr_freq. > >> + >> + if (!cpu_state || cpu_state->first_cpu != cpu || >> + !cpu_state->opp_table || !devfreq->opp_table) >> + return 0; >> + >> + cpu_freq = cpu_state->freq * 1000; >> + cpu_opp = devfreq_recommended_opp(cpu_state->dev, &cpu_freq, 0); >> + if (IS_ERR(cpu_opp)) >> + return 0; >> + >> + opp = dev_pm_opp_xlate_required_opp(cpu_state->opp_table, >> + devfreq->opp_table, cpu_opp); >> + dev_pm_opp_put(cpu_opp); >> + >> + if (!IS_ERR(opp)) { >> + freq = dev_pm_opp_get_freq(opp); >> + dev_pm_opp_put(opp); > > Better to add the 'out' goto statement. > If you use 'goto out', you can reduce the one indentation > without 'else' statement. > > >> + } else { > > As I commented, when dev_pm_opp_xlate_required_opp() return successfully > , use 'goto out'. We can remove 'else' and then reduce the unneeded indentation. > > >> + /* Use Interpolation if required opps is not available */ >> + cpu_min = cpu_state->min_freq; >> + cpu_max = cpu_state->max_freq; >> + cpu_freq = cpu_state->freq; >> + >> + if (freq_table) { >> + /* Get minimum frequency according to sorting order */ >> + max_state = freq_table[devfreq->profile->max_state - 1]; >> + if (freq_table[0] < max_state) { >> + dev_min = freq_table[0]; >> + dev_max = max_state; >> + } else { >> + dev_min = max_state; >> + dev_max = freq_table[0]; >> + } >> + } else { >> + if (devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value >> + <= devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value) >> + return 0; >> + dev_min = >> + devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value; >> + dev_max = >> + devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value; > > I think it is not proper to access the variable of pm_qos structure directly. > Instead of direct access, you have to use the exported PM QoS function such as > - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MIN_FREQUENCY); > - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MAX_FREQUENCY); > >> + } >> + cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min; >> + freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100); >> + } > > > I think that you better to add 'out' jump label as following: > > out: > >> + >> + return freq; >> +} >> + >> +static int get_target_freq_with_cpufreq(struct devfreq *devfreq, >> + unsigned long *freq) >> +{ >> + struct devfreq_passive_data *p_data = >> + (struct devfreq_passive_data *)devfreq->data; >> + unsigned int cpu, target_freq = 0; > > Need to define 'target_freq' with 'unsigned long' type. > >> + >> + for_each_online_cpu(cpu) >> + target_freq = max(target_freq, >> + xlate_cpufreq_to_devfreq(p_data, cpu)); >> + >> + *freq = target_freq; >> + >> + return 0; >> +} >> + >> +static int get_target_freq_with_devfreq(struct devfreq *devfreq, >> unsigned long *freq) >> { >> struct devfreq_passive_data *p_data >> @@ -23,16 +101,6 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >> int i, count, ret = 0; >> >> /* >> - * If the devfreq device with passive governor has the specific method >> - * to determine the next frequency, should use the get_target_freq() >> - * of struct devfreq_passive_data. >> - */ >> - if (p_data->get_target_freq) { >> - ret = p_data->get_target_freq(devfreq, freq); >> - goto out; >> - } >> - >> - /* >> * If the parent and passive devfreq device uses the OPP table, >> * get the next frequency by using the OPP table. >> */ >> @@ -102,6 +170,37 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >> return ret; >> } >> >> +static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >> + unsigned long *freq) >> +{ >> + struct devfreq_passive_data *p_data = >> + (struct devfreq_passive_data *)devfreq->data; >> + int ret; >> + >> + /* >> + * If the devfreq device with passive governor has the specific method >> + * to determine the next frequency, should use the get_target_freq() >> + * of struct devfreq_passive_data. >> + */ >> + if (p_data->get_target_freq) >> + return p_data->get_target_freq(devfreq, freq); >> + >> + switch (p_data->parent_type) { >> + case DEVFREQ_PARENT_DEV: >> + ret = get_target_freq_with_devfreq(devfreq, freq); >> + break; >> + case CPUFREQ_PARENT_DEV: >> + ret = get_target_freq_with_cpufreq(devfreq, freq); >> + break; >> + default: >> + ret = -EINVAL; >> + dev_err(&devfreq->dev, "Invalid parent type\n"); >> + break; >> + } >> + >> + return ret; >> +} >> + >> static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq) >> { >> int ret; >> @@ -156,6 +255,140 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb, >> return NOTIFY_DONE; >> } >> >> +static int cpufreq_passive_notifier_call(struct notifier_block *nb, >> + unsigned long event, void *ptr) >> +{ >> + struct devfreq_passive_data *data = >> + container_of(nb, struct devfreq_passive_data, nb); >> + struct devfreq *devfreq = (struct devfreq *)data->this; >> + struct devfreq_cpu_state *cpu_state; >> + struct cpufreq_freqs *freq = ptr; > > How about changing 'freq' to 'cpu_freqs'? > > In the drivers/cpufreq/cpufreq.c, use 'freqs' name indicating > the instance of 'struct cpufreq_freqs'. And in order to > identfy, how about adding 'cpu_' prefix for variable name? > >> + unsigned int current_freq; > > Need to define curr_freq with 'unsigned long' type > and better to use 'curr_freq' variable name. > >> + int ret; >> + >> + if (event != CPUFREQ_POSTCHANGE || !freq || >> + !data->cpu_state[freq->policy->cpu]) >> + return 0; >> + >> + cpu_state = data->cpu_state[freq->policy->cpu]; >> + if (cpu_state->freq == freq->new) >> + return 0; >> + >> + /* Backup current freq and pre-update cpu state freq*/ >> + current_freq = cpu_state->freq; >> + cpu_state->freq = freq->new; >> + >> + mutex_lock(&devfreq->lock); >> + ret = update_devfreq(devfreq); >> + mutex_unlock(&devfreq->lock); >> + if (ret) { >> + cpu_state->freq = current_freq; >> + dev_err(&devfreq->dev, "Couldn't update the frequency.\n"); >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int cpufreq_passive_register(struct devfreq_passive_data **p_data) >> +{ >> + struct devfreq_passive_data *data = *p_data; >> + struct devfreq *devfreq = (struct devfreq *)data->this; >> + struct device *dev = devfreq->dev.parent; >> + struct opp_table *opp_table = NULL; >> + struct devfreq_cpu_state *state; > > For the readability, I thinkt 'cpu_state' is proper instead of 'state'. > >> + struct cpufreq_policy *policy; >> + struct device *cpu_dev; >> + unsigned int cpu; >> + int ret; >> + >> + get_online_cpus(); > > Add blank line. > >> + data->nb.notifier_call = cpufreq_passive_notifier_call; >> + ret = cpufreq_register_notifier(&data->nb, >> + CPUFREQ_TRANSITION_NOTIFIER); >> + if (ret) { >> + dev_err(dev, "Couldn't register cpufreq notifier.\n"); >> + data->nb.notifier_call = NULL; >> + goto out; >> + } >> + >> + /* Populate devfreq_cpu_state */ >> + for_each_online_cpu(cpu) { >> + if (data->cpu_state[cpu]) >> + continue; >> + >> + policy = cpufreq_cpu_get(cpu); > > cpufreq_cpu_get() might return 'NULL'. I think you need to handle > return value as following: > > if (!policy) { > ret = -EINVAL; > goto out; > } else if (PTR_ERR(policy) == -EPROBE_DEFER) { > goto out; > } else if (IS_ERR(policy) { > ret = PTR_ERR(policy); > dev_err(dev, "Couldn't get the cpufreq_poliy.\n"); > goto out; > } > > If cpufreq_cpu_get() return successfully, to do next. > It reduces the one indentaion. > > > >> + if (policy) { >> + state = kzalloc(sizeof(*state), GFP_KERNEL); >> + if (!state) { >> + ret = -ENOMEM; >> + goto out; >> + } >> + >> + cpu_dev = get_cpu_device(cpu); >> + if (!cpu_dev) { >> + dev_err(dev, "Couldn't get cpu device.\n"); >> + ret = -ENODEV; >> + goto out; >> + } >> + >> + opp_table = dev_pm_opp_get_opp_table(cpu_dev); >> + if (IS_ERR(devfreq->opp_table)) { >> + ret = PTR_ERR(opp_table); >> + goto out; >> + } >> + >> + state->dev = cpu_dev; >> + state->opp_table = opp_table; >> + state->first_cpu = cpumask_first(policy->related_cpus); >> + state->freq = policy->cur; >> + state->min_freq = policy->cpuinfo.min_freq; >> + state->max_freq = policy->cpuinfo.max_freq; >> + data->cpu_state[cpu] = state; > > Add blank line. > >> + cpufreq_cpu_put(policy); >> + } else { >> + ret = -EPROBE_DEFER; >> + goto out; >> + } >> + } > > Add blank line. > >> +out: >> + put_online_cpus(); >> + if (ret) >> + return ret; >> + >> + /* Update devfreq */ >> + mutex_lock(&devfreq->lock); >> + ret = update_devfreq(devfreq); >> + mutex_unlock(&devfreq->lock); >> + if (ret) >> + dev_err(dev, "Couldn't update the frequency.\n"); >> + >> + return ret; >> +} >> + >> +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data) >> +{ >> + struct devfreq_passive_data *data = *p_data; >> + struct devfreq_cpu_state *cpu_state; >> + int cpu; >> + >> + if (data->nb.notifier_call) >> + cpufreq_unregister_notifier(&data->nb, >> + CPUFREQ_TRANSITION_NOTIFIER); >> + >> + for_each_possible_cpu(cpu) { >> + cpu_state = data->cpu_state[cpu]; >> + if (cpu_state) { >> + if (cpu_state->opp_table) >> + dev_pm_opp_put_opp_table(cpu_state->opp_table); >> + kfree(cpu_state); >> + cpu_state = NULL; >> + } >> + } >> + >> + return 0; >> +} >> + >> static int devfreq_passive_event_handler(struct devfreq *devfreq, >> unsigned int event, void *data) >> { >> @@ -165,7 +398,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, >> struct notifier_block *nb = &p_data->nb; >> int ret = 0; >> >> - if (!parent) >> + if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent) >> return -EPROBE_DEFER; > > If you modify the devfreq_passive_event_handler() as following, > you can move this condition for DEVFREQ_PARENT_DEV into > (register|unregister)_parent_dev_notifier. > > switch (event) { > case DEVFREQ_GOV_START: > ret = register_parent_dev_notifier(p_data); > break; > case DEVFREQ_GOV_STOP: > ret = unregister_parent_dev_notifier(p_data); > break; > default: > ret = -EINVAL; > break; > } > > return ret; > >> >> switch (event) { >> @@ -173,13 +406,24 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, >> if (!p_data->this) >> p_data->this = devfreq; >> >> - nb->notifier_call = devfreq_passive_notifier_call; >> - ret = devfreq_register_notifier(parent, nb, >> - DEVFREQ_TRANSITION_NOTIFIER); >> + if (p_data->parent_type == DEVFREQ_PARENT_DEV) { >> + nb->notifier_call = devfreq_passive_notifier_call; >> + ret = devfreq_register_notifier(parent, nb, >> + DEVFREQ_TRANSITION_NOTIFIER); >> + } else if (p_data->parent_type == CPUFREQ_PARENT_DEV) { >> + ret = cpufreq_passive_register(&p_data); > > I think that we better to collect the code related to notifier registration > into one function like devfreq_pass_register_notifier() instead of > cpufreq_passive_register() as following: I think it is more simple and readable. > > If you have more proper function name of register_parent_dev_notifier, > please give your opinion. > > > int register_parent_dev_notifier(struct devfreq_passive_data **p_data) > switch (p_data->parent_type) { > case DEVFREQ_PARENT_DEV: > nb->notifier_call = devfreq_passive_notifier_call; > ret = devfreq_register_notifier(parent, nb, > break; > case CPUFREQ_PARENT_DEV: > cpufreq_register_notifier(...) > ... > break; > } > > >> + } else { >> + ret = -EINVAL; >> + } >> break; >> case DEVFREQ_GOV_STOP: >> - WARN_ON(devfreq_unregister_notifier(parent, nb, >> - DEVFREQ_TRANSITION_NOTIFIER)); >> + if (p_data->parent_type == DEVFREQ_PARENT_DEV) >> + WARN_ON(devfreq_unregister_notifier(parent, nb, >> + DEVFREQ_TRANSITION_NOTIFIER)); >> + else if (p_data->parent_type == CPUFREQ_PARENT_DEV) >> + cpufreq_passive_unregister(&p_data); >> + else >> + ret = -EINVAL; > > ditto. unregister_parent_dev_notifier(struct devfreq_passive_data **p_data) > >> break; >> default: >> break; >> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h >> index a4b19d593151..04ce576fd6f1 100644 >> --- a/include/linux/devfreq.h >> +++ b/include/linux/devfreq.h >> @@ -278,6 +278,32 @@ struct devfreq_simple_ondemand_data { >> >> #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE) >> /** >> + * struct devfreq_cpu_state - holds the per-cpu state >> + * @freq: the current frequency of the cpu. >> + * @min_freq: the min frequency of the cpu. >> + * @max_freq: the max frequency of the cpu. >> + * @first_cpu: the cpumask of the first cpu of a policy. >> + * @dev: reference to cpu device. >> + * @opp_table: reference to cpu opp table. >> + * >> + * This structure stores the required cpu_state of a cpu. >> + * This is auto-populated by the governor. >> + */ >> +struct devfreq_cpu_state {> + unsigned int freq; > > It is better to change from 'freq' to 'curr_freq' > for more correct expression. > >> + unsigned int min_freq; >> + unsigned int max_freq; >> + unsigned int first_cpu; >> + struct device *dev; > > How about changing the name 'dev' to 'cpu_dev'? > > >> + struct opp_table *opp_table; >> +}; > > devfreq_cpu_state is only handled by within driver/devfreq/governor_passive.c. > > So, you can move it into drivers/devfreq/governor_passive.c > and just add the definition into include/linux/devfreq.h as following: > It is able to prevent the access of variable of 'struct devfreq_cpu_state' > outside. > > struct devfreq_cpu_state; > >> + >> +enum devfreq_parent_dev_type { >> + DEVFREQ_PARENT_DEV, >> + CPUFREQ_PARENT_DEV, >> +}; >> + >> +/** >> * struct devfreq_passive_data - ``void *data`` fed to struct devfreq >> * and devfreq_add_device >> * @parent: the devfreq instance of parent device. >> @@ -288,13 +314,15 @@ struct devfreq_simple_ondemand_data { >> * using governors except for passive governor. >> * If the devfreq device has the specific method to decide >> * the next frequency, should use this callback. >> - * @this: the devfreq instance of own device. >> - * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list >> + * @parent_type parent type of the device > > Need to add ':' at the end of word. -> "parent_type:". > >> + * @this: the devfreq instance of own device. >> + * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list > > I knew that you make them with same indentation. > But, actually, it is not related to this patch like clean-up code. > Even if it is not pretty, you better to don't touch 'this' and 'nb' indentaion. > >> + * @cpu_state: the state min/max/current frequency of all online cpu's >> * >> * The devfreq_passive_data have to set the devfreq instance of parent >> * device with governors except for the passive governor. But, don't need to >> - * initialize the 'this' and 'nb' field because the devfreq core will handle >> - * them. >> + * initialize the 'this', 'nb' and 'cpu_state' field because the devfreq core >> + * will handle them. >> */ >> struct devfreq_passive_data { >> /* Should set the devfreq instance of parent device */ >> @@ -303,9 +331,13 @@ struct devfreq_passive_data { >> /* Optional callback to decide the next frequency of passvice device */ >> int (*get_target_freq)(struct devfreq *this, unsigned long *freq); >> >> + /* Should set the type of parent device */ >> + enum devfreq_parent_dev_type parent_type; >> + >> /* For passive governor's internal use. Don't need to set them */ >> struct devfreq *this; >> struct notifier_block nb; >> + struct devfreq_cpu_state *cpu_state[NR_CPUS]; >> }; >> #endif >> >> > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply related [flat|nested] 15+ messages in thread
[parent not found: <1591100614.1804.1.camel@mtksdaap41>]
* Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor [not found] ` <1591100614.1804.1.camel@mtksdaap41> @ 2020-06-03 4:12 ` Chanwoo Choi 0 siblings, 0 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-06-03 4:12 UTC (permalink / raw) To: andrew-sh.cheng Cc: MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown, devicetree, srv_heupstream, linux-pm, linux-kernel, linux-mediatek, Sibi Sankar, linux-arm-kernel Hi Andrew-sh.Cheng, On 6/2/20 9:23 PM, andrew-sh.cheng wrote: > On Thu, 2020-05-28 at 16:17 +0900, Chanwoo Choi wrote: >> Hi Andrew-sh.Cheng, >> >> The exynos-bus.c used the passive governor. >> Even if don't make the problem because DEVFREQ_PARENT_DEV is zero, >> you need to initialize the parent_type with DEVFREQ_PARENT_DEV as following: >> >> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c >> index 8fa8eb541373..1c71c47bc2ac 100644 >> --- a/drivers/devfreq/exynos-bus.c >> +++ b/drivers/devfreq/exynos-bus.c >> @@ -369,6 +369,7 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus, >> return -ENOMEM; >> >> passive_data->parent = parent_devfreq; >> + passive_data->parent_type = DEVFREQ_PARENT_DEV; >> >> /* Add devfreq device for exynos bus with passive governor */ >> bus->devfreq = devm_devfreq_add_device(dev, profile, DEVFREQ_GOV_PASSIVE, > Hi Chanwoo Choi, > Do you just remind me to initialize it to DEVFREQ_PARENT_DEV whn use > this governor? Yes. This change was not included in this patchset. > I will do it and thank you for reminding. Thanks. (snip) And, this patchset doesn't include the dt-binding example and any real example in devicetree. If possible, I recommend you better to update dt-binding document with example. -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <1591098190.30729.15.camel@mtksdaap41>]
* Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor [not found] ` <1591098190.30729.15.camel@mtksdaap41> @ 2020-06-03 4:07 ` Chanwoo Choi 0 siblings, 0 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-06-03 4:07 UTC (permalink / raw) To: andrew-sh.cheng Cc: MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown, devicetree, srv_heupstream, linux-pm, linux-kernel, linux-mediatek, Sibi Sankar, linux-arm-kernel Hi Andrew-sh.Cheng, Do you know that why cannot show the patches sent from you on mailing list? Even if you sent them to linux-pm mailing list, I cannot find your patches on linux-pm's patchwork[1] and others. [1] https://patchwork.kernel.org/project/linux-pm/list/ Could you find you patch on mailing list? Do you use git send-email when you send these patches? I used the thunderbird tool and gmail for reading the patches. When I tried to read the original source of this patch, it looks like that the body of patch is encoded. I cannot read the plain text of patch body. - When gmail, use 'Show original' - When thunderbird, use 'More -> View Source' If I'm missing something to check this patch, please let me know. I'll fix my environment. It is strange situation on my case. On 6/2/20 8:43 PM, andrew-sh.cheng wrote: > On Thu, 2020-05-28 at 15:14 +0900, Chanwoo Choi wrote: >> Hi Andrew-sh.Cheng, >> >> Thanks for your posting. I like this approach absolutely. >> I think that it is necessary. When I developed the embedded product, >> I needed this feature always. >> >> I add the comments on below. >> >> >> And the following email is not valid. So, I dropped this email >> from Cc list. >> Saravana Kannan <skannan@codeaurora.org> >> >> >> On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: >>> From: Saravana Kannan <skannan@codeaurora.org> >>> >>> Many CPU architectures have caches that can scale independent of the >>> CPUs. Frequency scaling of the caches is necessary to make sure that the >>> cache is not a performance bottleneck that leads to poor performance and >>> power. The same idea applies for RAM/DDR. >>> >>> To achieve this, this patch adds support for cpu based scaling to the >>> passive governor. This is accomplished by taking the current frequency >>> of each CPU frequency domain and then adjust the frequency of the cache >>> (or any devfreq device) based on the frequency of the CPUs. It listens >>> to CPU frequency transition notifiers to keep itself up to date on the >>> current CPU frequency. >>> >>> To decide the frequency of the device, the governor does one of the >>> following: >>> * Derives the optimal devfreq device opp from required-opps property of >>> the parent cpu opp_table. >>> >>> * Scales the device frequency in proportion to the CPU frequency. So, if >>> the CPUs are running at their max frequency, the device runs at its >>> max frequency. If the CPUs are running at their min frequency, the >>> device runs at its min frequency. It is interpolated for frequencies >>> in between. >>> >>> Andrew-sh.Cheng change >>> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq >>> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value >>> for kernel-5.7 >>> >>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>> [Sibi: Integrated cpu-freqmap governor into passive_governor] >>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> >>> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> >>> --- >>> drivers/devfreq/Kconfig | 2 + >>> drivers/devfreq/governor_passive.c | 278 ++++++++++++++++++++++++++++++++++--- >>> include/linux/devfreq.h | 40 +++++- >>> 3 files changed, 299 insertions(+), 21 deletions(-) >>> >>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >>> index 0b1df12e0f21..d9067950af6a 100644 >>> --- a/drivers/devfreq/Kconfig >>> +++ b/drivers/devfreq/Kconfig >>> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE >>> device. This governor does not change the frequency by itself >>> through sysfs entries. The passive governor recommends that >>> devfreq device uses the OPP table to get the frequency/voltage. >>> + Alternatively the governor can also be chosen to scale based on >>> + the online CPUs current frequency. >>> >>> comment "DEVFREQ Drivers" >>> >>> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c >>> index 2d67d6c12dce..7dcda02a5bb7 100644 >>> --- a/drivers/devfreq/governor_passive.c >>> +++ b/drivers/devfreq/governor_passive.c >>> @@ -8,11 +8,89 @@ >>> */ >>> >>> #include <linux/module.h> >>> +#include <linux/cpu.h> >>> +#include <linux/cpufreq.h> >>> +#include <linux/cpumask.h> >>> #include <linux/device.h> >>> #include <linux/devfreq.h> >>> +#include <linux/slab.h> >>> #include "governor.h" >>> >>> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >>> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data, >> >> Need to change 'unsigned int' to 'unsigned long' > Get it. If you add the blank line before/after of your reply, it is better to catch your reply. Please add the blank line for me. >> . >> >>> + unsigned int cpu) >>> +{ >>> + unsigned int cpu_min, cpu_max, dev_min, dev_max, cpu_percent, max_state; >> >> Better to define them separately as following and then need to rename >> the variable. Usually, use the 'min_freq' and 'max_freq' word for >> the minimum/maximum frequency. >> >> unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq, cpu_percent; >> unsigned long dev_min_freq, dev_max_freq, dev_max_state, >> >> The devfreq used 'unsigned long'. The cpufreq used 'unsigned long' >> and 'unsigned int'. You need to handle them properly. > Get it. > For cpu_freq, I separate it into "unsigned long cpu_curr_freq" and > "unsigned int cpu_curr_freq_khz" >> >> >>> + struct devfreq_cpu_state *cpu_state = data->cpu_state[cpu]; >>> + struct devfreq *devfreq = (struct devfreq *)data->this; >>> + unsigned long *freq_table = devfreq->profile->freq_table; >> >> In this function, use 'cpu' work for cpufreq and use 'dev' for devfreq. >> So, I think 'dev_freq_table' is proper name instead of 'freq_table' >> for the readability. >> >> freq_table -> dev_freq_table >> >>> + struct dev_pm_opp *opp = NULL, *cpu_opp = NULL; >> >> In the get_target_freq_with_devfreq(), use 'p_opp' indicating >> the OPP of parent device. For the consistency, I think that >> use 'p_opp' instead of 'cpu_opp'. >> >>> + unsigned long cpu_freq, freq; >> >> Define the 'cpu_freq' on above with cpu_min_freq/cpu_max_freq definition. >> cpu_freq -> cpu_curr_freq. > Get it. > Will modify them for readability. >> >>> + >>> + if (!cpu_state || cpu_state->first_cpu != cpu || >>> + !cpu_state->opp_table || !devfreq->opp_table) >>> + return 0; >>> + >>> + cpu_freq = cpu_state->freq * 1000; >>> + cpu_opp = devfreq_recommended_opp(cpu_state->dev, &cpu_freq, 0); >>> + if (IS_ERR(cpu_opp)) >>> + return 0; >>> + >>> + opp = dev_pm_opp_xlate_required_opp(cpu_state->opp_table, >>> + devfreq->opp_table, cpu_opp); >>> + dev_pm_opp_put(cpu_opp); >>> + >>> + if (!IS_ERR(opp)) { >>> + freq = dev_pm_opp_get_freq(opp); >>> + dev_pm_opp_put(opp); >> >> Better to add the 'out' goto statement. >> If you use 'goto out', you can reduce the one indentation >> without 'else' statement. > Get it. >> >> >>> + } else { >> >> As I commented, when dev_pm_opp_xlate_required_opp() return successfully >> , use 'goto out'. We can remove 'else' and then reduce the unneeded indentation. >> >> >>> + /* Use Interpolation if required opps is not available */ >>> + cpu_min = cpu_state->min_freq; >>> + cpu_max = cpu_state->max_freq; >>> + cpu_freq = cpu_state->freq; >>> + >>> + if (freq_table) { >>> + /* Get minimum frequency according to sorting order */ >>> + max_state = freq_table[devfreq->profile->max_state - 1]; >>> + if (freq_table[0] < max_state) { >>> + dev_min = freq_table[0]; >>> + dev_max = max_state; >>> + } else { >>> + dev_min = max_state; >>> + dev_max = freq_table[0]; >>> + } >>> + } else { >>> + if (devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value >>> + <= devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value) >>> + return 0; >>> + dev_min = >>> + devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value; >>> + dev_max = >>> + devfreq->user_max_freq_req.data.freq.qos->max_freq.target_value; >> >> I think it is not proper to access the variable of pm_qos structure directly. >> Instead of direct access, you have to use the exported PM QoS function such as >> - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MIN_FREQUENCY); >> - pm_qos_read_value(devfreq->dev.parent, DEV_PM_QOS_MAX_FREQUENCY); > Get it. >> >>> + } >>> + cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min; >>> + freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100); >>> + } >> >> >> I think that you better to add 'out' jump label as following: >> >> out: >> >>> + >>> + return freq; >>> +} >>> + >>> +static int get_target_freq_with_cpufreq(struct devfreq *devfreq, >>> + unsigned long *freq) >>> +{ >>> + struct devfreq_passive_data *p_data = >>> + (struct devfreq_passive_data *)devfreq->data; >>> + unsigned int cpu, target_freq = 0; >> >> Need to define 'target_freq' with 'unsigned long' type. > Get it. >> >>> + >>> + for_each_online_cpu(cpu) >>> + target_freq = max(target_freq, >>> + xlate_cpufreq_to_devfreq(p_data, cpu)); >>> + >>> + *freq = target_freq; >>> + >>> + return 0; >>> +} >>> + >>> +static int get_target_freq_with_devfreq(struct devfreq *devfreq, >>> unsigned long *freq) >>> { >>> struct devfreq_passive_data *p_data >>> @@ -23,16 +101,6 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >>> int i, count, ret = 0; >>> >>> /* >>> - * If the devfreq device with passive governor has the specific method >>> - * to determine the next frequency, should use the get_target_freq() >>> - * of struct devfreq_passive_data. >>> - */ >>> - if (p_data->get_target_freq) { >>> - ret = p_data->get_target_freq(devfreq, freq); >>> - goto out; >>> - } >>> - >>> - /* >>> * If the parent and passive devfreq device uses the OPP table, >>> * get the next frequency by using the OPP table. >>> */ >>> @@ -102,6 +170,37 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >>> return ret; >>> } >>> >>> +static int devfreq_passive_get_target_freq(struct devfreq *devfreq, >>> + unsigned long *freq) >>> +{ >>> + struct devfreq_passive_data *p_data = >>> + (struct devfreq_passive_data *)devfreq->data; >>> + int ret; >>> + >>> + /* >>> + * If the devfreq device with passive governor has the specific method >>> + * to determine the next frequency, should use the get_target_freq() >>> + * of struct devfreq_passive_data. >>> + */ >>> + if (p_data->get_target_freq) >>> + return p_data->get_target_freq(devfreq, freq); >>> + >>> + switch (p_data->parent_type) { >>> + case DEVFREQ_PARENT_DEV: >>> + ret = get_target_freq_with_devfreq(devfreq, freq); >>> + break; >>> + case CPUFREQ_PARENT_DEV: >>> + ret = get_target_freq_with_cpufreq(devfreq, freq); >>> + break; >>> + default: >>> + ret = -EINVAL; >>> + dev_err(&devfreq->dev, "Invalid parent type\n"); >>> + break; >>> + } >>> + >>> + return ret; >>> +} >>> + >>> static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq) >>> { >>> int ret; >>> @@ -156,6 +255,140 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb, >>> return NOTIFY_DONE; >>> } >>> >>> +static int cpufreq_passive_notifier_call(struct notifier_block *nb, >>> + unsigned long event, void *ptr) >>> +{ >>> + struct devfreq_passive_data *data = >>> + container_of(nb, struct devfreq_passive_data, nb); >>> + struct devfreq *devfreq = (struct devfreq *)data->this; >>> + struct devfreq_cpu_state *cpu_state; >>> + struct cpufreq_freqs *freq = ptr; >> >> How about changing 'freq' to 'cpu_freqs'? >> >> In the drivers/cpufreq/cpufreq.c, use 'freqs' name indicating >> the instance of 'struct cpufreq_freqs'. And in order to >> identfy, how about adding 'cpu_' prefix for variable name? >> >>> + unsigned int current_freq; >> >> Need to define curr_freq with 'unsigned long' type >> and better to use 'curr_freq' variable name. > It is good to change current_freq to curr_freq, but why should it us > 'unsigned long'? > I think it is 'unsigned int'. I think that 'curr_freq' is proper. Yes, it is 'unsigned int'. When you changing the cpu frequency to device frequency, recommend to handle them between unsigned int and unsigned long. >> >>> + int ret; >>> + >>> + if (event != CPUFREQ_POSTCHANGE || !freq || >>> + !data->cpu_state[freq->policy->cpu]) >>> + return 0; >>> + >>> + cpu_state = data->cpu_state[freq->policy->cpu]; >>> + if (cpu_state->freq == freq->new) >>> + return 0; >>> + >>> + /* Backup current freq and pre-update cpu state freq*/ >>> + current_freq = cpu_state->freq; >>> + cpu_state->freq = freq->new; >>> + >>> + mutex_lock(&devfreq->lock); >>> + ret = update_devfreq(devfreq); >>> + mutex_unlock(&devfreq->lock); >>> + if (ret) { >>> + cpu_state->freq = current_freq; >>> + dev_err(&devfreq->dev, "Couldn't update the frequency.\n"); >>> + return ret; >>> + } >>> + >>> + return 0; >>> +} >>> + >>> +static int cpufreq_passive_register(struct devfreq_passive_data **p_data) >>> +{ >>> + struct devfreq_passive_data *data = *p_data; >>> + struct devfreq *devfreq = (struct devfreq *)data->this; >>> + struct device *dev = devfreq->dev.parent; >>> + struct opp_table *opp_table = NULL; >>> + struct devfreq_cpu_state *state; >> >> For the readability, I thinkt 'cpu_state' is proper instead of 'state'. > Get it. >> >>> + struct cpufreq_policy *policy; >>> + struct device *cpu_dev; >>> + unsigned int cpu; >>> + int ret; >>> + >>> + get_online_cpus(); >> >> Add blank line. > Get it. >> >>> + data->nb.notifier_call = cpufreq_passive_notifier_call; >>> + ret = cpufreq_register_notifier(&data->nb, >>> + CPUFREQ_TRANSITION_NOTIFIER); >>> + if (ret) { >>> + dev_err(dev, "Couldn't register cpufreq notifier.\n"); >>> + data->nb.notifier_call = NULL; >>> + goto out; >>> + } >>> + >>> + /* Populate devfreq_cpu_state */ >>> + for_each_online_cpu(cpu) { >>> + if (data->cpu_state[cpu]) >>> + continue; >>> + >>> + policy = cpufreq_cpu_get(cpu); >> >> cpufreq_cpu_get() might return 'NULL'. I think you need to handle >> return value as following: >> >> if (!policy) { >> ret = -EINVAL; >> goto out; >> } else if (PTR_ERR(policy) == -EPROBE_DEFER) { >> goto out; >> } else if (IS_ERR(policy) { >> ret = PTR_ERR(policy); >> dev_err(dev, "Couldn't get the cpufreq_poliy.\n"); >> goto out; >> } >> >> If cpufreq_cpu_get() return successfully, to do next. >> It reduces the one indentaion. >> >> > Get it. >> >>> + if (policy) { >>> + state = kzalloc(sizeof(*state), GFP_KERNEL); >>> + if (!state) { >>> + ret = -ENOMEM; >>> + goto out; >>> + } >>> + >>> + cpu_dev = get_cpu_device(cpu); >>> + if (!cpu_dev) { >>> + dev_err(dev, "Couldn't get cpu device.\n"); >>> + ret = -ENODEV; >>> + goto out; >>> + } >>> + >>> + opp_table = dev_pm_opp_get_opp_table(cpu_dev); >>> + if (IS_ERR(devfreq->opp_table)) { >>> + ret = PTR_ERR(opp_table); >>> + goto out; >>> + } >>> + >>> + state->dev = cpu_dev; >>> + state->opp_table = opp_table; >>> + state->first_cpu = cpumask_first(policy->related_cpus); >>> + state->freq = policy->cur; >>> + state->min_freq = policy->cpuinfo.min_freq; >>> + state->max_freq = policy->cpuinfo.max_freq; >>> + data->cpu_state[cpu] = state; >> >> Add blank line. >> >>> + cpufreq_cpu_put(policy); >>> + } else { >>> + ret = -EPROBE_DEFER; >>> + goto out; >>> + } >>> + } >> >> Add blank line. > Get it. >>> +out: >>> + put_online_cpus(); >>> + if (ret) >>> + return ret; >>> + >>> + /* Update devfreq */ >>> + mutex_lock(&devfreq->lock); >>> + ret = update_devfreq(devfreq); >>> + mutex_unlock(&devfreq->lock); >>> + if (ret) >>> + dev_err(dev, "Couldn't update the frequency.\n"); >>> + >>> + return ret; >>> +} >>> + >>> +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data) >>> +{ >>> + struct devfreq_passive_data *data = *p_data; >>> + struct devfreq_cpu_state *cpu_state; >>> + int cpu; >>> + >>> + if (data->nb.notifier_call) >>> + cpufreq_unregister_notifier(&data->nb, >>> + CPUFREQ_TRANSITION_NOTIFIER); >>> + >>> + for_each_possible_cpu(cpu) { >>> + cpu_state = data->cpu_state[cpu]; >>> + if (cpu_state) { >>> + if (cpu_state->opp_table) >>> + dev_pm_opp_put_opp_table(cpu_state->opp_table); >>> + kfree(cpu_state); >>> + cpu_state = NULL; >>> + } >>> + } >>> + >>> + return 0; >>> +} >>> + >>> static int devfreq_passive_event_handler(struct devfreq *devfreq, >>> unsigned int event, void *data) >>> { >>> @@ -165,7 +398,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, >>> struct notifier_block *nb = &p_data->nb; >>> int ret = 0; >>> >>> - if (!parent) >>> + if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent) >>> return -EPROBE_DEFER; >> >> If you modify the devfreq_passive_event_handler() as following, >> you can move this condition for DEVFREQ_PARENT_DEV into >> (register|unregister)_parent_dev_notifier. >> >> switch (event) { >> case DEVFREQ_GOV_START: >> ret = register_parent_dev_notifier(p_data); >> break; >> case DEVFREQ_GOV_STOP: >> ret = unregister_parent_dev_notifier(p_data); >> break; >> default: >> ret = -EINVAL; >> break; >> } >> >> return ret; >> > Get it. >>> >>> switch (event) { >>> @@ -173,13 +406,24 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq, >>> if (!p_data->this) >>> p_data->this = devfreq; >>> >>> - nb->notifier_call = devfreq_passive_notifier_call; >>> - ret = devfreq_register_notifier(parent, nb, >>> - DEVFREQ_TRANSITION_NOTIFIER); >>> + if (p_data->parent_type == DEVFREQ_PARENT_DEV) { >>> + nb->notifier_call = devfreq_passive_notifier_call; >>> + ret = devfreq_register_notifier(parent, nb, >>> + DEVFREQ_TRANSITION_NOTIFIER); >>> + } else if (p_data->parent_type == CPUFREQ_PARENT_DEV) { >>> + ret = cpufreq_passive_register(&p_data); >> >> I think that we better to collect the code related to notifier registration >> into one function like devfreq_pass_register_notifier() instead of >> cpufreq_passive_register() as following: I think it is more simple and readable. >> >> If you have more proper function name of register_parent_dev_notifier, >> please give your opinion. >> >> int register_parent_dev_notifier(struct devfreq_passive_data **p_data) >> switch (p_data->parent_type) { >> case DEVFREQ_PARENT_DEV: >> nb->notifier_call = devfreq_passive_notifier_call; >> ret = devfreq_register_notifier(parent, nb, >> break; >> case CPUFREQ_PARENT_DEV: >> cpufreq_register_notifier(...) >> ... >> break; >> } > Not fully understanding. > Do you mean expanding cpufreq_passive_register()? Yes and rename it for both cpufreq and devfreq. > I think leave it in function will be with clean for this code segment. I want that one function handle the notifier register for both cpufreq and devfreq so that we make it more simply as following: On the step hanling the governor event, don't need to consider the type of parent device of devfreq deivce with this style. case DEVFREQ_GOV_START: ret = register_notifier(...); break; case DEVFREQ_GOV_STOP: ret = unregister_notifier(...); break; > >> >> >>> + } else { >>> + ret = -EINVAL; >>> + } >>> break; >>> case DEVFREQ_GOV_STOP: >>> - WARN_ON(devfreq_unregister_notifier(parent, nb, >>> - DEVFREQ_TRANSITION_NOTIFIER)); >>> + if (p_data->parent_type == DEVFREQ_PARENT_DEV) >>> + WARN_ON(devfreq_unregister_notifier(parent, nb, >>> + DEVFREQ_TRANSITION_NOTIFIER)); >>> + else if (p_data->parent_type == CPUFREQ_PARENT_DEV) >>> + cpufreq_passive_unregister(&p_data); >>> + else >>> + ret = -EINVAL; >> >> ditto. unregister_parent_dev_notifier(struct devfreq_passive_data **p_data) > Get it. ditto. As I aboved commented. >> >>> break; >>> default: >>> break; >>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h >>> index a4b19d593151..04ce576fd6f1 100644 >>> --- a/include/linux/devfreq.h >>> +++ b/include/linux/devfreq.h >>> @@ -278,6 +278,32 @@ struct devfreq_simple_ondemand_data { >>> >>> #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE) >>> /** >>> + * struct devfreq_cpu_state - holds the per-cpu state >>> + * @freq: the current frequency of the cpu. >>> + * @min_freq: the min frequency of the cpu. >>> + * @max_freq: the max frequency of the cpu. >>> + * @first_cpu: the cpumask of the first cpu of a policy. >>> + * @dev: reference to cpu device. >>> + * @opp_table: reference to cpu opp table. >>> + * >>> + * This structure stores the required cpu_state of a cpu. >>> + * This is auto-populated by the governor. >>> + */ >>> +struct devfreq_cpu_state {> + unsigned int freq; >> >> It is better to change from 'freq' to 'curr_freq' >> for more correct expression. > Get it. >> >>> + unsigned int min_freq; >>> + unsigned int max_freq; >>> + unsigned int first_cpu; >>> + struct device *dev; >> >> How about changing the name 'dev' to 'cpu_dev'? > Okay. >> >> >>> + struct opp_table *opp_table; >>> +}; >> >> devfreq_cpu_state is only handled by within driver/devfreq/governor_passive.c. >> >> So, you can move it into drivers/devfreq/governor_passive.c >> and just add the definition into include/linux/devfreq.h as following: >> It is able to prevent the access of variable of 'struct devfreq_cpu_state' >> outside. >> >> struct devfreq_cpu_state; > Get it. >> >>> + >>> +enum devfreq_parent_dev_type { >>> + DEVFREQ_PARENT_DEV, >>> + CPUFREQ_PARENT_DEV, >>> +}; >>> + >>> +/** >>> * struct devfreq_passive_data - ``void *data`` fed to struct devfreq >>> * and devfreq_add_device >>> * @parent: the devfreq instance of parent device. >>> @@ -288,13 +314,15 @@ struct devfreq_simple_ondemand_data { >>> * using governors except for passive governor. >>> * If the devfreq device has the specific method to decide >>> * the next frequency, should use this callback. >>> - * @this: the devfreq instance of own device. >>> - * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list >>> + * @parent_type parent type of the device >> >> Need to add ':' at the end of word. -> "parent_type:". >> >>> + * @this: the devfreq instance of own device. >>> + * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list >> >> I knew that you make them with same indentation. >> But, actually, it is not related to this patch like clean-up code. >> Even if it is not pretty, you better to don't touch 'this' and 'nb' indentaion. > Get it. >> >>> + * @cpu_state: the state min/max/current frequency of all online cpu's >>> * >>> * The devfreq_passive_data have to set the devfreq instance of parent >>> * device with governors except for the passive governor. But, don't need to >>> - * initialize the 'this' and 'nb' field because the devfreq core will handle >>> - * them. >>> + * initialize the 'this', 'nb' and 'cpu_state' field because the devfreq core >>> + * will handle them. >>> */ >>> struct devfreq_passive_data { >>> /* Should set the devfreq instance of parent device */ >>> @@ -303,9 +331,13 @@ struct devfreq_passive_data { >>> /* Optional callback to decide the next frequency of passvice device */ >>> int (*get_target_freq)(struct devfreq *this, unsigned long *freq); >>> >>> + /* Should set the type of parent device */ >>> + enum devfreq_parent_dev_type parent_type; >>> + >>> /* For passive governor's internal use. Don't need to set them */ >>> struct devfreq *this; >>> struct notifier_block nb; >>> + struct devfreq_cpu_state *cpu_state[NR_CPUS]; >>> }; >>> #endif >>> >>> >> >> > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CGME20200520034339epcas1p1524dea2d7089cb3492384bbe917dcffe@epcas1p1.samsung.com>]
[parent not found: <20200520034307.20435-9-andrew-sh.cheng@mediatek.com>]
* Re: [PATCH 08/12] dt-bindings: devfreq: add compatible for mt8183 cci devfreq [not found] ` <20200520034307.20435-9-andrew-sh.cheng@mediatek.com> @ 2020-05-28 7:42 ` Chanwoo Choi 0 siblings, 0 replies; 15+ messages in thread From: Chanwoo Choi @ 2020-05-28 7:42 UTC (permalink / raw) To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream Hi, On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote: > This adds dt-binding documentation of cci devfreq > for Mediatek MT8183 SoC platform. > > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > .../devicetree/bindings/devfreq/mt8183-cci.yaml | 51 ++++++++++++++++++++++ > 1 file changed, 51 insertions(+) > create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml > > diff --git a/Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml b/Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml > new file mode 100644 > index 000000000000..a7341fd94097 > --- /dev/null > +++ b/Documentation/devicetree/bindings/devfreq/mt8183-cci.yaml > @@ -0,0 +1,51 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: https://protect2.fireeye.com/url?k=33f1f15d-6e23ea05-33f07a12-0cc47a31c8b4-91b3f8aeecce95dc&q=1&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdevfreq%2Fmt8183-cci.yaml%23 > +$schema: https://protect2.fireeye.com/url?k=fc7d9089-a1af8bd1-fc7c1bc6-0cc47a31c8b4-b46f5afc59faf86d&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23 > + > +title: CCI_DEVFREQ driver for MT8183. > + > +maintainers: > + - Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > + > +description: | > + This module is used to create CCI DEVFREQ. > + The performance will depend on both CCI frequency and CPU frequency. > + For MT8183, CCI co-buck with Little core. > + Contain CCI opp table for voltage and frequency scaling. > + > +properties: > + compatible: > + const: "mediatek,mt8183-cci" > + > + clocks: > + maxItems: 1 > + > + clock-names: > + const: "cci" > + > + operating-points-v2: true > + opp-table: true > + > + proc-supply: > + description: > + Phandle of the regulator that provides the supply voltage. > + > +required: > + - compatible > + - clocks > + - clock-names > + - proc-supply > + > +examples: > + - | > + #include <dt-bindings/clock/mt8183-clk.h> > + cci: cci { > + compatible = "mediatek,mt8183-cci"; > + clocks = <&apmixedsys CLK_APMIXED_CCIPLL>; > + clock-names = "cci"; > + operating-points-v2 = <&cci_opp>; > + proc-supply = <&mt6358_vproc12_reg>; > + }; > + > I recommend that add the more detailed example with OPP table with CPU node. -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support [not found] ` <20200520034307.20435-1-andrew-sh.cheng@mediatek.com> ` (4 preceding siblings ...) [not found] ` <CGME20200520034339epcas1p1524dea2d7089cb3492384bbe917dcffe@epcas1p1.samsung.com> @ 2020-06-15 7:31 ` Viresh Kumar 5 siblings, 0 replies; 15+ messages in thread From: Viresh Kumar @ 2020-06-15 7:31 UTC (permalink / raw) To: Andrew-sh.Cheng Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream On 20-05-20, 11:42, Andrew-sh.Cheng wrote: > - Resend depending patches of Sravana Kannan base on kernel-5.7 Saravana's patches were never accepted and I suggested him this which he never tested I believe. https://lore.kernel.org/lkml/20191125112812.26jk5hsdwqfnofc2@vireshk-i7/ There is no point rebasing your stuff on a series which hasn't concluded or is accepted, at least logically. -- viresh ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-06-15 7:31 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20200520034324epcas1p3affbd24bd1f3fe40d51baade07c1abba@epcas1p3.samsung.com> [not found] ` <20200520034307.20435-1-andrew-sh.cheng@mediatek.com> 2020-05-20 4:10 ` [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support Chanwoo Choi [not found] ` <1589953015.8243.2.camel@mtksdaap41> 2020-05-20 6:24 ` Chanwoo Choi [not found] ` <1589958625.23971.2.camel@mtksdaap41> 2020-05-20 14:53 ` Matthias Brugger [not found] ` <20200520034307.20435-10-andrew-sh.cheng@mediatek.com> 2020-05-20 12:31 ` [PATCH 09/12] devfreq: add mediatek cci devfreq Mark Brown 2020-05-21 8:52 ` andrew-sh.cheng 2020-05-28 7:35 ` Chanwoo Choi 2020-05-28 8:00 ` Chanwoo Choi [not found] ` <20200520034307.20435-2-andrew-sh.cheng@mediatek.com> 2020-05-20 14:54 ` [PATCH 01/12] OPP: Allow required-opps even if the device doesn't have power-domains Matthias Brugger [not found] ` <CGME20200520034335epcas1p45a321a1a878fb7cd7b9c9ada0a474ef7@epcas1p4.samsung.com> [not found] ` <20200520034307.20435-7-andrew-sh.cheng@mediatek.com> 2020-05-28 5:03 ` [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor Chanwoo Choi 2020-05-28 6:14 ` Chanwoo Choi 2020-05-28 7:17 ` Chanwoo Choi [not found] ` <1591100614.1804.1.camel@mtksdaap41> 2020-06-03 4:12 ` Chanwoo Choi [not found] ` <1591098190.30729.15.camel@mtksdaap41> 2020-06-03 4:07 ` Chanwoo Choi [not found] ` <CGME20200520034339epcas1p1524dea2d7089cb3492384bbe917dcffe@epcas1p1.samsung.com> [not found] ` <20200520034307.20435-9-andrew-sh.cheng@mediatek.com> 2020-05-28 7:42 ` [PATCH 08/12] dt-bindings: devfreq: add compatible for mt8183 cci devfreq Chanwoo Choi 2020-06-15 7:31 ` [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support Viresh Kumar
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).