On Thu, Aug 30, 2018 at 11:36:12AM -0700, Douglas Anderson wrote: > The geni_se_clk_freq_match() has some strange semantics. Specifically > it is defined with two modes: > 1. It can find a clock that's an exact multiple of the requested rate > 2. If can find a non-exact match but it can't handle multiples then nit: s/If/It/ > > ...but callers should always be able to handle a clock that is a > multiple of the requested clock so mode #2 doesn't really make sense. > Let's change the semantics so that the non-exact match can also accept > multiples and then change the code to handle that. > > The only caller of this code is the unlanded SPI driver [1] which > currently passes "exact = True", thus it should be safe to change the > semantics in this way. ...and, in fact, the SPI driver should likely > be modified to pass "exact = False" (with the new semantics) since > that will allow it to work with SPI devices that request a clock rate > that doesn't exactly match a rate we can make. > > [1] https://lkml.kernel.org/r/1535107336-2214-1-git-send-email-dkota@xxxxxxxxxxxxxx > > Fixes: eddac5af0654 ("soc: qcom: Add GENI based QUP Wrapper driver") > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > --- > > drivers/soc/qcom/qcom-geni-se.c | 37 ++++++++++++++++++++------------- > 1 file changed, 22 insertions(+), 15 deletions(-) > > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c > index 1b19b8428c4a..092b32a315c3 100644 > --- a/drivers/soc/qcom/qcom-geni-se.c > +++ b/drivers/soc/qcom/qcom-geni-se.c > @@ -544,16 +544,17 @@ EXPORT_SYMBOL(geni_se_clk_tbl_get); > * @se: Pointer to the concerned serial engine. > * @req_freq: Requested clock frequency. > * @index: Index of the resultant frequency in the table. > - * @res_freq: Resultant frequency which matches or is closer to the > - * requested frequency. > + * @res_freq: Resultant frequency of the source clock. > * @exact: Flag to indicate exact multiple requirement of the requested > * frequency. > * > - * This function is called by the protocol drivers to determine the matching > - * or exact multiple of the requested frequency, as provided by the serial > - * engine clock in order to meet the performance requirements. If there is > - * no matching or exact multiple of the requested frequency found, then it > - * selects the closest floor frequency, if exact flag is not set. > + * This function is called by the protocol drivers to determine the best match > + * of the requested frequency as provided by the serial engine clock in order > + * to meet the performance requirements. > + * > + * If we return success: > + * - if @exact is true then @res_freq / <an_integer> == @req_freq > + * - if @exact is false then @res_freq / <an_integer> <= @req_freq > * > * Return: 0 on success, standard Linux error codes on failure. > */ > @@ -564,6 +565,9 @@ int geni_se_clk_freq_match(struct geni_se *se, unsigned long req_freq, > unsigned long *tbl; > int num_clk_levels; > int i; > + unsigned long best_delta; > + unsigned long new_delta; > + unsigned int divider; > > num_clk_levels = geni_se_clk_tbl_get(se, &tbl); > if (num_clk_levels < 0) > @@ -572,18 +576,21 @@ int geni_se_clk_freq_match(struct geni_se *se, unsigned long req_freq, > if (num_clk_levels == 0) > return -EINVAL; > > - *res_freq = 0; > + best_delta = 0; > for (i = 0; i < num_clk_levels; i++) { > - if (!(tbl[i] % req_freq)) { > + divider = DIV_ROUND_UP(tbl[i], req_freq); > + new_delta = req_freq - tbl[i] / divider; > + if (!best_delta || new_delta < best_delta) { nit: if you assigned best_delta to ULONG_MAX above you could omit the check for !best_delta here, better to read IMO. > + /* We have a new best! */ > *index = i; > *res_freq = tbl[i]; > - return 0; > - } > > - if (!(*res_freq) || ((tbl[i] > *res_freq) && > - (tbl[i] < req_freq))) { > - *index = i; > - *res_freq = tbl[i]; > + /* If the new best is exact then we're done */ > + if (new_delta == 0) > + return 0; > + > + /* Record how close we got */ > + best_delta = new_delta; > } > } > Looks good to me assuming that the statement "callers should always be able to handle a clock that is a multiple of the requested clock" is correct. Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx>
