* Re: [v4, 2/8] cpufreq: mediatek: add clock enable for intermediate clock [not found] ` <1565703113-31479-3-git-send-email-andrew-sh.cheng@mediatek.com> @ 2019-08-19 9:50 ` Viresh Kumar 0 siblings, 0 replies; 10+ messages in thread From: Viresh Kumar @ 2019-08-19 9:50 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > 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, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index a370577ffc73..acd9539e95de 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); > > @@ -419,6 +426,10 @@ static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info) > clk_put(info->cpu_clk); > if (!IS_ERR(info->inter_clk)) > clk_put(info->inter_clk); Shouldn't you remove this part now ? > + 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 -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1565703113-31479-2-git-send-email-andrew-sh.cheng@mediatek.com>]
* Re: [v4, 1/8] cpufreq: mediatek: change to regulator_get_optional [not found] ` <1565703113-31479-2-git-send-email-andrew-sh.cheng@mediatek.com> @ 2019-08-19 9:51 ` Viresh Kumar 0 siblings, 0 replies; 10+ messages in thread From: Viresh Kumar @ 2019-08-19 9:51 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > For new mediatek chip mt8183, > cci and little cluster share the same buck, > so need to modify the attribute of regulator from exclusive to optional > > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > drivers/cpufreq/mediatek-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index f14f3a85f2f7..a370577ffc73 100644 > --- a/drivers/cpufreq/mediatek-cpufreq.c > +++ b/drivers/cpufreq/mediatek-cpufreq.c > @@ -338,7 +338,7 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > goto out_free_resources; > } > > - proc_reg = regulator_get_exclusive(cpu_dev, "proc"); > + proc_reg = regulator_get_optional(cpu_dev, "proc"); > if (IS_ERR(proc_reg)) { > if (PTR_ERR(proc_reg) == -EPROBE_DEFER) > pr_warn("proc regulator for cpu%d not ready, retry.\n", Applied. Thanks. -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1565703113-31479-4-git-send-email-andrew-sh.cheng@mediatek.com>]
* Re: [v4, 3/8] cpufreq: mediatek: Add support for mt8183 [not found] ` <1565703113-31479-4-git-send-email-andrew-sh.cheng@mediatek.com> @ 2019-08-19 9:59 ` Viresh Kumar 0 siblings, 0 replies; 10+ messages in thread From: Viresh Kumar @ 2019-08-19 9:59 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > Add compatible string for mediatek mt8183 > > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> > --- > drivers/cpufreq/cpufreq-dt-platdev.c | 1 + > drivers/cpufreq/mediatek-cpufreq.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > index 03dc4244ab00..0f7e837a264e 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -117,6 +117,7 @@ static const struct of_device_id blacklist[] __initconst = { > { .compatible = "mediatek,mt817x", }, > { .compatible = "mediatek,mt8173", }, > { .compatible = "mediatek,mt8176", }, > + { .compatible = "mediatek,mt8183", }, > > { .compatible = "nvidia,tegra124", }, > { .compatible = "nvidia,tegra210", }, > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index acd9539e95de..4dce41b18369 100644 > --- a/drivers/cpufreq/mediatek-cpufreq.c > +++ b/drivers/cpufreq/mediatek-cpufreq.c > @@ -546,6 +546,7 @@ static const struct of_device_id mtk_cpufreq_machines[] __initconst = { > { .compatible = "mediatek,mt817x", }, > { .compatible = "mediatek,mt8173", }, > { .compatible = "mediatek,mt8176", }, > + { .compatible = "mediatek,mt8183", }, Had to fix rebase conflict manually for this. Please always rebase on latest linux-next. Applied. Thanks. -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1565703113-31479-8-git-send-email-andrew-sh.cheng@mediatek.com>]
* Re: [v4, 7/8] cpufreq: mediatek: add opp notification for SVS support [not found] ` <1565703113-31479-8-git-send-email-andrew-sh.cheng@mediatek.com> @ 2019-08-20 3:39 ` Viresh Kumar [not found] ` <1571193828.22071.5.camel@mtksdaap41> 0 siblings, 1 reply; 10+ messages in thread From: Viresh Kumar @ 2019-08-20 3:39 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > 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 | 78 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 78 insertions(+) > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c > index 4dce41b18369..9820c8003507 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,74 @@ 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) { Does this ever get called for your platform ? Why are you using opp disable ? Maybe we can avoid it completely. > + 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 +451,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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1571193828.22071.5.camel@mtksdaap41>]
* Re: [v4, 7/8] cpufreq: mediatek: add opp notification for SVS support [not found] ` <1571193828.22071.5.camel@mtksdaap41> @ 2019-10-17 6:31 ` Viresh Kumar [not found] ` <1571389431.27207.4.camel@mtksdaap41> 0 siblings, 1 reply; 10+ messages in thread From: Viresh Kumar @ 2019-10-17 6: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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Fan Chen (陳凡) On 16-10-19, 10:43, andrew-sh.cheng wrote: > This is due to SVS feature need to fix Vproc for calibration. > When SVS calibration, it want to disable all opp items, except one with > voltae 1.0V. (SVS will change the voltage field of that opp item, if the > corresponding voltage is not 1.0V) > In this way, SVS can make sure there is no other module, include > thermal, will change Vproc by DVFS driver. > After SVS calibration done, SVS will enable those disabled opp items > back. But why is this required to be done this way ? Why can't we just update the voltages without doing this disable/enable dance ? -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1571389431.27207.4.camel@mtksdaap41>]
* Re: [v4, 7/8] cpufreq: mediatek: add opp notification for SVS support [not found] ` <1571389431.27207.4.camel@mtksdaap41> @ 2019-10-18 9:53 ` Viresh Kumar 0 siblings, 0 replies; 10+ messages in thread From: Viresh Kumar @ 2019-10-18 9:53 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Fan Chen (陳凡) On 18-10-19, 17:03, andrew-sh.cheng wrote: > On Thu, 2019-10-17 at 12:01 +0530, Viresh Kumar wrote: > > On 16-10-19, 10:43, andrew-sh.cheng wrote: > > > This is due to SVS feature need to fix Vproc for calibration. > > > When SVS calibration, it want to disable all opp items, except one with > > > voltae 1.0V. (SVS will change the voltage field of that opp item, if the > > > corresponding voltage is not 1.0V) > > > In this way, SVS can make sure there is no other module, include > > > thermal, will change Vproc by DVFS driver. > > > After SVS calibration done, SVS will enable those disabled opp items > > > back. > > > > But why is this required to be done this way ? Why can't we just update the > > voltages without doing this disable/enable dance ? > > > This is because some opp items need voltage larger than 1.0V. > We cannot update the voltage to 1.0V. > > If we don't disable these opp items, and DVFS policy want to set these > high frequencies, dvfs driver will set higher voltage to Vproc and SVS > calibration will be fail. Okay. -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com>]
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime [not found] ` <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com> @ 2019-08-19 11:18 ` Viresh Kumar 2019-11-01 8:08 ` Roger Lu 2019-08-22 13:51 ` Matthias Brugger 1 sibling, 1 reply; 10+ messages in thread From: Viresh Kumar @ 2019-08-19 11:18 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, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen, Stephen Boyd, Roger Lu On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > From: Stephen Boyd <sboyd@codeaurora.org> > > On some SoCs the Adaptive Voltage Scaling (AVS) technique is > employed to optimize the operating voltage of a device. At a > given frequency, the hardware monitors dynamic factors and either > makes a suggestion for how much to adjust a voltage for the > current frequency, or it automatically adjusts the voltage > without software intervention. Add an API to the OPP library for > the former case, so that AVS type devices can update the voltages > for an OPP when the hardware determines the voltage should > change. The assumption is that drivers like CPUfreq or devfreq > will register for the OPP notifiers and adjust the voltage > according to suggestions that AVS makes. > > This patch is devired from [1] submitted by Stephen. > [1] https://lore.kernel.org/patchwork/patch/599279/ > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > Signed-off-by: Roger Lu <roger.lu@mediatek.com> > --- > drivers/opp/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/pm_opp.h | 11 +++++++++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index c094d5d20fd7..407a07f29b12 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -2054,6 +2054,69 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, > } > > /** > + * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP > + * @dev: device for which we do this operation > + * @freq: OPP frequency to adjust voltage of > + * @u_volt: new OPP voltage > + * > + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > + * copy operation, returns 0 if no modifcation was done OR modification was > + * successful. > + */ > +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > + unsigned long u_volt) Can you please update this to take a triplet instead ? That is what we are storing in OPP core now a days. -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime 2019-08-19 11:18 ` [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime Viresh Kumar @ 2019-11-01 8:08 ` Roger Lu 2019-11-05 6:56 ` Viresh Kumar 0 siblings, 1 reply; 10+ messages in thread From: Roger Lu @ 2019-11-01 8:08 UTC (permalink / raw) To: Viresh Kumar Cc: Andrew-sh Cheng (鄭式勳), MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J. Wysocki, Nishanth Menon, Stephen Boyd, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Fan Chen (陳凡), Stephen Boyd Dear Viresh, Sorry for the late reply. On Mon, 2019-08-19 at 19:18 +0800, Viresh Kumar wrote: > On 13-08-19, 21:31, Andrew-sh.Cheng wrote: > > From: Stephen Boyd <sboyd@codeaurora.org> > > > > On some SoCs the Adaptive Voltage Scaling (AVS) technique is > > employed to optimize the operating voltage of a device. At a > > given frequency, the hardware monitors dynamic factors and either > > makes a suggestion for how much to adjust a voltage for the > > current frequency, or it automatically adjusts the voltage > > without software intervention. Add an API to the OPP library for > > the former case, so that AVS type devices can update the voltages > > for an OPP when the hardware determines the voltage should > > change. The assumption is that drivers like CPUfreq or devfreq > > will register for the OPP notifiers and adjust the voltage > > according to suggestions that AVS makes. > > > > This patch is devired from [1] submitted by Stephen. > > [1] https://lore.kernel.org/patchwork/patch/599279/ > > > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > > Signed-off-by: Roger Lu <roger.lu@mediatek.com> > > --- > > drivers/opp/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > include/linux/pm_opp.h | 11 +++++++++ > > 2 files changed, 74 insertions(+) > > > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > > index c094d5d20fd7..407a07f29b12 100644 > > --- a/drivers/opp/core.c > > +++ b/drivers/opp/core.c > > @@ -2054,6 +2054,69 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, > > } > > > > /** > > + * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP > > + * @dev: device for which we do this operation > > + * @freq: OPP frequency to adjust voltage of > > + * @u_volt: new OPP voltage > > + * > > + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > > + * copy operation, returns 0 if no modifcation was done OR modification was > > + * successful. > > + */ > > +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > > + unsigned long u_volt) > > Can you please update this to take a triplet instead ? That is what we are > storing in OPP core now a days. I've studied opp/core.c and still don't know meaning of triplet here. Could you give me more hints (reference API?) about how to take a triplet instead? Thanks in advance. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime 2019-11-01 8:08 ` Roger Lu @ 2019-11-05 6:56 ` Viresh Kumar 0 siblings, 0 replies; 10+ messages in thread From: Viresh Kumar @ 2019-11-05 6:56 UTC (permalink / raw) To: Roger Lu Cc: Andrew-sh Cheng (鄭式勳), MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger, Rafael J. Wysocki, Nishanth Menon, Stephen Boyd, linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, Fan Chen (陳凡), Stephen Boyd On 01-11-19, 16:08, Roger Lu wrote: > I've studied opp/core.c and still don't know meaning of triplet here. > Could you give me more hints (reference API?) about how to take a > triplet instead? Thanks in advance. I was hoping you to follow this thread :) https://lore.kernel.org/linux-arm-kernel/20191016145756.16004-2-s.nawrocki@samsung.com/ I already applied this patch to the OPP tree. -- viresh ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime [not found] ` <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-19 11:18 ` [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime Viresh Kumar @ 2019-08-22 13:51 ` Matthias Brugger 1 sibling, 0 replies; 10+ messages in thread From: Matthias Brugger @ 2019-08-22 13:51 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 Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream, fan.chen, Stephen Boyd, Roger Lu On 13/08/2019 15:31, Andrew-sh.Cheng wrote: > From: Stephen Boyd <sboyd@codeaurora.org> > > On some SoCs the Adaptive Voltage Scaling (AVS) technique is > employed to optimize the operating voltage of a device. At a > given frequency, the hardware monitors dynamic factors and either > makes a suggestion for how much to adjust a voltage for the > current frequency, or it automatically adjusts the voltage > without software intervention. Add an API to the OPP library for > the former case, so that AVS type devices can update the voltages > for an OPP when the hardware determines the voltage should > change. The assumption is that drivers like CPUfreq or devfreq > will register for the OPP notifiers and adjust the voltage > according to suggestions that AVS makes. > > This patch is devired from [1] submitted by Stephen. > [1] https://lore.kernel.org/patchwork/patch/599279/ > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > Signed-off-by: Roger Lu <roger.lu@mediatek.com> Nit: your signed-off-by tag is missing. Regards, Matthias > --- > drivers/opp/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/pm_opp.h | 11 +++++++++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index c094d5d20fd7..407a07f29b12 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -2054,6 +2054,69 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, > } > > /** > + * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP > + * @dev: device for which we do this operation > + * @freq: OPP frequency to adjust voltage of > + * @u_volt: new OPP voltage > + * > + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > + * copy operation, returns 0 if no modifcation was done OR modification was > + * successful. > + */ > +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > + unsigned long u_volt) > +{ > + struct opp_table *opp_table; > + struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV); > + int r = 0; > + > + /* Find the opp_table */ > + opp_table = _find_opp_table(dev); > + if (IS_ERR(opp_table)) { > + r = PTR_ERR(opp_table); > + dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r); > + return r; > + } > + > + mutex_lock(&opp_table->lock); > + > + /* Do we have the frequency? */ > + list_for_each_entry(tmp_opp, &opp_table->opp_list, node) { > + if (tmp_opp->rate == freq) { > + opp = tmp_opp; > + break; > + } > + } > + > + if (IS_ERR(opp)) { > + r = PTR_ERR(opp); > + goto adjust_unlock; > + } > + > + /* Is update really needed? */ > + if (opp->supplies->u_volt == u_volt) > + goto adjust_unlock; > + > + opp->supplies->u_volt = u_volt; > + > + dev_pm_opp_get(opp); > + mutex_unlock(&opp_table->lock); > + > + /* Notify the voltage change of the OPP */ > + blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_ADJUST_VOLTAGE, > + opp); > + > + dev_pm_opp_put(opp); > + goto adjust_put_table; > + > +adjust_unlock: > + mutex_unlock(&opp_table->lock); > +adjust_put_table: > + dev_pm_opp_put_opp_table(opp_table); > + return r; > +} > + > +/** > * dev_pm_opp_enable() - Enable a specific OPP > * @dev: device for which we do this operation > * @freq: OPP frequency to enable > diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h > index af5021f27cb7..86947d53e8c4 100644 > --- a/include/linux/pm_opp.h > +++ b/include/linux/pm_opp.h > @@ -22,6 +22,7 @@ struct opp_table; > > enum dev_pm_opp_event { > OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_ENABLE, OPP_EVENT_DISABLE, > + OPP_EVENT_ADJUST_VOLTAGE, > }; > > /** > @@ -111,6 +112,9 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, > void dev_pm_opp_remove(struct device *dev, unsigned long freq); > void dev_pm_opp_remove_all_dynamic(struct device *dev); > > +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > + unsigned long u_volt); > + > int dev_pm_opp_enable(struct device *dev, unsigned long freq); > > int dev_pm_opp_disable(struct device *dev, unsigned long freq); > @@ -234,6 +238,13 @@ static inline void dev_pm_opp_remove_all_dynamic(struct device *dev) > { > } > > +static inline int > +dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > + unsigned long u_volt) > +{ > + return 0; > +} > + > static inline int dev_pm_opp_enable(struct device *dev, unsigned long freq) > { > return 0; > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-11-05 6:56 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1565703113-31479-1-git-send-email-andrew-sh.cheng@mediatek.com> [not found] ` <1565703113-31479-3-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-19 9:50 ` [v4, 2/8] cpufreq: mediatek: add clock enable for intermediate clock Viresh Kumar [not found] ` <1565703113-31479-2-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-19 9:51 ` [v4, 1/8] cpufreq: mediatek: change to regulator_get_optional Viresh Kumar [not found] ` <1565703113-31479-4-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-19 9:59 ` [v4, 3/8] cpufreq: mediatek: Add support for mt8183 Viresh Kumar [not found] ` <1565703113-31479-8-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-20 3:39 ` [v4, 7/8] cpufreq: mediatek: add opp notification for SVS support Viresh Kumar [not found] ` <1571193828.22071.5.camel@mtksdaap41> 2019-10-17 6:31 ` Viresh Kumar [not found] ` <1571389431.27207.4.camel@mtksdaap41> 2019-10-18 9:53 ` Viresh Kumar [not found] ` <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com> 2019-08-19 11:18 ` [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime Viresh Kumar 2019-11-01 8:08 ` Roger Lu 2019-11-05 6:56 ` Viresh Kumar 2019-08-22 13:51 ` Matthias Brugger
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).