From: Stephan Gerhold <stephan@gerhold.net>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
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: Mon, 12 Jun 2023 22:54:50 +0200 [thread overview]
Message-ID: <ZIeGGn7emge6Xkb0@gerhold.net> (raw)
In-Reply-To: <20230526-topic-smd_icc-v3-18-5fb7d39b874f@linaro.org>
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.
> ---
> 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
Thanks,
Stephan
next prev parent reply other threads:[~2023-06-12 21:01 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 [this message]
2023-06-13 11:22 ` Konrad Dybcio
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=ZIeGGn7emge6Xkb0@gerhold.net \
--to=stephan@gerhold.net \
--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=konrad.dybcio@linaro.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 \
/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.