On 28.05.2023 14:37, Christian Marangi wrote:
> 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@xxxxxxxxx>
>>> ---
>>> 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?
Yeah that would be more readable!
>
>>> + 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.
Hm.. I'm not sure what's the expected behavior here.. Stephen?
Konrad
>
>>> +
>>> + 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.
>
