From: Matthias Kaehlcke <mka@chromium.org>
To: Sibi Sankar <sibis@codeaurora.org>
Cc: viresh.kumar@linaro.org, sboyd@kernel.org,
georgi.djakov@linaro.org, saravanak@google.com, 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
Subject: Re: [PATCH v6 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change
Date: Mon, 15 Jun 2020 10:25:53 -0700 [thread overview]
Message-ID: <20200615172553.GU4525@google.com> (raw)
In-Reply-To: <20200605213332.609-5-sibis@codeaurora.org>
Hi Sibi,
On Sat, Jun 06, 2020 at 03:03:31AM +0530, 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>
> ---
>
> v6:
> * Add global flag to distinguish between voltage update and opp add.
> Use the same flag before trying to scale ddr/l3 bw [Viresh]
> * Use dev_pm_opp_find_freq_ceil to grab all opps [Viresh]
> * Move dev_pm_opp_of_find_icc_paths into probe [Viresh]
>
> 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 | 82 ++++++++++++++++++++++++++++++-
> 1 file changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index fc92a8842e252..8fa6ab6e0e4b6 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>
> @@ -30,6 +31,48 @@
>
> static unsigned long cpu_hw_rate, xo_rate;
> static struct platform_device *global_pdev;
> +static bool icc_scaling_enabled;
It seem you rely on 'icc_scaling_enabled' to be initialized to 'false'.
This works during the first initialization, but not if the 'device' is
unbound/rebound. In theory things shouldn't be different in a succesive
initialization, however for robustness the variable should be explicitly
set to 'false' somewhere in the code path (_probe(), _read_lut(), ...).
> +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;
> + int ret;
> +
> + /* Skip voltage update if the opp table is not available */
> + if (!icc_scaling_enabled)
> + return dev_pm_opp_add(cpu_dev, freq_hz, volt);
> +
> + ret = dev_pm_opp_adjust_voltage(cpu_dev, freq_hz, volt, volt, volt);
> + if (ret) {
> + dev_err(cpu_dev, "Voltage update failed freq=%ld\n", freq_khz);
> + return ret;
> + }
> +
> + return dev_pm_opp_enable(cpu_dev, freq_hz);
> +}
>
> static int qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
> unsigned int index)
> @@ -39,6 +82,9 @@ static int qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
>
> writel_relaxed(index, perf_state_reg);
>
> + if (icc_scaling_enabled)
> + qcom_cpufreq_set_bw(policy, freq);
> +
> arch_set_freq_scale(policy->related_cpus, freq,
> policy->cpuinfo.max_freq);
> return 0;
> @@ -89,11 +135,31 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
> u32 data, src, lval, i, core_count, prev_freq = 0, freq;
> u32 volt;
> struct cpufreq_frequency_table *table;
> + struct dev_pm_opp *opp;
> + unsigned long rate;
> + 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 */
nit: IIUC the cross-validation doesn't happen in this branch, so the
comment is a bit misleading. Maybe change it to "Disable all opps to
cross-validate against the LUT {below,later}".
> + icc_scaling_enabled = true;
> + for (rate = 0; ; rate++) {
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate);
> + if (IS_ERR(opp))
> + break;
> +
> + dev_pm_opp_put(opp);
> + dev_pm_opp_disable(cpu_dev, rate);
> + }
> + } else if (ret != -ENODEV) {
> + dev_err(cpu_dev, "Invalid opp table in device tree\n");
> + return ret;
> + }
> +
> for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> data = readl_relaxed(base + REG_FREQ_LUT +
> i * LUT_ROW_SIZE);
> @@ -112,7 +178,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);
This is the cross-validation mentioned above, right? Shouldn't it include
a check of the return value?
> 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 +199,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);
ditto
nit: with the updated max line length it isn't necessary anymore to break
this into multiple lines (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?h=v5.8-rc1#n54),
though the coding style still has the old limit.
next prev parent reply other threads:[~2020-06-15 17:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 21:33 [PATCH v6 0/5] DDR/L3 Scaling support on SDM845 and SC7180 SoCs Sibi Sankar
2020-06-05 21:33 ` [PATCH v6 1/5] cpufreq: blacklist SDM845 in cpufreq-dt-platdev Sibi Sankar
2020-06-05 21:33 ` [PATCH v6 2/5] cpufreq: blacklist SC7180 " Sibi Sankar
2020-06-05 21:33 ` [PATCH v6 3/5] OPP: Add and export helper to set bandwidth Sibi Sankar
2020-06-15 16:58 ` Matthias Kaehlcke
2020-06-05 21:33 ` [PATCH v6 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change Sibi Sankar
2020-06-15 17:25 ` Matthias Kaehlcke [this message]
2020-06-16 21:05 ` Sibi Sankar
2020-06-16 22:11 ` Matthias Kaehlcke
2020-06-17 4:52 ` Viresh Kumar
2020-06-17 16:43 ` Sibi Sankar
2020-06-18 17:05 ` Matthias Kaehlcke
2020-06-05 21:33 ` [PATCH v6 5/5] cpufreq: qcom: Disable fast switch when scaling DDR/L3 Sibi Sankar
2020-06-15 17:32 ` Matthias Kaehlcke
2020-06-08 10:27 ` [PATCH v6 0/5] DDR/L3 Scaling support on SDM845 and SC7180 SoCs Viresh Kumar
-- strict thread matches above, loose matches on Subject: below --
2020-06-22 8:16 Sibi Sankar
2020-06-22 8:16 ` [PATCH v6 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change Sibi Sankar
2020-06-22 15:58 ` Matthias Kaehlcke
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=20200615172553.GU4525@google.com \
--to=mka@chromium.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@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=sibis@codeaurora.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.