Re: [PATCH] tty: serial: qcom-geni-serial: minor fixes to get_clk_div_rate()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 6/7/2022 1:29 AM, Doug Anderson wrote:
Hi,

On Mon, Jun 6, 2022 at 11:19 AM Vijaya Krishna Nivarthi
<quic_vnivarth@xxxxxxxxxxx> wrote:
Hi,


On 6/4/2022 12:10 AM, Doug Anderson wrote:
Hi,

On Fri, Jun 3, 2022 at 10:43 AM Vijaya Krishna Nivarthi
<quic_vnivarth@xxxxxxxxxxx> wrote:
Ah, or I guess what you're saying is that the table historically
contained "rounded" rates but that clk_round_rate() isn't returning
nice round rates. OK, but if we truly want to support an inexact
match, you'd want to pick the rate that reduces the error, not just
pick the first one. In other words, something like this (untested):

freq = clk_round_rate(clk, mult);
diff = abs(((long)mult - freq) / div);
if (diff < best_diff) {
     best_diff = diff;
     ser_clk = freq;
     best_div = div;
}
I am not sure if its required that freq is a multiple of best_div now
that we don't have a multiple of desired_clk anyway.
How about just this (untested):

freq = clk_round_rate(clk, mult);
candidate_div = max(1, DIV_ROUND_CLOSEST(freq, desired_clk));
candidate_freq = freq / candidate_div;
diff = abs((long)desired_clk - candidate_freq);
if (diff < best_diff) {
    best_diff = diff;
    ser_clk = freq;
    best_div = candidate_div;
}
I am afraid this still doesn't guarantee that ser_clk is a multiple of
best_div
OK. ...I guess my question would be: does it matter for some reason?
"ser_clk" is just a local variable in this function. Who cares if it's
not a multiple of best_div? This is why we're keeping track of
"best_div" in the first place, so that later in the function instead
of:

*clk_div = ser_clk / desired_clk;
if (!(*clk_div))
   *clk_div = 1;

You just do:

*clk_div = best_div;

My only concern continues to be...

Given ser_clk is the final frequency that this function is going to return and best_div is going to be the clk_divider, is it ok if the divider cant divide the frequency exactly?

In other words, Can this function output combinations like (402,4)  (501,5) ?

If ok, then we can go ahead with this patch or even previous perhaps.


I tested it with a function simulates clk_round_rate.

static unsigned long clk_round_rate_test(struct clk *clk, unsigned long
in_freq)
{
      unsigned long root_freq[6] = {105, 204, 303, 402, 501, 602};
      int i;

      for (i = 0; i < 6; i++) {
          if (root_freq[i] >= in_freq)
              return root_freq[i];
      }
      return root_freq[6];
}

      {
          unsigned long ser_clk;
          unsigned long desired_clk;
          unsigned long freq;
          int div_round_closest;
          unsigned long div;
          unsigned long mult;
          unsigned long candidate_div, candidate_freq;

          unsigned long diff, best_diff, best_div;
          unsigned long one;

          desired_clk = 100;
          one = 1;
          best_diff = ULONG_MAX;
          pr_err("\ndesired_clk-%d\n", desired_clk);
          for (div = 1; div <= 10; div++) {
              mult = div * desired_clk;

              freq = clk_round_rate_test(clk, mult);
              div_round_closest = DIV_ROUND_CLOSEST(freq, desired_clk);
              candidate_div = max(one, (unsigned long)div_round_closest);
              candidate_freq = freq / candidate_div;
              diff = abs((long)desired_clk - candidate_freq);
              pr_err("div-%d, mult-%d, freq-%d, div_round_closest-%d,
candidate_div-%d, candidate_freq-%d, diff-%d\n",
                  div, mult, freq, div_round_closest, candidate_div,
candidate_freq, diff);
              if (diff < best_diff) {
                  pr_err("This is best so far\n");
                  best_diff = diff;
                  ser_clk = freq;
                  best_div = candidate_div;
              }
          }
          pr_err("\nbest_diff-%d, ser_clk-%d, best_div-%d\n",
              best_diff, ser_clk, best_div);
      }

And here is the output

[   17.835167] desired_clk-100
[   17.839567] div-1, mult-100, freq-105, div_round_closest-1,
candidate_div-1, candidate_freq-105, diff-5
[   17.849220] This is best so far
[   17.852458] div-2, mult-200, freq-204, div_round_closest-2,
candidate_div-2, candidate_freq-102, diff-2
[   17.862104] This is best so far
[   17.865345] div-3, mult-300, freq-303, div_round_closest-3,
candidate_div-3, candidate_freq-101, diff-1
[   17.874995] This is best so far
[   17.878237] div-4, mult-400, freq-402, div_round_closest-4,
candidate_div-4, candidate_freq-100, diff-0
[   17.887882] This is best so far
[   17.891118] div-5, mult-500, freq-501, div_round_closest-5,
candidate_div-5, candidate_freq-100, diff-0
[   17.900770] div-6, mult-600, freq-602, div_round_closest-6,
candidate_div-6, candidate_freq-100, diff-0
[   17.910415] div-7, mult-700, freq-602, div_round_closest-6,
candidate_div-6, candidate_freq-100, diff-0
[   17.920057] div-8, mult-800, freq-602, div_round_closest-6,
candidate_div-6, candidate_freq-100, diff-0
[   17.929703] div-9, mult-900, freq-602, div_round_closest-6,
candidate_div-6, candidate_freq-100, diff-0
[   17.939353] div-10, mult-1000, freq-602, div_round_closest-6,
candidate_div-6, candidate_freq-100, diff-0
[   17.949181]
[   17.949181] best_diff-0, ser_clk-402, best_div-4
That doesn't look like a terrible result. I guess nominally 602 is a
better approximation, but if we're accepting that we're not going to
have an exact rate anyway then maybe being off by that tiny amount
doesn't matter and we'd do better with the slow clock (maybe saves
power?)
Actually power saving was the anticipation behind returning first frequency in original patch, when we cant find exact frequency.

Please note that we go past cases when we have an divider that can
exactly divide the frequency(105/1, 204/2, 303/3) and end up with one
that doesn't.
Ah, good point. Luckily that's a 1-line fix, right?

Apologies, I could not figure out how.

Thank you.



-Doug



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux