Hi Chen-Yu,

On Wed, Mar 22, 2017 at 02:50:31PM +0800, Chen-Yu Tsai wrote:

On Wed, Feb 15, 2017 at 5:49 PM, Maxime Ripard
[off-list ref] wrote:

quoted

On Tue, Feb 14, 2017 at 06:26:39PM +0800, Chen-Yu Tsai wrote:

quoted

On Tue, Feb 14, 2017 at 5:58 PM, Maxime Ripard
[off-list ref] wrote:

quoted

On Tue, Feb 14, 2017 at 11:35:25AM +0800, Chen-Yu Tsai wrote:

quoted

+/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */

Is that even working?

Looking at the nkmp clock code, only .recalc_rate will work properly though.
Maybe I could fix up the code so it handles zero width factors.

quoted

I'm not quite sure we want to do that. We might model it as a NP clock
with a variable prediv?

There's no NP clock type yet. And a problem with a variable prediv is that
it doesn't participate in factor calculation. It's effectively fixed.

I did this for the A80 as well though. Fixing up the NKMP clock might be
easier.

Then maybe we just need a NMP clock type then. What I'm really afraid
of is that we'll just end up in a clk-factors situation that was
simply impossible to maintain without breaking anything, hence why we
had different clock types then.

Upon further review, I think it will work. I did notice a discrepancy
between .set_rate and .round_rate though. Will send fixes later.

About the old clk-factors situation, I'm not exactly sure what part
you're referring to.

We need to be able to support old DTs, which will still use the old
clock code. Whatever solution we come up with need to take that into
account.

To me it seems the "factors" bits are mostly the same. Differences
are mostly with parent-specific pre-dividers, clock post-dividers,
and non-standard factors. The first is nicely handled by the new mux
wrapper, the second is currently only used with NK types, and the
last is currently only supported by single factor divider or
multiplier clocks with tables.

Non-standard factors are probably the trickiest one, but given we will
support full factor tables for some of the tricky CPU PLLs, this is
probably solved, even if not implemented yet.

I'll start with the NP style clocks, which only use P when the output
is under a certain frequency.

Do we need to use a P factor? I mean, we can just create a custom
clock for that, I'd realy don't want to cripple the generic code for a
completely non-generic problem.

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/20170326/c2e28624/attachment-0001.sig>