linux-kernel - Re: [RFC PATCH] clk: fractional-divider: Correct max_{m,n} handed over to rational_best

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 15 Jul 2021 11:19:13 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Liu Ying <victor.liu@....com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Dong Aisheng <aisheng.dong@....com>,
        NXP Linux Team <linux-imx@....com>,
        Jacky Bai <ping.bai@....com>
Subject: Re: [RFC PATCH] clk: fractional-divider: Correct max_{m,n} handed
 over to rational_best_approximation()

+Cc: Mauro (below Q about sphinx and docs)

On Thu, Jul 15, 2021 at 11:14 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Thu, Jul 15, 2021 at 11:02 AM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:

...

> Now I realize one more item which is missed in the big picture.
> When we have overflowed the denominator (n) and shifted the values, we
> are expecting that the caller will check the rate and use another
> 2^scale (see (6) below) prescaler if needed to drop frequency to the
> needed values. The first few users of this were the drivers of the IPs
> which have an additional prescaler themselves. I dunno if there is any
> flag in CCF to show that the set frequency is 2^scale higher than
> asked.
>
> It means if
>
>         r_o / r_u >> N_lim (5)
>
> we will get m and n *saturated* without this snipped, while with it
> they will be much much better with a nuance that resulting frequency
> is shifted left by
>
>         scale = ln2(r_o/r_u) - nlim (6)
>
> scale bits.

I think I have at some point to introduce a documentation and explain
all this from the thread there.

Mauro, is sphinx capable of producing TeX formulas?

-- 
With Best Regards,
Andy Shevchenko