[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6473e34c.df0a0220.33a79.6c95@mx.google.com>
Date: Sun, 28 May 2023 14:37:26 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] clk: qcom: clk-rcg2: add support for rcg2 freq
multi ops
On Sat, May 27, 2023 at 06:11:16PM +0200, Konrad Dybcio wrote:
>
>
> On 27.04.2023 17:07, Christian Marangi wrote:
> > Some RCG frequency can be reached by multiple configuration.
> >
> > Add clk_rcg2_fm_ops ops to support these special RCG configurations.
> >
> > These alternative ops will select the frequency using a CEIL policy.
> >
> > When the correct frequency is found, the correct config is selected by
> > calculating the final rate (by checking the defined parent and values
> > in the config that is being checked) and deciding based on the one that
> > is less different than the requested one.
> >
> > These check are skipped if there is just on config for the requested
> > freq.
> >
> > qcom_find_freq_multi is added to search the freq with the new struct
> > freq_multi_tbl.
> > __clk_rcg2_select_conf is used to select the correct conf by simulating
> > the final clock.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> > ---
> > drivers/clk/qcom/clk-rcg.h | 1 +
> > drivers/clk/qcom/clk-rcg2.c | 152 ++++++++++++++++++++++++++++++++++++
> > drivers/clk/qcom/common.c | 18 +++++
> > drivers/clk/qcom/common.h | 2 +
> > 4 files changed, 173 insertions(+)
> >
> > diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
> > index dc85b46b0d79..f8ec989ed3d9 100644
> > --- a/drivers/clk/qcom/clk-rcg.h
> > +++ b/drivers/clk/qcom/clk-rcg.h
> > @@ -188,6 +188,7 @@ struct clk_rcg2_gfx3d {
> >
> > extern const struct clk_ops clk_rcg2_ops;
> > extern const struct clk_ops clk_rcg2_floor_ops;
> > +extern const struct clk_ops clk_rcg2_fm_ops;
> > extern const struct clk_ops clk_rcg2_mux_closest_ops;
> > extern const struct clk_ops clk_edp_pixel_ops;
> > extern const struct clk_ops clk_byte_ops;
> > diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> > index 76551534f10d..4f2fe012ef5f 100644
> > --- a/drivers/clk/qcom/clk-rcg2.c
> > +++ b/drivers/clk/qcom/clk-rcg2.c
> > @@ -266,6 +266,104 @@ static int _freq_tbl_determine_rate(struct clk_hw *hw, const struct freq_tbl *f,
> > return 0;
> > }
> >
> > +static const struct freq_conf *
> > +__clk_rcg2_select_conf(struct clk_hw *hw, const struct freq_multi_tbl *f,
> > + unsigned long req_rate)
> > +{
> > + unsigned long best_rate = 0, parent_rate, rate;
> > + const struct freq_conf *conf, *best_conf;
> > + struct clk_rcg2 *rcg = to_clk_rcg2(hw);
> > + struct clk_hw *p;
> > + int index, i;
> > +
> > + /* Exit early if only one config is defined */
> > + if (f->num_confs == 1)
> > + return f->confs;
> > +
> > + /* Search in each provided config the one that is near the wanted rate */
> > + for (i = 0, conf = f->confs; i < f->num_confs; i++, conf++) {
> > + index = qcom_find_src_index(hw, rcg->parent_map, conf->src);
> > + if (index < 0)
> > + continue;
> > +
> > + p = clk_hw_get_parent_by_index(hw, index);
> > + if (!p)
> > + continue;
> > +
> > + parent_rate = clk_hw_get_rate(p);
> > + rate = calc_rate(parent_rate, conf->n, conf->m, conf->n, conf->pre_div);
> > +
> > + if (rate == req_rate) {
> > + best_conf = conf;
> > + break;
> > + }
> > +
> > + if (abs(req_rate - rate) < abs(best_rate - rate)) {
> Shouldn't this be:
>
> if (abs(req_rate - rate) < abs(best_rate - req_rate)
>
> ?
>
> this way it'd say
>
> "if this iteration's rate is closer to the requested one than the
> best one we've found yet, it's better"
>
Hi, thanks for the review!
I wonder if even better would be something where we save the best rate
diff and just compare that.
rate_diff = abs(req_rate - rate)
if (rate_diff < best_rate_diff) {
best_rate_diff = rate_diff;
best_conf = conf;
}
And best_rate_diff init to ULONG_MAX?
> > + best_rate = rate;
> > + best_conf = conf;
> > + }
> > + }
> > +
> > + /*
> > + * Very unlikely.
> > + * Force the first conf if we can't find a correct config.
> > + */
> > + if (unlikely(i == f->num_confs))
> > + best_conf = f->confs;
> Is that a supported scenario or would it be a device driver / clock
> driver error?
>
It's to handle case for the 2 continue in the loop and arriving in a
situation where best_conf was never set?
Should we return a warning and an ERR_PTR? Idea was to provide a best
effort selection.
> > +
> > + return best_conf;
> > +}
> > +
> > +static int _freq_tbl_fm_determine_rate(struct clk_hw *hw, const struct freq_multi_tbl *f,
> > + struct clk_rate_request *req)
> > +{
> > + unsigned long clk_flags, rate = req->rate;
> > + const struct freq_conf *conf;
> > + struct clk_hw *p;
> > + struct clk_rcg2 *rcg = to_clk_rcg2(hw);
> swap lines 2, 3, 4 to 4, 2, 3 and you'll get a revers-Christmas-tree!
>
Thanks, didn't notice this. Will do in v5.
--
Ansuel
Powered by blists - more mailing lists