linux-kernel - Re: [RFC PATCH] clk: rockchip: rk3399: support pll setting automatically

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 30 Aug 2016 09:30:55 +0800
From:   Elaine Zhang <zhangqing@...k-chips.com>
To:     Heiko Stübner <heiko@...ech.de>,
        Doug Anderson <dianders@...omium.org>
CC:     Xing Zheng <zhengxing@...k-chips.com>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Brian Norris <briannorris@...omium.org>,
        Tao Huang <huangtao@...k-chips.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] clk: rockchip: rk3399: support pll setting automatically



On 08/30/2016 01:54 AM, Heiko Stübner wrote:
> Am Montag, 29. August 2016, 10:35:44 schrieb Doug Anderson:
>> Hi,
>>
>> On Sun, Aug 28, 2016 at 8:21 AM, Heiko Stübner <heiko@...ech.de> wrote:
>>> Hi Xing, Elaine,
>>>
>>> Am Dienstag, 2. August 2016, 21:34:12 schrieb Xing Zheng:
>>>> From: Elaine Zhang <zhangqing@...k-chips.com>
>>>>
>>>> The goal is that we can configure the most suitable pll params
>>>> automatically.
>>>>
>>>> If setting freq is not supported in rockchip_pll_rate_table
>>>> rk3399_pll_rates[], we can set pll params automatically.
>>>>
>>>> Signed-off-by: Elaine Zhang <zhangqing@...k-chips.com>
>>>> Signed-off-by: Xing Zheng <zhengxing@...k-chips.com>
>>>
>>> first off, I really like that idea of calculating the generic pll
>>> frequencies instead of duplicating these entries in every soc clock
>>> driver.
>>
>> I probably won't have time to look at this any time soon, but when I
>> saw this patch fly by I was a little hesitant because:
>>
>> * Not all PLL settings produce the same jitter.  On rk3288 I spent
>> loads of time searching for PLL settings that would be low jitter
>> enough to make a pixel clock that was happy with lots of different TVs
>> / monitors.  It's true that there were certain heuristics that could
>> be followed but certainly my predictions didn't always match what
>> happened.
>>
>> * Depending on what's using the PLL, you might want very different
>> settings.  One can optimize for lock time, power usage, jitter,
>> accuracy, etc.  For instance for a CPU clock that you change a lot you
>> probably don't care about hitting an exact frequency and you probably
>> don't care overly much about jitter, but you want low lock times.  For
>> HDMI you don't care about lock times and and probably don't care about
>> power usage, but you care about meeting an exact clock and really
>> really care about jitter.
>>
>> * I know that in the past the way I found to make some of the best
>> rates for HDMI was to have the PLL make a rate that was several times
>> what I wanted and then activate a divider later in the clock tree.
>> That gave me the best jitter / clock accuracy.  I have no idea how to
>> do that automatically, but in the past I relied on the PLL only having
>> a fixed set of rates it could make so it would fail to make the lower
>> clock rate (higher jitter) and eventually end up with the better one.
>>
>>
>> Anyway, I don't know how to solve all of the above, but I just wanted
>> to bring it up as a concern.
>
> after talking with Doug on irc, I realized that this really can become a
> problem, as right now we have a list with known-good rates, can adjust those
> as needed and have the clock framework select the best for a certain target
> rate.
>
> But with the automatic calculation it would open up nearly unlimited different
> rates with possible negative effects and no way to eliminate or even test most
> of them.
>
> So it may very well be best to stay with static rates, in a component as core
> as the PLLs are?

I also thought of this question, and really cant't solve all of the above.
According to before product experience,if the clk test jitter is not 
accept,we can add this freq to the static freq table.
And others use the pll setting automatically.

>
>
> Heiko
>
>
>