From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Georgi Djakov <djakov@kernel.org>, Leo Yan <leo.yan@linaro.org>,
Evan Green <evgreen@chromium.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v3 18/23] interconnect: qcom: icc-rpm: Control bus rpmcc from icc
Date: Tue, 13 Jun 2023 13:22:09 +0200 [thread overview]
Message-ID: <88ce120e-dc2e-a07f-3c9f-53073e51a1af@linaro.org> (raw)
In-Reply-To: <ZIeGGn7emge6Xkb0@gerhold.net>
On 12.06.2023 22:54, Stephan Gerhold wrote:
> On Mon, Jun 12, 2023 at 08:24:35PM +0200, Konrad Dybcio wrote:
>> The sole purpose of bus clocks that were previously registered with
>> rpmcc was to convey the aggregated bandwidth to RPM. There's no good
>> reason to keep them outside the interconnect framework, as it only
>> adds to the plentiful complexity.
>>
>> Add the required code to handle these clocks from within SMD RPM ICC.
>>
>> RPM-owned bus clocks are no longer considered a thing, but sadly we
>> have to allow for the existence of HLOS-owned bus clocks, as some
>> (mostly older) SoCs (ab)use these for bus scaling (e.g. MSM8998 and
>> &mmcc AHB_CLK_SRC).
>>
>> This in turn is trivially solved with a single *clk, which is filled
>> and used iff qp.bus_clk_desc is absent and we have a "bus" clock-names
>> entry in the DT node.
>>
>> This change should(tm) be fully compatible with all sorts of old
>> Device Trees as far as the interconnect functionality goes (modulo
>> abusing bus clock handles, but that's a mistake in and of itself).
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>
> Would be nice to add a comment here already that you're breaking
> compatbility with the qcom,icc.h. It's a bit hidden otherwise.
Right, wouldn't hurt..
>
>> ---
>> drivers/interconnect/qcom/icc-rpm.c | 114 ++++++++++++++++++++----------------
>> drivers/interconnect/qcom/icc-rpm.h | 13 ++--
>> drivers/interconnect/qcom/msm8996.c | 1 -
>> drivers/interconnect/qcom/sdm660.c | 1 -
>> 4 files changed, 66 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
>> index b8ecf9538ab9..5ffcf5ca8914 100644
>> --- a/drivers/interconnect/qcom/icc-rpm.c
>> +++ b/drivers/interconnect/qcom/icc-rpm.c
>> @@ -49,7 +49,7 @@
>> #define NOC_QOS_MODE_FIXED_VAL 0x0
>> #define NOC_QOS_MODE_BYPASS_VAL 0x2
>>
>> -#define ICC_BUS_CLK_MIN_RATE 19200000ULL
>> +#define ICC_BUS_CLK_MIN_RATE 19200ULL /* kHz */
>>
>> static int qcom_icc_set_qnoc_qos(struct icc_node *src)
>> {
>> @@ -338,11 +338,10 @@ static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
>> struct qcom_icc_node *src_qn = NULL, *dst_qn = NULL;
>> struct icc_provider *provider;
>> u64 sum_bw;
>> - u64 rate;
>> + u64 active_rate, sleep_rate;
>> u64 agg_avg[QCOM_ICC_NUM_BUCKETS], agg_peak[QCOM_ICC_NUM_BUCKETS];
>> u64 max_agg_avg;
>> - int ret, i;
>> - int bucket;
>> + int ret;
>>
>> src_qn = src->data;
>> if (dst)
>> @@ -364,49 +363,54 @@ static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
>> return ret;
>> }
>>
>> - for (i = 0; i < qp->num_bus_clks; i++) {
>> - /*
>> - * Use WAKE bucket for active clock, otherwise, use SLEEP bucket
>> - * for other clocks. If a platform doesn't set interconnect
>> - * path tags, by default use sleep bucket for all clocks.
>> - *
>> - * Note, AMC bucket is not supported yet.
>> - */
>> - if (!strcmp(qp->bus_clks[i].id, "bus_a"))
>> - bucket = QCOM_ICC_BUCKET_WAKE;
>> - else
>> - bucket = QCOM_ICC_BUCKET_SLEEP;
>> -
>> - rate = icc_units_to_bps(max(agg_avg[bucket], agg_peak[bucket]));
>> - do_div(rate, src_qn->buswidth);
>> - rate = min_t(u64, rate, LONG_MAX);
>> -
>> - /*
>> - * Downstream checks whether the requested rate is zero, but it makes little sense
>> - * to vote for a value that's below the lower threshold, so let's not do so.
>> - */
>> - if (bucket == QCOM_ICC_BUCKET_WAKE && qp->keep_alive)
>> - rate = max(ICC_BUS_CLK_MIN_RATE, rate);
>> -
>> - if (qp->bus_clk_rate[i] == rate)
>> - continue;
>> -
>> - ret = clk_set_rate(qp->bus_clks[i].clk, rate);
>> - if (ret) {
>> - pr_err("%s clk_set_rate error: %d\n",
>> - qp->bus_clks[i].id, ret);
>> + /* Some providers don't have a bus clock to scale */
>> + if (!qp->bus_clk_desc && !qp->bus_clk)
>> + return 0;
>> +
>> + /* Intentionally keep the rates in kHz as that's what RPM accepts */
>> + active_rate = max(agg_avg[QCOM_SMD_RPM_ACTIVE_STATE],
>> + agg_peak[QCOM_SMD_RPM_ACTIVE_STATE]);
>> + do_div(active_rate, src_qn->buswidth);
>> +
>> + sleep_rate = max(agg_avg[QCOM_SMD_RPM_SLEEP_STATE],
>> + agg_peak[QCOM_SMD_RPM_SLEEP_STATE]);
>> + do_div(sleep_rate, src_qn->buswidth);
>> +
>> + /*
>> + * Downstream checks whether the requested rate is zero, but it makes little sense
>> + * to vote for a value that's below the lower threshold, so let's not do so.
>> + */
>> + if (qp->keep_alive)
>> + active_rate = max(ICC_BUS_CLK_MIN_RATE, active_rate);
>> +
>> + /* Some providers have a non-RPM-owned bus clock - convert kHz->Hz for the CCF */
>> + if (qp->bus_clk) {
>> + active_rate = max_t(u64, active_rate, sleep_rate);
>> + /* ARM32 caps clk_set_rate arg to u32.. Nothing we can do about that! */
>> + active_rate = min_t(u64, 1000ULL * active_rate, ULONG_MAX);
>> + return clk_set_rate(qp->bus_clk, active_rate);
>> + }
>> +
>> + /* RPM only accepts <=INT_MAX rates */
>> + active_rate = min_t(u32, active_rate, INT_MAX);
>> + sleep_rate = min_t(u32, sleep_rate, INT_MAX);
>> +
>> + if ((active_rate != qp->bus_clk_rate[QCOM_SMD_RPM_ACTIVE_STATE]) ||
>> + (sleep_rate != qp->bus_clk_rate[QCOM_SMD_RPM_SLEEP_STATE])) {
>> + ret = qcom_icc_rpm_set_bus_rate(qp->bus_clk_desc,
>> + active_rate,
>> + sleep_rate);
>> + if (ret)
>> return ret;
>
> Hm, do we have to set both rates together in all cases? If cpufreq is
> quickly changing frequencies (and therefore active-only ICC bandwidths)
> it should be sufficient to make one call into RPM and leave the sleep
> rate as-is. Especially because you already cache the two rates
> separately.
>
> AFAICT downstream updates the contexts completely separately, so I don't
> think it updates both rates at once either. And actually even the old
> code before this patch didn't do that :D
Right, I can trivially solve that by making qcom_icc_rpm_set_bus_rate
accept an is_active parameter..
Konrad
>
> Thanks,
> Stephan
next prev parent reply other threads:[~2023-06-13 11:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 18:24 [PATCH v3 00/23] Restructure RPM SMD ICC Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 01/23] dt-bindings: interconnect: Add Qcom RPM ICC bindings Konrad Dybcio
2023-06-13 11:11 ` Stephan Gerhold
2023-06-13 11:20 ` Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 02/23] soc: qcom: smd-rpm: Add QCOM_SMD_RPM_STATE_NUM Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 03/23] soc: qcom: smd-rpm: Use tabs for defines Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 04/23] clk: qcom: smd-rpm: Move some RPM resources to the common header Konrad Dybcio
2023-06-12 19:36 ` Stephen Boyd
2023-06-12 18:24 ` [PATCH v3 05/23] soc: qcom: smd-rpm: Move icc_smd_rpm registration to clk-smd-rpm Konrad Dybcio
2023-06-12 19:41 ` Stephen Boyd
2023-06-12 18:24 ` [PATCH v3 06/23] interconnect: qcom: icc-rpm: Introduce keep_alive Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 07/23] interconnect: qcom: icc-rpm: Allow negative QoS offset Konrad Dybcio
2023-06-12 20:27 ` Stephan Gerhold
2023-06-13 12:12 ` Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 08/23] interconnect: qcom: Fold smd-rpm.h into icc-rpm.h Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 09/23] interconnect: qcom: smd-rpm: Add rpmcc handling skeleton code Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 10/23] interconnect: qcom: Add missing headers in icc-rpm.h Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 11/23] interconnect: qcom: Define RPM bus clocks Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 12/23] interconnect: qcom: sdm660: Hook up RPM bus clk definitions Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 13/23] interconnect: qcom: msm8996: " Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 14/23] interconnect: qcom: qcs404: " Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 15/23] interconnect: qcom: msm8939: " Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 16/23] interconnect: qcom: msm8916: " Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 17/23] interconnect: qcom: qcm2290: " Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 18/23] interconnect: qcom: icc-rpm: Control bus rpmcc from icc Konrad Dybcio
2023-06-12 20:54 ` Stephan Gerhold
2023-06-13 11:22 ` Konrad Dybcio [this message]
2023-06-12 18:24 ` [PATCH v3 19/23] clk: qcom: smd-rpm: Separate out interconnect bus clocks Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 20/23] interconnect: qcom: icc-rpm: Fix bucket number Konrad Dybcio
2023-06-12 20:57 ` Stephan Gerhold
2023-06-13 9:06 ` Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 21/23] interconnect: qcom: icc-rpm: Set bandwidth on both contexts Konrad Dybcio
2023-06-12 21:00 ` Stephan Gerhold
2023-06-12 18:24 ` [PATCH v3 22/23] interconnect: qcom: icc-rpm: Set correct bandwidth through RPM bw req Konrad Dybcio
2023-06-12 18:24 ` [PATCH v3 23/23] interconnect: qcom: icc-rpm: Fix bandwidth calculations Konrad Dybcio
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=88ce120e-dc2e-a07f-3c9f-53073e51a1af@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=evgreen@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=leo.yan@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=stephan@gerhold.net \
/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 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).