From: Sibi Sankar <sibis@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: sboyd@kernel.org, georgi.djakov@linaro.org, saravanak@google.com,
mka@chromium.org, nm@ti.com, bjorn.andersson@linaro.org,
agross@kernel.org, rjw@rjwysocki.net,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, dianders@chromium.org,
vincent.guittot@linaro.org, amit.kucheria@linaro.org,
lukasz.luba@arm.com, sudeep.holla@arm.com,
smasetty@codeaurora.org, linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH v5 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change
Date: Fri, 29 May 2020 17:00:57 +0530 [thread overview]
Message-ID: <a90bce2d52f7cdb726e8b799e3512fad@codeaurora.org> (raw)
In-Reply-To: <20200529100028.2wz2iqi5vqji2heb@vireshk-i7>
Hey Viresh,
Thanks for taking time to review the
series :)
On 2020-05-29 15:30, Viresh Kumar wrote:
> On 28-05-20, 01:51, Sibi Sankar wrote:
>> Add support to parse optional OPP table attached to the cpu node when
>> the OPP bandwidth values are populated. This allows for scaling of
>> DDR/L3 bandwidth levels with frequency change.
>>
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>
>> V5:
>> * Use dev_pm_opp_adjust_voltage instead [Viresh]
>> * Misc cleanup
>>
>> v4:
>> * Split fast switch disable into another patch [Lukasz]
>>
>> drivers/cpufreq/qcom-cpufreq-hw.c | 77
>> ++++++++++++++++++++++++++++++-
>> 1 file changed, 75 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
>> b/drivers/cpufreq/qcom-cpufreq-hw.c
>> index fc92a8842e252..fbd73d106a3ae 100644
>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> @@ -6,6 +6,7 @@
>> #include <linux/bitfield.h>
>> #include <linux/cpufreq.h>
>> #include <linux/init.h>
>> +#include <linux/interconnect.h>
>> #include <linux/kernel.h>
>> #include <linux/module.h>
>> #include <linux/of_address.h>
>> @@ -31,6 +32,52 @@
>> static unsigned long cpu_hw_rate, xo_rate;
>> static struct platform_device *global_pdev;
>>
>> +static int qcom_cpufreq_set_bw(struct cpufreq_policy *policy,
>> + unsigned long freq_khz)
>> +{
>> + unsigned long freq_hz = freq_khz * 1000;
>> + struct dev_pm_opp *opp;
>> + struct device *dev;
>> + int ret;
>> +
>> + dev = get_cpu_device(policy->cpu);
>> + if (!dev)
>> + return -ENODEV;
>> +
>> + opp = dev_pm_opp_find_freq_exact(dev, freq_hz, true);
>> + if (IS_ERR(opp))
>> + return PTR_ERR(opp);
>> +
>> + ret = dev_pm_opp_set_bw(dev, opp);
>> + dev_pm_opp_put(opp);
>> + return ret;
>> +}
>> +
>> +static int qcom_cpufreq_update_opp(struct device *cpu_dev,
>> + unsigned long freq_khz,
>> + unsigned long volt)
>> +{
>> + unsigned long freq_hz = freq_khz * 1000;
>> +
>> + if (dev_pm_opp_adjust_voltage(cpu_dev, freq_hz, volt, volt, volt))
>> + return dev_pm_opp_add(cpu_dev, freq_hz, volt);
>
> What's going on here ? Why add OPP here ?
We update the voltage if opp were
initially added as part of
dev_pm_opp_of_add_table. However
if the cpu node does not have an
opp table associated with it, we
do a opp_add_v1 instead.
>
>> +
>> + /* Enable the opp after voltage update */
>> + return dev_pm_opp_enable(cpu_dev, freq_hz);
>> +}
>> +
>> +/* Check for optional interconnect paths on CPU0 */
>> +static int qcom_cpufreq_find_icc_paths(struct device *dev)
>> +{
>> + struct device *cpu_dev;
>> +
>> + cpu_dev = get_cpu_device(0);
>> + if (!cpu_dev)
>> + return -EPROBE_DEFER;
>> +
>> + return dev_pm_opp_of_find_icc_paths(cpu_dev, NULL);
>> +}
>> +
>
> open code this into the probe routine.
sure
>
>> static int qcom_cpufreq_hw_target_index(struct cpufreq_policy
>> *policy,
>> unsigned int index)
>> {
>> @@ -39,6 +86,8 @@ static int qcom_cpufreq_hw_target_index(struct
>> cpufreq_policy *policy,
>>
>> writel_relaxed(index, perf_state_reg);
>>
>> + qcom_cpufreq_set_bw(policy, freq);
>> +
>> arch_set_freq_scale(policy->related_cpus, freq,
>> policy->cpuinfo.max_freq);
>> return 0;
>> @@ -88,12 +137,30 @@ static int qcom_cpufreq_hw_read_lut(struct device
>> *cpu_dev,
>> {
>> u32 data, src, lval, i, core_count, prev_freq = 0, freq;
>> u32 volt;
>> + u64 rate;
>> struct cpufreq_frequency_table *table;
>> + struct device_node *opp_table_np, *np;
>> + int ret;
>>
>> table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
>> if (!table)
>> return -ENOMEM;
>>
>> + ret = dev_pm_opp_of_add_table(cpu_dev);
>> + if (!ret) {
>> + /* Disable all opps and cross-validate against LUT */
>> + opp_table_np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
>> + for_each_available_child_of_node(opp_table_np, np) {
>> + ret = of_property_read_u64(np, "opp-hz", &rate);
>
> No way, please use dev_pm_opp_find_freq_*() here instead to grab OPPs
> one by one.
sure I'll use a dev_pm_opp_find_freq_ceil
loop to do the same :P
>
>> + if (!ret)
>> + dev_pm_opp_disable(cpu_dev, rate);
>> + }
>> + of_node_put(opp_table_np);
>> + } else if (ret != -ENODEV) {
>> + dev_err(cpu_dev, "Invalid OPP table in Device tree\n");
>> + return ret;
>> + }
>
> Rather put this in the if (ret) block and so the else part doesn't
> need extra indentation.
https://patchwork.kernel.org/patch/11573905/
I'll need to enable fast_switch
when the device does not have a
opp-table associated with it or
throw a error when an improper
table is specified. If a table
with bw values is specified, we
disable fast switch and enable
scaling.
>
>> +
>> for (i = 0; i < LUT_MAX_ENTRIES; i++) {
>> data = readl_relaxed(base + REG_FREQ_LUT +
>> i * LUT_ROW_SIZE);
>> @@ -112,7 +179,7 @@ static int qcom_cpufreq_hw_read_lut(struct device
>> *cpu_dev,
>>
>> if (freq != prev_freq && core_count != LUT_TURBO_IND) {
>> table[i].frequency = freq;
>> - dev_pm_opp_add(cpu_dev, freq * 1000, volt);
>> + qcom_cpufreq_update_opp(cpu_dev, freq, volt);
>> dev_dbg(cpu_dev, "index=%d freq=%d, core_count %d\n", i,
>> freq, core_count);
>> } else if (core_count == LUT_TURBO_IND) {
>> @@ -133,7 +200,8 @@ static int qcom_cpufreq_hw_read_lut(struct device
>> *cpu_dev,
>> if (prev->frequency == CPUFREQ_ENTRY_INVALID) {
>> prev->frequency = prev_freq;
>> prev->flags = CPUFREQ_BOOST_FREQ;
>> - dev_pm_opp_add(cpu_dev, prev_freq * 1000, volt);
>> + qcom_cpufreq_update_opp(cpu_dev, prev_freq,
>> + volt);
>> }
>>
>> break;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-05-29 11:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 20:21 [PATCH v5 0/5] DDR/L3 Scaling support on SDM845 and SC7180 SoCs Sibi Sankar
2020-05-27 20:21 ` [PATCH v5 1/5] cpufreq: blacklist SDM845 in cpufreq-dt-platdev Sibi Sankar
2020-05-27 20:21 ` [PATCH v5 2/5] cpufreq: blacklist SC7180 " Sibi Sankar
2020-05-27 20:21 ` [PATCH v5 3/5] OPP: Add and export helper to set bandwidth Sibi Sankar
2020-05-27 20:21 ` [PATCH v5 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change Sibi Sankar
2020-05-29 10:00 ` Viresh Kumar
2020-05-29 11:30 ` Sibi Sankar [this message]
2020-06-01 11:01 ` Viresh Kumar
2020-06-02 6:57 ` Sibi Sankar
2020-05-27 20:21 ` [PATCH v5 5/5] cpufreq: qcom: Disable fast switch when scaling DDR/L3 Sibi Sankar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a90bce2d52f7cdb726e8b799e3512fad@codeaurora.org \
--to=sibis@codeaurora.org \
--cc=agross@kernel.org \
--cc=amit.kucheria@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=dianders@chromium.org \
--cc=georgi.djakov@linaro.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mka@chromium.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=smasetty@codeaurora.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.