Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

[Maxime Ripard]

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
> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, Feb 14, 2017 at 06:26:39PM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Feb 14, 2017 at 5:58 PM, Maxime Ripard
> >> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
> >> > On Tue, Feb 14, 2017 at 11:35:25AM +0800, Chen-Yu Tsai wrote:
> >> >> +/* 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.
> >>
> >> > 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

Attachment: signature.asc
Description: PGP signature