[PATCH v4 08/11] clk: sunxi-ng: nkm: Support finding closest rate

[Maxime Ripard]

On Sun, Jul 23, 2023 at 09:25:10AM +0200, Frank Oltmanns wrote:
> On 2023-07-17 at 16:14:58 +0200, Maxime Ripard <mripard at kernel.org> wrote:
> > [[PGP Signed Part:Undecided]]
> > On Mon, Jul 17, 2023 at 03:34:32PM +0200, Frank Oltmanns wrote:
> >> When finding the best rate for a NKM clock, consider rates that are
> >> higher than the requested rate, if the CCU_FEATURE_CLOSEST_RATE flag is
> >> set by using the helper function ccu_is_better_rate().
> >>
> >> Accommodate ccu_mux_helper_determine_rate to this change.
> >>
> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> >> ---
> >>  drivers/clk/sunxi-ng/ccu_mux.c |  2 +-
> >>  drivers/clk/sunxi-ng/ccu_nkm.c | 18 ++++++++----------
> >>  2 files changed, 9 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> >> index 1d557e323169..3ca695439620 100644
> >> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> >> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> >> @@ -139,7 +139,7 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
> >>  			goto out;
> >>  		}
> >>
> >> -		if ((req->rate - tmp_rate) < (req->rate - best_rate)) {
> >> +		if (ccu_is_better_rate(common, req->rate, tmp_rate, best_rate)) {
> >>  			best_rate = tmp_rate;
> >>  			best_parent_rate = parent_rate;
> >>  			best_parent = parent;
> >> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> >> index 793160bc2d47..5439b9351cd7 100644
> >> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> >> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> >> @@ -39,6 +39,7 @@ static unsigned long ccu_nkm_optimal_parent_rate(unsigned long rate, unsigned lo
> >>  }
> >>
> >>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct clk_hw *phw, struct _ccu_nkm *nkm,
> >> +						       struct ccu_common *common,
> >>  						       unsigned long *parent, unsigned long rate)
> >>  {
> >>  	unsigned long best_rate = 0, best_parent_rate = *parent, tmp_parent = *parent;
> >> @@ -54,10 +55,8 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct clk_hw *phw, struc
> >>  				tmp_parent = clk_hw_round_rate(phw, tmp_parent);
> >>
> >>  				tmp_rate = tmp_parent * _n * _k / _m;
> >> -				if (tmp_rate > rate)
> >> -					continue;
> >>
> >> -				if ((rate - tmp_rate) < (rate - best_rate)) {
> >> +				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate)) {
> >>  					best_rate = tmp_rate;
> >>  					best_parent_rate = tmp_parent;
> >>  					best_n = _n;
> >> @@ -78,7 +77,7 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct clk_hw *phw, struc
> >>  }
> >>
> >>  static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> >> -				       struct _ccu_nkm *nkm)
> >> +				       struct _ccu_nkm *nkm, struct ccu_common *common)
> >
> > Same comment than on patch 7, common should be first in those two functions.
> >
> 
> Ok, I wasn't sure what your expectation is for existing functions. For
> ccu_find_best_with_parent_adj the order is:
>   1. *phw
>   2. *nkm
>   3. *common
>   4. *parent
>   5. rate

Arguments are generally ordered by putting first what the function will
act upon, and then from generic to specific, and output last.

Which I guess would make the ideal one something like:
*common
*parent_hw
*parent
rate
nkm

> We don't have the parent hw in ccu_nkm_find_best. The order prior to
> this patch is:
>   1. parent
>   2. rate
>   3. *nkm
> 
> We need to add *common to that, so I could add it to the beginning as
> per your suggestion:
>   1. *common
>   2. parent
>   3. rate
>   4. *nkm

Those two make sense to me

> I could also pull *nkm to the beginning (similar to the parent_adj
> version):
>   4. *nkm
>   1. *common
>   2. parent
>   3. rate

nkm is an output, it needs to be last.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230724/8385f870/attachment.sig>