From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> 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. depend on: https://patchwork.kernel.org/patch/11193513/ Change since v4: - Remove redundant code Andrew-sh.Cheng (5): cpufreq: mediatek: add clock enable for intermediate clock dt-bindings: devfreq: add compatible for mt8183 cci devfreq devfreq: add mediatek cci devfreq cpufreq: mediatek: add opp notification for SVS support devfreq: mediatek: cci devfreq register opp notification for SVS support .../bindings/devfreq/mt8183-cci-devfreq.txt | 20 ++ drivers/cpufreq/mediatek-cpufreq.c | 92 +++++- drivers/devfreq/Kconfig | 10 + drivers/devfreq/Makefile | 1 + drivers/devfreq/mt8183-cci-devfreq.c | 308 +++++++++++++++++++++ 5 files changed, 429 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> Intermediate clock is not always enabled by ccf in different projects, so cpufreq should always enable it by itself. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> --- drivers/cpufreq/mediatek-cpufreq.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index 0c98dd08273d..4b0cc50dd93b 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -368,13 +368,17 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) goto out_free_resources; } + ret = clk_prepare_enable(inter_clk); + if (ret) + goto out_free_opp_table; + /* Search a safe voltage for intermediate frequency. */ rate = clk_get_rate(inter_clk); opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate); if (IS_ERR(opp)) { pr_err("failed to get intermediate opp for cpu%d\n", cpu); ret = PTR_ERR(opp); - goto out_free_opp_table; + goto out_disable_clock; } info->intermediate_voltage = dev_pm_opp_get_voltage(opp); dev_pm_opp_put(opp); @@ -393,6 +397,9 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) return 0; +out_disable_clock: + clk_disable_unprepare(inter_clk); + out_free_opp_table: dev_pm_opp_of_cpumask_remove_table(&info->cpus); @@ -417,8 +424,10 @@ static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info) regulator_put(info->sram_reg); if (!IS_ERR(info->cpu_clk)) clk_put(info->cpu_clk); - if (!IS_ERR(info->inter_clk)) + if (!IS_ERR(info->inter_clk)) { + clk_disable_unprepare(info->inter_clk); clk_put(info->inter_clk); + } dev_pm_opp_of_cpumask_remove_table(&info->cpus); } -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> This adds dt-binding documentation of cci devfreq for Mediatek MT8183 SoC platform. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> --- .../bindings/devfreq/mt8183-cci-devfreq.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt diff --git a/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt new file mode 100644 index 000000000000..a65a70bb9f09 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt @@ -0,0 +1,20 @@ +* Mediatek Cache Coherent Interconnect(CCI) frequency device + +Required properties: +- compatible: should contain "mediatek,mt8183-cci" for frequency scaling of CCI +- clocks: for frequency scaling of CCI +- clock-names: for frequency scaling of CCI driver to reference +- regulator: for voltage scaling of CCI +- operating-points-v2: for frequency scaling of CCI opp table + +Example: + cci: cci { + compatible = "mediatek,mt8183-cci"; + clocks = <&apmixedsys CLK_APMIXED_CCIPLL>; + clock-names = "cci_clock"; + operating-points-v2 = <&cci_opp>; + }; + + &cci { + proc-supply = <&mt6358_vproc12_reg>; + }; \ No newline at end of file -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> 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 | 247 +++++++++++++++++++++++++++++++++++ 3 files changed, 258 insertions(+) create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index defe1d438710..76bc42657787 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -92,6 +92,16 @@ config ARM_EXYNOS_BUS_DEVFREQ and adjusts the operating frequencies and voltages with OPP support. This does not yet operate with optimal voltages. +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. + 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 338ae8440db6..1fa05e39e4ff 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o # DEVFREQ Drivers obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.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..818a167c442f --- /dev/null +++ b/drivers/devfreq/mt8183-cci-devfreq.c @@ -0,0 +1,247 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019 MediaTek Inc. + + * 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 "governor.h" + +struct cci_devfreq { + struct devfreq *devfreq; + struct regulator *proc_reg; + unsigned long proc_reg_uV; + struct clk *cci_clk; + struct notifier_block nb; +}; + +static int cci_devfreq_regulator_notifier(struct notifier_block *nb, + unsigned long val, void *data) +{ + int ret; + struct cci_devfreq *cci_df = + container_of(nb, struct cci_devfreq, nb); + + /* deal with reduce frequency */ + if (val & REGULATOR_EVENT_PRE_VOLTAGE_CHANGE) { + struct pre_voltage_change_data *pvc_data = data; + + if (pvc_data->min_uV < pvc_data->old_uV) { + cci_df->proc_reg_uV = + (unsigned long)(pvc_data->min_uV); + mutex_lock(&cci_df->devfreq->lock); + ret = update_devfreq(cci_df->devfreq); + if (ret) + pr_err("Fail to reduce cci frequency: %d\n", + ret); + mutex_unlock(&cci_df->devfreq->lock); + } + } else if ((val & REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE) && + ((unsigned long)data > cci_df->proc_reg_uV)) { + cci_df->proc_reg_uV = (unsigned long)data; + mutex_lock(&cci_df->devfreq->lock); + ret = update_devfreq(cci_df->devfreq); + if (ret) + pr_err("Fail to raise cci frequency back: %d\n", ret); + mutex_unlock(&cci_df->devfreq->lock); + } else if ((val & REGULATOR_EVENT_VOLTAGE_CHANGE) && + (cci_df->proc_reg_uV < (unsigned long)data)) { + /* deal with increase frequency */ + cci_df->proc_reg_uV = (unsigned long)data; + mutex_lock(&cci_df->devfreq->lock); + ret = update_devfreq(cci_df->devfreq); + if (ret) + pr_err("Fail to raise cci frequency: %d\n", ret); + mutex_unlock(&cci_df->devfreq->lock); + } + + return 0; +} + +static int mtk_cci_governor_get_target(struct devfreq *devfreq, + unsigned long *freq) +{ + struct cci_devfreq *cci_df; + struct dev_pm_opp *opp; + + cci_df = dev_get_drvdata(devfreq->dev.parent); + + /* find available frequency */ + opp = dev_pm_opp_find_freq_ceil_by_volt(devfreq->dev.parent, + cci_df->proc_reg_uV); + *freq = dev_pm_opp_get_freq(opp); + + return 0; +} + +static int mtk_cci_governor_event_handler(struct devfreq *devfreq, + unsigned int event, void *data) +{ + int ret; + struct cci_devfreq *cci_df; + struct notifier_block *nb; + + cci_df = dev_get_drvdata(devfreq->dev.parent); + nb = &cci_df->nb; + + switch (event) { + case DEVFREQ_GOV_START: + case DEVFREQ_GOV_RESUME: + nb->notifier_call = cci_devfreq_regulator_notifier; + ret = regulator_register_notifier(cci_df->proc_reg, + nb); + if (ret) + pr_err("%s: failed to add governor: %d\n", __func__, + ret); + break; + + case DEVFREQ_GOV_STOP: + case DEVFREQ_GOV_SUSPEND: + ret = regulator_unregister_notifier(cci_df->proc_reg, + nb); + if (ret) + pr_err("%s: failed to add governor: %d\n", __func__, + ret); + break; + + default: + break; + } + + return 0; +} + +static struct devfreq_governor mtk_cci_devfreq_governor = { + .name = "mtk_cci_vmon", + .get_target_freq = mtk_cci_governor_get_target, + .event_handler = mtk_cci_governor_event_handler, + .immutable = true +}; + +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); + + if (!cci_df) + return -EINVAL; + + ret = clk_set_rate(cci_df->cci_clk, *freq); + if (ret) { + pr_err("%s: failed cci to set rate: %d\n", __func__, + ret); + return ret; + } + + return 0; +} + +static struct devfreq_dev_profile cci_devfreq_profile = { + .target = mtk_cci_devfreq_target, +}; + +static int mtk_cci_devfreq_probe(struct platform_device *pdev) +{ + struct device *cci_dev = &pdev->dev; + struct cci_devfreq *cci_df; + 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; + } + + ret = dev_pm_opp_of_add_table(cci_dev); + if (ret) { + dev_err(cci_dev, "Fail to init CCI OPP table: %d\n", ret); + return ret; + } + + platform_set_drvdata(pdev, cci_df); + + cci_df->devfreq = devm_devfreq_add_device(cci_dev, + &cci_devfreq_profile, + "mtk_cci_vmon", + NULL); + 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); + return ret; + } + + return 0; +} + +static const __maybe_unused struct of_device_id + mediatek_cci_devfreq_of_match[] = { + { .compatible = "mediatek,mt8183-cci" }, + { }, +}; +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match); + +static struct platform_driver cci_devfreq_driver = { + .probe = mtk_cci_devfreq_probe, + .driver = { + .name = "mediatek-cci-devfreq", + .of_match_table = of_match_ptr(mediatek_cci_devfreq_of_match), + }, +}; + +static int __init mtk_cci_devfreq_init(void) +{ + int ret; + + ret = devfreq_add_governor(&mtk_cci_devfreq_governor); + if (ret) { + pr_err("%s: failed to add governor: %d\n", __func__, ret); + return ret; + } + + ret = platform_driver_register(&cci_devfreq_driver); + if (ret) + devfreq_remove_governor(&mtk_cci_devfreq_governor); + + return ret; +} +module_init(mtk_cci_devfreq_init) + +static void __exit mtk_cci_devfreq_exit(void) +{ + int ret; + + ret = devfreq_remove_governor(&mtk_cci_devfreq_governor); + if (ret) + pr_err("%s: failed to remove governor: %d\n", __func__, ret); + + platform_driver_unregister(&cci_devfreq_driver); +} +module_exit(mtk_cci_devfreq_exit) + +MODULE_DESCRIPTION("Mediatek CCI devfreq driver"); +MODULE_AUTHOR("Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>"); +MODULE_LICENSE("GPL v2"); -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> cpufreq should listen opp notification and do proper actions when receiving disable and voltage adjustment events, which are triggered when SVS is enabled. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> --- drivers/cpufreq/mediatek-cpufreq.c | 79 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index 4b0cc50dd93b..7c37ab31230a 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -42,6 +42,10 @@ struct mtk_cpu_dvfs_info { struct list_head list_head; int intermediate_voltage; bool need_voltage_tracking; + struct mutex lock; /* avoid notify and policy race condition */ + struct notifier_block opp_nb; + int opp_cpu; + unsigned long opp_freq; }; static LIST_HEAD(dvfs_info_list); @@ -231,6 +235,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, vproc = dev_pm_opp_get_voltage(opp); dev_pm_opp_put(opp); + mutex_lock(&info->lock); /* * If the new voltage or the intermediate voltage is higher than the * current voltage, scale up voltage first. @@ -242,6 +247,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, pr_err("cpu%d: failed to scale up voltage!\n", policy->cpu); mtk_cpufreq_set_voltage(info, old_vproc); + mutex_unlock(&info->lock); return ret; } } @@ -253,6 +259,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, policy->cpu); mtk_cpufreq_set_voltage(info, old_vproc); WARN_ON(1); + mutex_unlock(&info->lock); return ret; } @@ -263,6 +270,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, policy->cpu); clk_set_parent(cpu_clk, armpll); mtk_cpufreq_set_voltage(info, old_vproc); + mutex_unlock(&info->lock); return ret; } @@ -273,6 +281,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, policy->cpu); mtk_cpufreq_set_voltage(info, inter_vproc); WARN_ON(1); + mutex_unlock(&info->lock); return ret; } @@ -288,15 +297,75 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, clk_set_parent(cpu_clk, info->inter_clk); clk_set_rate(armpll, old_freq_hz); clk_set_parent(cpu_clk, armpll); + mutex_unlock(&info->lock); return ret; } } + info->opp_freq = freq_hz; + mutex_unlock(&info->lock); + return 0; } #define DYNAMIC_POWER "dynamic-power-coefficient" +static int mtk_cpufreq_opp_notifier(struct notifier_block *nb, + unsigned long event, void *data) +{ + struct dev_pm_opp *opp = data; + struct dev_pm_opp *opp_item; + struct mtk_cpu_dvfs_info *info = + container_of(nb, struct mtk_cpu_dvfs_info, opp_nb); + unsigned long freq, volt; + struct cpufreq_policy *policy; + int ret = 0; + + if (event == OPP_EVENT_ADJUST_VOLTAGE) { + freq = dev_pm_opp_get_freq(opp); + + mutex_lock(&info->lock); + if (info->opp_freq == freq) { + volt = dev_pm_opp_get_voltage(opp); + ret = mtk_cpufreq_set_voltage(info, volt); + if (ret) + dev_err(info->cpu_dev, "failed to scale voltage: %d\n", + ret); + } + mutex_unlock(&info->lock); + } else if (event == OPP_EVENT_DISABLE) { + freq = info->opp_freq; + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, &freq); + if (!IS_ERR(opp_item)) + dev_pm_opp_put(opp_item); + else + freq = 0; + + /* case of current opp is disabled */ + if (freq == 0 || freq != info->opp_freq) { + // find an enable opp item + freq = 1; + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, + &freq); + if (!IS_ERR(opp_item)) { + dev_pm_opp_put(opp_item); + policy = cpufreq_cpu_get(info->opp_cpu); + if (policy) { + cpufreq_driver_target(policy, + freq / 1000, + CPUFREQ_RELATION_L); + cpufreq_cpu_put(policy); + } + } else { + pr_err("%s: all opp items are disabled\n", + __func__); + } + } + } + + return notifier_from_errno(ret); +} + static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) { struct device *cpu_dev; @@ -383,11 +452,21 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) info->intermediate_voltage = dev_pm_opp_get_voltage(opp); dev_pm_opp_put(opp); + info->opp_cpu = cpu; + info->opp_nb.notifier_call = mtk_cpufreq_opp_notifier; + ret = dev_pm_opp_register_notifier(cpu_dev, &info->opp_nb); + if (ret) { + pr_warn("cannot register opp notification\n"); + goto out_free_opp_table; + } + + mutex_init(&info->lock); info->cpu_dev = cpu_dev; info->proc_reg = proc_reg; info->sram_reg = IS_ERR(sram_reg) ? NULL : sram_reg; info->cpu_clk = cpu_clk; info->inter_clk = inter_clk; + info->opp_freq = clk_get_rate(cpu_clk); /* * If SRAM regulator is present, software "voltage tracking" is needed -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> SVS will change the voltage of opp item. CCI devfreq need to react to change frequency. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> --- drivers/devfreq/mt8183-cci-devfreq.c | 61 ++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/drivers/devfreq/mt8183-cci-devfreq.c b/drivers/devfreq/mt8183-cci-devfreq.c index 818a167c442f..afc274d73c2f 100644 --- a/drivers/devfreq/mt8183-cci-devfreq.c +++ b/drivers/devfreq/mt8183-cci-devfreq.c @@ -19,7 +19,10 @@ struct cci_devfreq { struct regulator *proc_reg; unsigned long proc_reg_uV; struct clk *cci_clk; + unsigned long freq; struct notifier_block nb; + struct notifier_block opp_nb; + int cci_min_freq; }; static int cci_devfreq_regulator_notifier(struct notifier_block *nb, @@ -65,17 +68,60 @@ static int cci_devfreq_regulator_notifier(struct notifier_block *nb, return 0; } +static int ccidevfreq_opp_notifier(struct notifier_block *nb, + unsigned long event, void *data) +{ + int ret; + struct dev_pm_opp *opp = data; + struct cci_devfreq *cci_df = container_of(nb, struct cci_devfreq, + opp_nb); + unsigned long freq, volt, cur_volt; + + if (event == OPP_EVENT_ADJUST_VOLTAGE) { + freq = dev_pm_opp_get_freq(opp); + /* current opp item is changed */ + if (freq == cci_df->freq) { + volt = dev_pm_opp_get_voltage(opp); + cur_volt = regulator_get_voltage(cci_df->proc_reg); + + if (volt > cur_volt) { + /* need reduce freq */ + mutex_lock(&cci_df->devfreq->lock); + ret = update_devfreq(cci_df->devfreq); + if (ret) + pr_err("Fail to reduce cci frequency by opp notification: %d\n", + ret); + mutex_unlock(&cci_df->devfreq->lock); + } + } + + if (freq == cci_df->cci_min_freq) { + volt = dev_pm_opp_get_voltage(opp); + regulator_set_voltage(cci_df->proc_reg, volt, INT_MAX); + } + } + + return 0; +} + static int mtk_cci_governor_get_target(struct devfreq *devfreq, unsigned long *freq) { struct cci_devfreq *cci_df; struct dev_pm_opp *opp; + int ret; cci_df = dev_get_drvdata(devfreq->dev.parent); /* find available frequency */ opp = dev_pm_opp_find_freq_ceil_by_volt(devfreq->dev.parent, cci_df->proc_reg_uV); + ret = PTR_ERR_OR_ZERO(opp); + if (ret) { + pr_err("%s[%d], cannot find opp with voltage=%d: %d\n", + __func__, __LINE__, cci_df->proc_reg_uV, ret); + return ret; + } *freq = dev_pm_opp_get_freq(opp); return 0; @@ -87,9 +133,11 @@ static int mtk_cci_governor_event_handler(struct devfreq *devfreq, int ret; struct cci_devfreq *cci_df; struct notifier_block *nb; + struct notifier_block *opp_nb; cci_df = dev_get_drvdata(devfreq->dev.parent); nb = &cci_df->nb; + opp_nb = &cci_df->opp_nb; switch (event) { case DEVFREQ_GOV_START: @@ -100,6 +148,8 @@ static int mtk_cci_governor_event_handler(struct devfreq *devfreq, if (ret) pr_err("%s: failed to add governor: %d\n", __func__, ret); + opp_nb->notifier_call = ccidevfreq_opp_notifier; + dev_pm_opp_register_notifier(devfreq->dev.parent, opp_nb); break; case DEVFREQ_GOV_STOP: @@ -141,6 +191,8 @@ static int mtk_cci_devfreq_target(struct device *dev, unsigned long *freq, return ret; } + cci_df->freq = *freq; + return 0; } @@ -152,6 +204,8 @@ static int mtk_cci_devfreq_probe(struct platform_device *pdev) { struct device *cci_dev = &pdev->dev; struct cci_devfreq *cci_df; + unsigned long freq, volt; + struct dev_pm_opp *opp; int ret; cci_df = devm_kzalloc(cci_dev, sizeof(*cci_df), GFP_KERNEL); @@ -181,6 +235,13 @@ static int mtk_cci_devfreq_probe(struct platform_device *pdev) return ret; } + /* set voltage lower bound */ + freq = 1; + opp = dev_pm_opp_find_freq_ceil(cci_dev, &freq); + cci_df->cci_min_freq = dev_pm_opp_get_freq(opp); + volt = dev_pm_opp_get_voltage(opp); + dev_pm_opp_put(opp); + platform_set_drvdata(pdev, cci_df); cci_df->devfreq = devm_devfreq_add_device(cci_dev, -- 2.12.5 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index 4b0cc50dd93b..7c37ab31230a 100644 > --- a/drivers/cpufreq/mediatek-cpufreq.c > +++ b/drivers/cpufreq/mediatek-cpufreq.c > @@ -42,6 +42,10 @@ struct mtk_cpu_dvfs_info { > struct list_head list_head; > int intermediate_voltage; > bool need_voltage_tracking; > + struct mutex lock; /* avoid notify and policy race condition */ Will a read-write lock be better suited here for performance reasons ? > + struct notifier_block opp_nb; > + int opp_cpu; > + unsigned long opp_freq; > }; > > static LIST_HEAD(dvfs_info_list); > @@ -231,6 +235,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > vproc = dev_pm_opp_get_voltage(opp); > dev_pm_opp_put(opp); > > + mutex_lock(&info->lock); > /* > * If the new voltage or the intermediate voltage is higher than the > * current voltage, scale up voltage first. > @@ -242,6 +247,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > pr_err("cpu%d: failed to scale up voltage!\n", > policy->cpu); > mtk_cpufreq_set_voltage(info, old_vproc); > + mutex_unlock(&info->lock); > return ret; > } > } > @@ -253,6 +259,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > policy->cpu); > mtk_cpufreq_set_voltage(info, old_vproc); > WARN_ON(1); > + mutex_unlock(&info->lock); > return ret; > } > > @@ -263,6 +270,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > policy->cpu); > clk_set_parent(cpu_clk, armpll); > mtk_cpufreq_set_voltage(info, old_vproc); > + mutex_unlock(&info->lock); > return ret; > } > > @@ -273,6 +281,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > policy->cpu); > mtk_cpufreq_set_voltage(info, inter_vproc); > WARN_ON(1); > + mutex_unlock(&info->lock); > return ret; > } > > @@ -288,15 +297,75 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > clk_set_parent(cpu_clk, info->inter_clk); > clk_set_rate(armpll, old_freq_hz); > clk_set_parent(cpu_clk, armpll); > + mutex_unlock(&info->lock); > return ret; > } > } > > + info->opp_freq = freq_hz; > + mutex_unlock(&info->lock); > + > return 0; > } > > #define DYNAMIC_POWER "dynamic-power-coefficient" > > +static int mtk_cpufreq_opp_notifier(struct notifier_block *nb, > + unsigned long event, void *data) > +{ > + struct dev_pm_opp *opp = data; > + struct dev_pm_opp *opp_item; > + struct mtk_cpu_dvfs_info *info = > + container_of(nb, struct mtk_cpu_dvfs_info, opp_nb); Do the assignment after all definitions, instead of awkwardly breaking the line here. > + unsigned long freq, volt; > + struct cpufreq_policy *policy; > + int ret = 0; > + > + if (event == OPP_EVENT_ADJUST_VOLTAGE) { > + freq = dev_pm_opp_get_freq(opp); > + > + mutex_lock(&info->lock); > + if (info->opp_freq == freq) { > + volt = dev_pm_opp_get_voltage(opp); > + ret = mtk_cpufreq_set_voltage(info, volt); > + if (ret) > + dev_err(info->cpu_dev, "failed to scale voltage: %d\n", > + ret); > + } > + mutex_unlock(&info->lock); > + } else if (event == OPP_EVENT_DISABLE) { > + freq = info->opp_freq; > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, &freq); name it new_opp instead of opp_item. > + if (!IS_ERR(opp_item)) > + dev_pm_opp_put(opp_item); > + else > + freq = 0; > + What is the purpose of the above code ? > + /* case of current opp is disabled */ > + if (freq == 0 || freq != info->opp_freq) { > + // find an enable opp item Use proper commenting style please. > + freq = 1; > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > + &freq); > + if (!IS_ERR(opp_item)) { > + dev_pm_opp_put(opp_item); > + policy = cpufreq_cpu_get(info->opp_cpu); > + if (policy) { > + cpufreq_driver_target(policy, > + freq / 1000, > + CPUFREQ_RELATION_L); Why don't you simply call this instead of all the code in the else block ? > + cpufreq_cpu_put(policy); > + } > + } else { > + pr_err("%s: all opp items are disabled\n", > + __func__); > + } > + } > + } > + > + return notifier_from_errno(ret); > +} > + > static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > { > struct device *cpu_dev; > @@ -383,11 +452,21 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > info->intermediate_voltage = dev_pm_opp_get_voltage(opp); > dev_pm_opp_put(opp); > > + info->opp_cpu = cpu; > + info->opp_nb.notifier_call = mtk_cpufreq_opp_notifier; > + ret = dev_pm_opp_register_notifier(cpu_dev, &info->opp_nb); > + if (ret) { > + pr_warn("cannot register opp notification\n"); > + goto out_free_opp_table; > + } > + > + mutex_init(&info->lock); > info->cpu_dev = cpu_dev; > info->proc_reg = proc_reg; > info->sram_reg = IS_ERR(sram_reg) ? NULL : sram_reg; > info->cpu_clk = cpu_clk; > info->inter_clk = inter_clk; > + info->opp_freq = clk_get_rate(cpu_clk); > > /* > * If SRAM regulator is present, software "voltage tracking" is needed > -- > 2.12.5 -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > > index 4b0cc50dd93b..7c37ab31230a 100644 > > --- a/drivers/cpufreq/mediatek-cpufreq.c > > +++ b/drivers/cpufreq/mediatek-cpufreq.c > > @@ -42,6 +42,10 @@ struct mtk_cpu_dvfs_info { > > struct list_head list_head; > > int intermediate_voltage; > > bool need_voltage_tracking; > > + struct mutex lock; /* avoid notify and policy race condition */ > > Will a read-write lock be better suited here for performance reasons ? Thank you for advice, I will check it. > > > + struct notifier_block opp_nb; > > + int opp_cpu; > > + unsigned long opp_freq; > > }; > > > > static LIST_HEAD(dvfs_info_list); > > @@ -231,6 +235,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > vproc = dev_pm_opp_get_voltage(opp); > > dev_pm_opp_put(opp); > > > > + mutex_lock(&info->lock); > > /* > > * If the new voltage or the intermediate voltage is higher than the > > * current voltage, scale up voltage first. > > @@ -242,6 +247,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > pr_err("cpu%d: failed to scale up voltage!\n", > > policy->cpu); > > mtk_cpufreq_set_voltage(info, old_vproc); > > + mutex_unlock(&info->lock); > > return ret; > > } > > } > > @@ -253,6 +259,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > policy->cpu); > > mtk_cpufreq_set_voltage(info, old_vproc); > > WARN_ON(1); > > + mutex_unlock(&info->lock); > > return ret; > > } > > > > @@ -263,6 +270,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > policy->cpu); > > clk_set_parent(cpu_clk, armpll); > > mtk_cpufreq_set_voltage(info, old_vproc); > > + mutex_unlock(&info->lock); > > return ret; > > } > > > > @@ -273,6 +281,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > policy->cpu); > > mtk_cpufreq_set_voltage(info, inter_vproc); > > WARN_ON(1); > > + mutex_unlock(&info->lock); > > return ret; > > } > > > > @@ -288,15 +297,75 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, > > clk_set_parent(cpu_clk, info->inter_clk); > > clk_set_rate(armpll, old_freq_hz); > > clk_set_parent(cpu_clk, armpll); > > + mutex_unlock(&info->lock); > > return ret; > > } > > } > > > > + info->opp_freq = freq_hz; > > + mutex_unlock(&info->lock); > > + > > return 0; > > } > > > > #define DYNAMIC_POWER "dynamic-power-coefficient" > > > > +static int mtk_cpufreq_opp_notifier(struct notifier_block *nb, > > + unsigned long event, void *data) > > +{ > > + struct dev_pm_opp *opp = data; > > + struct dev_pm_opp *opp_item; > > + struct mtk_cpu_dvfs_info *info = > > + container_of(nb, struct mtk_cpu_dvfs_info, opp_nb); > > Do the assignment after all definitions, instead of awkwardly breaking > the line here. Got it, will change it. > > > + unsigned long freq, volt; > > + struct cpufreq_policy *policy; > > + int ret = 0; > > + > > + if (event == OPP_EVENT_ADJUST_VOLTAGE) { > > + freq = dev_pm_opp_get_freq(opp); > > + > > + mutex_lock(&info->lock); > > + if (info->opp_freq == freq) { > > + volt = dev_pm_opp_get_voltage(opp); > > + ret = mtk_cpufreq_set_voltage(info, volt); > > + if (ret) > > + dev_err(info->cpu_dev, "failed to scale voltage: %d\n", > > + ret); > > + } > > + mutex_unlock(&info->lock); > > + } else if (event == OPP_EVENT_DISABLE) { > > + freq = info->opp_freq; > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, &freq); > > name it new_opp instead of opp_item. Got it, will change it. > > > + if (!IS_ERR(opp_item)) > > + dev_pm_opp_put(opp_item); > > + else > > + freq = 0; > > + > > What is the purpose of the above code ? When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq value won't be set. Set it as 0 for below checking > > > + /* case of current opp is disabled */ > > + if (freq == 0 || freq != info->opp_freq) { > > + // find an enable opp item > > Use proper commenting style please. Got it, will change it. > > > + freq = 1; > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > + &freq); > > + if (!IS_ERR(opp_item)) { > > + dev_pm_opp_put(opp_item); > > + policy = cpufreq_cpu_get(info->opp_cpu); > > + if (policy) { > > + cpufreq_driver_target(policy, > > + freq / 1000, > > + CPUFREQ_RELATION_L); > > Why don't you simply call this instead of all the code in the else > block ? These else code is used to check "current opp item is disabled or not". If not, do nothing. If current opp item is disabled, need to find an not-disabled opp item, and set frequency to it. > > > + cpufreq_cpu_put(policy); > > + } > > + } else { > > + pr_err("%s: all opp items are disabled\n", > > + __func__); > > + } > > + } > > + } > > + > > + return notifier_from_errno(ret); > > +} > > + > > static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > > { > > struct device *cpu_dev; > > @@ -383,11 +452,21 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > > info->intermediate_voltage = dev_pm_opp_get_voltage(opp); > > dev_pm_opp_put(opp); > > > > + info->opp_cpu = cpu; > > + info->opp_nb.notifier_call = mtk_cpufreq_opp_notifier; > > + ret = dev_pm_opp_register_notifier(cpu_dev, &info->opp_nb); > > + if (ret) { > > + pr_warn("cannot register opp notification\n"); > > + goto out_free_opp_table; > > + } > > + > > + mutex_init(&info->lock); > > info->cpu_dev = cpu_dev; > > info->proc_reg = proc_reg; > > info->sram_reg = IS_ERR(sram_reg) ? NULL : sram_reg; > > info->cpu_clk = cpu_clk; > > info->inter_clk = inter_clk; > > + info->opp_freq = clk_get_rate(cpu_clk); > > > > /* > > * If SRAM regulator is present, software "voltage tracking" is needed > > -- > > 2.12.5 > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 09-12-19, 14:56, andrew-sh.cheng wrote: > On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > > + if (!IS_ERR(opp_item)) > > > + dev_pm_opp_put(opp_item); > > > + else > > > + freq = 0; > > > + > > > > What is the purpose of the above code ? > When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq > value won't be set. > Set it as 0 for below checking > > > > > + /* case of current opp is disabled */ > > > + if (freq == 0 || freq != info->opp_freq) { > > > + // find an enable opp item > > > + freq = 1; > > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > > + &freq); > > > + if (!IS_ERR(opp_item)) { > > > + dev_pm_opp_put(opp_item); > > > + policy = cpufreq_cpu_get(info->opp_cpu); > > > + if (policy) { > > > + cpufreq_driver_target(policy, > > > + freq / 1000, > > > + CPUFREQ_RELATION_L); > > > > Why don't you simply call this instead of all the code in the else > > block ? > These else code is used to check "current opp item is disabled or not". > If not, do nothing. > If current opp item is disabled, need to find an not-disabled opp item, > and set frequency to it. Right. So this notifier helper of yours receive the opp which is getting disabled, why don't you compare its frequency directly to see if the current OPP is getting disabled ? -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi, On 11/26/19 8:50 PM, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > This adds dt-binding documentation of cci devfreq > for Mediatek MT8183 SoC platform. > > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > .../bindings/devfreq/mt8183-cci-devfreq.txt | 20 ++++++++++++++++++++ mt8183-cci.txt is better without 'devfreq' word. I recommend to make the binding document with yaml. You can refer to the example[1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next&id=6ad0b4fb960c3bc32034d8f3ec7609c8bcb8d9a4 > 1 file changed, 20 insertions(+) > create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt > > diff --git a/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt > new file mode 100644 > index 000000000000..a65a70bb9f09 > --- /dev/null > +++ b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt > @@ -0,0 +1,20 @@ > +* Mediatek Cache Coherent Interconnect(CCI) frequency device recommend to add the more detailed description of what is the role of this driver. > + > +Required properties: > +- compatible: should contain "mediatek,mt8183-cci" for frequency scaling of CCI > +- clocks: for frequency scaling of CCI > +- clock-names: for frequency scaling of CCI driver to reference > +- regulator: for voltage scaling of CCI > +- operating-points-v2: for frequency scaling of CCI opp table > + > +Example: > + cci: cci { > + compatible = "mediatek,mt8183-cci"; > + clocks = <&apmixedsys CLK_APMIXED_CCIPLL>; > + clock-names = "cci_clock"; Recommend to use 'cci' without '_clock' because we can know that it's clock name event if '_clock'. > + operating-points-v2 = <&cci_opp>; > + }; > + > + &cci { > + proc-supply = <&mt6358_vproc12_reg>; > + }; > \ No newline at end of file > -- Best Regards, Chanwoo Choi Samsung Electronics _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi, On 11/26/19 8:50 PM, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > 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. What is correct full word of SVS? - S(?) VS (Voltage Scaling) ? > depend on: > https://patchwork.kernel.org/patch/11193513/ > > Change since v4: > - Remove redundant code > > > Andrew-sh.Cheng (5): > cpufreq: mediatek: add clock enable for intermediate clock > dt-bindings: devfreq: add compatible for mt8183 cci devfreq > devfreq: add mediatek cci devfreq > cpufreq: mediatek: add opp notification for SVS support > devfreq: mediatek: cci devfreq register opp notification for SVS > support > > .../bindings/devfreq/mt8183-cci-devfreq.txt | 20 ++ > drivers/cpufreq/mediatek-cpufreq.c | 92 +++++- > drivers/devfreq/Kconfig | 10 + > drivers/devfreq/Makefile | 1 + > drivers/devfreq/mt8183-cci-devfreq.c | 308 +++++++++++++++++++++ > 5 files changed, 429 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt > create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c > -- Best Regards, Chanwoo Choi Samsung Electronics _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi, "mtk_cci_vmon" governor looks like the devfreq passive governor. But, the existing devfreq passive governor depend on the other devfreq device. "mtk_cci_vmon" governor depend on the regulator with regulator notifier. I think that it is better to extend the passive governor in order to support the regulator notifier. It is possible because passive governor already used the devfreq notifier. Previously, the patch[1] tried to add the cpu based scaling to passive governor. [1] https://lore.kernel.org/patchwork/patch/1101049/ - [RFC,v2] PM / devfreq: Add cpu based scaling support to passive_governor Regards, Chanwoo Choi On 11/26/19 8:50 PM, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > 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 | 247 +++++++++++++++++++++++++++++++++++ > 3 files changed, 258 insertions(+) > create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index defe1d438710..76bc42657787 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -92,6 +92,16 @@ config ARM_EXYNOS_BUS_DEVFREQ > and adjusts the operating frequencies and voltages with OPP support. > This does not yet operate with optimal voltages. > > +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. > + 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 338ae8440db6..1fa05e39e4ff 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o > > # DEVFREQ Drivers > obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.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..818a167c442f > --- /dev/null > +++ b/drivers/devfreq/mt8183-cci-devfreq.c > @@ -0,0 +1,247 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. > + > + * 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 "governor.h" > + > +struct cci_devfreq { > + struct devfreq *devfreq; > + struct regulator *proc_reg; > + unsigned long proc_reg_uV; > + struct clk *cci_clk; > + struct notifier_block nb; > +}; > + > +static int cci_devfreq_regulator_notifier(struct notifier_block *nb, > + unsigned long val, void *data) > +{ > + int ret; > + struct cci_devfreq *cci_df = > + container_of(nb, struct cci_devfreq, nb); > + > + /* deal with reduce frequency */ > + if (val & REGULATOR_EVENT_PRE_VOLTAGE_CHANGE) { > + struct pre_voltage_change_data *pvc_data = data; > + > + if (pvc_data->min_uV < pvc_data->old_uV) { > + cci_df->proc_reg_uV = > + (unsigned long)(pvc_data->min_uV); > + mutex_lock(&cci_df->devfreq->lock); > + ret = update_devfreq(cci_df->devfreq); > + if (ret) > + pr_err("Fail to reduce cci frequency: %d\n", > + ret); > + mutex_unlock(&cci_df->devfreq->lock); > + } > + } else if ((val & REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE) && > + ((unsigned long)data > cci_df->proc_reg_uV)) { > + cci_df->proc_reg_uV = (unsigned long)data; > + mutex_lock(&cci_df->devfreq->lock); > + ret = update_devfreq(cci_df->devfreq); > + if (ret) > + pr_err("Fail to raise cci frequency back: %d\n", ret); > + mutex_unlock(&cci_df->devfreq->lock); > + } else if ((val & REGULATOR_EVENT_VOLTAGE_CHANGE) && > + (cci_df->proc_reg_uV < (unsigned long)data)) { > + /* deal with increase frequency */ > + cci_df->proc_reg_uV = (unsigned long)data; > + mutex_lock(&cci_df->devfreq->lock); > + ret = update_devfreq(cci_df->devfreq); > + if (ret) > + pr_err("Fail to raise cci frequency: %d\n", ret); > + mutex_unlock(&cci_df->devfreq->lock); > + } > + > + return 0; > +} > + > +static int mtk_cci_governor_get_target(struct devfreq *devfreq, > + unsigned long *freq) > +{ > + struct cci_devfreq *cci_df; > + struct dev_pm_opp *opp; > + > + cci_df = dev_get_drvdata(devfreq->dev.parent); > + > + /* find available frequency */ > + opp = dev_pm_opp_find_freq_ceil_by_volt(devfreq->dev.parent, > + cci_df->proc_reg_uV); > + *freq = dev_pm_opp_get_freq(opp); > + > + return 0; > +} > + > +static int mtk_cci_governor_event_handler(struct devfreq *devfreq, > + unsigned int event, void *data) > +{ > + int ret; > + struct cci_devfreq *cci_df; > + struct notifier_block *nb; > + > + cci_df = dev_get_drvdata(devfreq->dev.parent); > + nb = &cci_df->nb; > + > + switch (event) { > + case DEVFREQ_GOV_START: > + case DEVFREQ_GOV_RESUME: > + nb->notifier_call = cci_devfreq_regulator_notifier; > + ret = regulator_register_notifier(cci_df->proc_reg, > + nb); > + if (ret) > + pr_err("%s: failed to add governor: %d\n", __func__, > + ret); > + break; > + > + case DEVFREQ_GOV_STOP: > + case DEVFREQ_GOV_SUSPEND: > + ret = regulator_unregister_notifier(cci_df->proc_reg, > + nb); > + if (ret) > + pr_err("%s: failed to add governor: %d\n", __func__, > + ret); > + break; > + > + default: > + break; > + } > + > + return 0; > +} > + > +static struct devfreq_governor mtk_cci_devfreq_governor = { > + .name = "mtk_cci_vmon", > + .get_target_freq = mtk_cci_governor_get_target, > + .event_handler = mtk_cci_governor_event_handler, > + .immutable = true > +}; > + > +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); > + > + if (!cci_df) > + return -EINVAL; > + > + ret = clk_set_rate(cci_df->cci_clk, *freq); > + if (ret) { > + pr_err("%s: failed cci to set rate: %d\n", __func__, > + ret); > + return ret; > + } > + > + return 0; > +} > + > +static struct devfreq_dev_profile cci_devfreq_profile = { > + .target = mtk_cci_devfreq_target, > +}; > + > +static int mtk_cci_devfreq_probe(struct platform_device *pdev) > +{ > + struct device *cci_dev = &pdev->dev; > + struct cci_devfreq *cci_df; > + 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; > + } > + > + ret = dev_pm_opp_of_add_table(cci_dev); > + if (ret) { > + dev_err(cci_dev, "Fail to init CCI OPP table: %d\n", ret); > + return ret; > + } > + > + platform_set_drvdata(pdev, cci_df); > + > + cci_df->devfreq = devm_devfreq_add_device(cci_dev, > + &cci_devfreq_profile, > + "mtk_cci_vmon", > + NULL); > + 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); > + return ret; > + } > + > + return 0; > +} > + > +static const __maybe_unused struct of_device_id > + mediatek_cci_devfreq_of_match[] = { > + { .compatible = "mediatek,mt8183-cci" }, > + { }, > +}; > +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match); > + > +static struct platform_driver cci_devfreq_driver = { > + .probe = mtk_cci_devfreq_probe, > + .driver = { > + .name = "mediatek-cci-devfreq", > + .of_match_table = of_match_ptr(mediatek_cci_devfreq_of_match), > + }, > +}; > + > +static int __init mtk_cci_devfreq_init(void) > +{ > + int ret; > + > + ret = devfreq_add_governor(&mtk_cci_devfreq_governor); > + if (ret) { > + pr_err("%s: failed to add governor: %d\n", __func__, ret); > + return ret; > + } > + > + ret = platform_driver_register(&cci_devfreq_driver); > + if (ret) > + devfreq_remove_governor(&mtk_cci_devfreq_governor); > + > + return ret; > +} > +module_init(mtk_cci_devfreq_init) Use module_platform_driver > + > +static void __exit mtk_cci_devfreq_exit(void) > +{ > + int ret; > + > + ret = devfreq_remove_governor(&mtk_cci_devfreq_governor); > + if (ret) > + pr_err("%s: failed to remove governor: %d\n", __func__, ret); > + > + platform_driver_unregister(&cci_devfreq_driver); > +} > +module_exit(mtk_cci_devfreq_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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Tue, 2019-12-10 at 14:43 +0800, Viresh Kumar wrote: > On 09-12-19, 14:56, andrew-sh.cheng wrote: > > On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > > > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > > > + if (!IS_ERR(opp_item)) > > > > + dev_pm_opp_put(opp_item); > > > > + else > > > > + freq = 0; > > > > + > > > > > > What is the purpose of the above code ? > > When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq > > value won't be set. > > Set it as 0 for below checking > > > > > > > + /* case of current opp is disabled */ > > > > + if (freq == 0 || freq != info->opp_freq) { > > > > + // find an enable opp item > > > > + freq = 1; > > > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > > > + &freq); > > > > + if (!IS_ERR(opp_item)) { > > > > + dev_pm_opp_put(opp_item); > > > > + policy = cpufreq_cpu_get(info->opp_cpu); > > > > + if (policy) { > > > > + cpufreq_driver_target(policy, > > > > + freq / 1000, > > > > + CPUFREQ_RELATION_L); > > > > > > Why don't you simply call this instead of all the code in the else > > > block ? > > These else code is used to check "current opp item is disabled or not". > > If not, do nothing. > > If current opp item is disabled, need to find an not-disabled opp item, > > and set frequency to it. > > Right. So this notifier helper of yours receive the opp which is getting > disabled, why don't you compare its frequency directly to see if the current OPP > is getting disabled ? Sorry to overlook your question. This is because when the opp is disabled, we cannot use dev_pm_opp_get_freq() to get frequency of that opp. There is a check: if (IS_ERR_OR_NULL(opp) || !opp->available) { pr_err("%s: Invalid parameters\n", __func__); return 0; > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 10-03-20, 16:11, andrew-sh.cheng wrote: > On Tue, 2019-12-10 at 14:43 +0800, Viresh Kumar wrote: > > On 09-12-19, 14:56, andrew-sh.cheng wrote: > > > On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > > > > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > > > > + if (!IS_ERR(opp_item)) > > > > > + dev_pm_opp_put(opp_item); > > > > > + else > > > > > + freq = 0; > > > > > + > > > > > > > > What is the purpose of the above code ? > > > When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq > > > value won't be set. > > > Set it as 0 for below checking > > > > > > > > > + /* case of current opp is disabled */ > > > > > + if (freq == 0 || freq != info->opp_freq) { > > > > > + // find an enable opp item > > > > > + freq = 1; > > > > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > > > > + &freq); > > > > > + if (!IS_ERR(opp_item)) { > > > > > + dev_pm_opp_put(opp_item); > > > > > + policy = cpufreq_cpu_get(info->opp_cpu); > > > > > + if (policy) { > > > > > + cpufreq_driver_target(policy, > > > > > + freq / 1000, > > > > > + CPUFREQ_RELATION_L); > > > > > > > > Why don't you simply call this instead of all the code in the else > > > > block ? > > > These else code is used to check "current opp item is disabled or not". > > > If not, do nothing. > > > If current opp item is disabled, need to find an not-disabled opp item, > > > and set frequency to it. > > > > Right. So this notifier helper of yours receive the opp which is getting > > disabled, why don't you compare its frequency directly to see if the current OPP > > is getting disabled ? > Sorry to overlook your question. > This is because when the opp is disabled, > we cannot use dev_pm_opp_get_freq() to get frequency of that opp. > There is a check: > if (IS_ERR_OR_NULL(opp) || !opp->available) { I think we can remove the available check here, as we are jut trying to find frequency of an OPP we already have. Send a patch for that please. > pr_err("%s: Invalid parameters\n", __func__); > return 0; > > > > -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Wed, 2020-03-11 at 11:36 +0530, Viresh Kumar wrote: > On 10-03-20, 16:11, andrew-sh.cheng wrote: > > On Tue, 2019-12-10 at 14:43 +0800, Viresh Kumar wrote: > > > On 09-12-19, 14:56, andrew-sh.cheng wrote: > > > > On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > > > > > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > > > > > + if (!IS_ERR(opp_item)) > > > > > > + dev_pm_opp_put(opp_item); > > > > > > + else > > > > > > + freq = 0; > > > > > > + > > > > > > > > > > What is the purpose of the above code ? > > > > When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq > > > > value won't be set. > > > > Set it as 0 for below checking > > > > > > > > > > > + /* case of current opp is disabled */ > > > > > > + if (freq == 0 || freq != info->opp_freq) { > > > > > > + // find an enable opp item > > > > > > + freq = 1; > > > > > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > > > > > + &freq); > > > > > > + if (!IS_ERR(opp_item)) { > > > > > > + dev_pm_opp_put(opp_item); > > > > > > + policy = cpufreq_cpu_get(info->opp_cpu); > > > > > > + if (policy) { > > > > > > + cpufreq_driver_target(policy, > > > > > > + freq / 1000, > > > > > > + CPUFREQ_RELATION_L); > > > > > > > > > > Why don't you simply call this instead of all the code in the else > > > > > block ? > > > > These else code is used to check "current opp item is disabled or not". > > > > If not, do nothing. > > > > If current opp item is disabled, need to find an not-disabled opp item, > > > > and set frequency to it. > > > > > > Right. So this notifier helper of yours receive the opp which is getting > > > disabled, why don't you compare its frequency directly to see if the current OPP > > > is getting disabled ? > > Sorry to overlook your question. > > This is because when the opp is disabled, > > we cannot use dev_pm_opp_get_freq() to get frequency of that opp. > > There is a check: > > if (IS_ERR_OR_NULL(opp) || !opp->available) { > > I think we can remove the available check here, as we are jut trying > to find frequency of an OPP we already have. Send a patch for that > please. Got it. I will do it at next patch set. > > > pr_err("%s: Invalid parameters\n", __func__); > > return 0; > > > > > > > > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Wed, 2020-03-11 at 11:36 +0530, Viresh Kumar wrote: > On 10-03-20, 16:11, andrew-sh.cheng wrote: > > On Tue, 2019-12-10 at 14:43 +0800, Viresh Kumar wrote: > > > On 09-12-19, 14:56, andrew-sh.cheng wrote: > > > > On Wed, 2019-11-27 at 14:06 +0530, Viresh Kumar wrote: > > > > > On 26-11-19, 19:50, Andrew-sh.Cheng wrote: > > > > > > + if (!IS_ERR(opp_item)) > > > > > > + dev_pm_opp_put(opp_item); > > > > > > + else > > > > > > + freq = 0; > > > > > > + > > > > > > > > > > What is the purpose of the above code ? > > > > When dev_pm_opp_find_freq_ceil() doesn't find matching opp item, freq > > > > value won't be set. > > > > Set it as 0 for below checking > > > > > > > > > > > + /* case of current opp is disabled */ > > > > > > + if (freq == 0 || freq != info->opp_freq) { > > > > > > + // find an enable opp item > > > > > > + freq = 1; > > > > > > + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, > > > > > > + &freq); > > > > > > + if (!IS_ERR(opp_item)) { > > > > > > + dev_pm_opp_put(opp_item); > > > > > > + policy = cpufreq_cpu_get(info->opp_cpu); > > > > > > + if (policy) { > > > > > > + cpufreq_driver_target(policy, > > > > > > + freq / 1000, > > > > > > + CPUFREQ_RELATION_L); > > > > > > > > > > Why don't you simply call this instead of all the code in the else > > > > > block ? > > > > These else code is used to check "current opp item is disabled or not". > > > > If not, do nothing. > > > > If current opp item is disabled, need to find an not-disabled opp item, > > > > and set frequency to it. > > > > > > Right. So this notifier helper of yours receive the opp which is getting > > > disabled, why don't you compare its frequency directly to see if the current OPP > > > is getting disabled ? > > Sorry to overlook your question. > > This is because when the opp is disabled, > > we cannot use dev_pm_opp_get_freq() to get frequency of that opp. > > There is a check: > > if (IS_ERR_OR_NULL(opp) || !opp->available) { > > I think we can remove the available check here, as we are jut trying > to find frequency of an OPP we already have. Send a patch for that > please. > Hi Viresh, I have something want to consult you. For your previous comment, you suggest use read-write lock to replace mutex lock. Will it be more efficiently even when all are write lock? (all lock region are "setting VProc voltage") > > pr_err("%s: Invalid parameters\n", __func__); > > return 0; > > > > > > > > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 13-03-20, 15:22, andrew-sh.cheng wrote: > I have something want to consult you. > For your previous comment, you suggest use read-write lock to replace > mutex lock. > Will it be more efficiently even when all are write lock? > (all lock region are "setting VProc voltage") The data to be protected here isn't the VProc voltage but the list of valid OPPs. My idea was if we can make the target() routine run a bit faster as it really matters as it is called from scheduler hot path. It won't be wrong to use the mutex the way you have used it right now, but I think the read lock is much faster, though the read/write lock is more beneficial in case where there are multiple readers and fewer writers. The target() routine gets called multiple times here, not in parallel, and the OPP change notifier won't be called so often. -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Fri, 2020-03-13 at 14:40 +0530, Viresh Kumar wrote: > On 13-03-20, 15:22, andrew-sh.cheng wrote: > > I have something want to consult you. > > For your previous comment, you suggest use read-write lock to replace > > mutex lock. > > Will it be more efficiently even when all are write lock? > > (all lock region are "setting VProc voltage") > > The data to be protected here isn't the VProc voltage but the list of > valid OPPs. My idea was if we can make the target() routine run a bit > faster as it really matters as it is called from scheduler hot path. > > It won't be wrong to use the mutex the way you have used it right now, > but I think the read lock is much faster, though the read/write lock > is more beneficial in case where there are multiple readers and fewer > writers. The target() routine gets called multiple times here, not > in parallel, and the OPP change notifier won't be called so often. > Hi Viresh, I will use regulator in the locked region. And regulator will use mutex_lock. I use read_lock/write_lock, and there will be below run time error, Is it due to read_lock/write_lock using spin lock? write_lock() => _raw_write_lock() @ spinlock.c Please give me some advices. Thank you. [ 28.109082] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254 [ 28.117710] in_atomic(): 1, irqs_disabled(): 0, pid: 1855, name: sugov:0 [ 28.124788] CPU: 0 PID: 1855 Comm: sugov:0 Tainted: G W 4.19.107 #51 [ 28.132440] Hardware name: MediaTek krane sku176 board (DT) [ 28.138006] Call trace: [ 28.140461] dump_backtrace+0x0/0x17c [ 28.144121] show_stack+0x20/0x2c [ 28.147432] dump_stack+0xd4/0x10c [ 28.150831] ___might_sleep+0x108/0x118 [ 28.154659] __might_sleep+0x50/0x84 [ 28.158230] mutex_lock+0x28/0x60 [ 28.161541] regulator_lock_dependent+0x3c/0x10c [ 28.166152] regulator_set_voltage+0x48/0xa0 [ 28.170417] mtk_cpufreq_set_voltage+0x16c/0x324 [ 28.175046] mtk_cpufreq_set_target+0x13c/0x2c8 [ 28.179574] __cpufreq_driver_target+0x424/0x4c4 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 06-04-20, 17:12, andrew-sh.cheng wrote: > I will use regulator in the locked region. > And regulator will use mutex_lock. Yeah, you can't use spinlock here, use a mutex. -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Mon, 2020-04-06 at 14:59 +0530, Viresh Kumar wrote: > On 06-04-20, 17:12, andrew-sh.cheng wrote: > > I will use regulator in the locked region. > > And regulator will use mutex_lock. > > Yeah, you can't use spinlock here, use a mutex. > Hi Viresh, I am not familiar with read/write lock. Do you mean there is another read/write function, which is not read_lock()/write_lock(), using mutex but not spinlock? Could you kindly tell me the functions. Thank you. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 07-04-20, 14:54, andrew-sh.cheng wrote: > On Mon, 2020-04-06 at 14:59 +0530, Viresh Kumar wrote: > > On 06-04-20, 17:12, andrew-sh.cheng wrote: > > > I will use regulator in the locked region. > > > And regulator will use mutex_lock. > > > > Yeah, you can't use spinlock here, use a mutex. > > > Hi Viresh, > > I am not familiar with read/write lock. > Do you mean there is another read/write function, which is not > read_lock()/write_lock(), using mutex but not spinlock? Heh, I am asking you to use simple mutex here, leave the read/write lock thing completely as it won't work here. -- viresh _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Tue, 2020-04-07 at 13:59 +0530, Viresh Kumar wrote: > On 07-04-20, 14:54, andrew-sh.cheng wrote: > > On Mon, 2020-04-06 at 14:59 +0530, Viresh Kumar wrote: > > > On 06-04-20, 17:12, andrew-sh.cheng wrote: > > > > I will use regulator in the locked region. > > > > And regulator will use mutex_lock. > > > > > > Yeah, you can't use spinlock here, use a mutex. > > > > > Hi Viresh, > > > > I am not familiar with read/write lock. > > Do you mean there is another read/write function, which is not > > read_lock()/write_lock(), using mutex but not spinlock? > > Heh, I am asking you to use simple mutex here, leave the read/write > lock thing completely as it won't work here. > Got it. Thank you for your patient~ _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek