linux-kernel - Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL

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]

Message-ID: <20170119154538.4ge5vez36kvmase6@lukather>
Date:   Thu, 19 Jan 2017 16:45:38 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Ondřej Jirman <megous@...ous.com>
Cc:     dev@...ux-sunxi.org, Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jorik Jonker <jorik@...pendief.biz>,
        "open list:COMMON CLK FRAMEWORK" <linux-clk@...r.kernel.org>,
        "moderated list:ARM/Allwinner sunXi SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

On Wed, Jan 18, 2017 at 06:48:35PM +0100, Ondřej Jirman wrote:
> Dne 18.1.2017 v 17:56 Maxime Ripard napsal(a):
> >>> What's your current plan to fix that? I guess the easiest (and most
> >>> likely to be reusable) would be to allow for clock tables, instead of
> >>> using the generic approach. We might have some other clocks (like
> >>> audio or video) that would need such a precise tuning in the future
> >>> too.
> >>
> >> My proposed solution is this for M factor (H3 specific solution):
> >>
> >> https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738
> > 
> > This one is fine.
> > 
> >> and this for P factor:
> >>
> >> https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a
> >>
> >> Perhaps it should be configurable if the P limitation is not universal
> >> for all NKMP clocks. But I haven't read all the datasheets.
> > 
> > And this is exactly what I wanted to avoid, for the reason you're
> > giving :)
> > 
> > This is some generic code, and yet you're putting a clock and SoC
> > specific limit in there. You have two ways to deal with that. Either
> > come up with some generic throttling mecanism to force a particular
> > value above or below a given threshold, but that might be tedious to
> > do, and require some significant rework.
> > 
> > Or you can use a table, which is generic and should be relatively
> > easy. I really think this is the most straightforward solution, and
> > even more so since we just want to support a limited number of
> > frequencies in this case.
> 
> So I would add a pointer to a table to struct ccu_nkmp and define the
> table itself in ccu-sun8i-h3.c?
> 
> If struct ccu_nkmp would have non-NULL pointer to a table, it would be
> used instead of the math in ccu_nkmp.c.
> 
> Sounds ok?

Yep, sounds perfect!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)