[linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: Maxime Ripard <hidden>
Date: 2017-01-19 16:21:51
Also in:
linux-clk, lkml
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):quoted
quoted
quoted
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/88be3d421e958579026135d8acec4b3983958738This one is fine.quoted
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170119/4ec64c25/attachment.sig>