[U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support

[Lukasz Majewski]

On Thu, 4 Apr 2019 14:56:36 +0530
Jagan Teki <jagan at amarulasolutions.com> wrote:

> On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski <lukma at denx.de> wrote:
> >
> > On Tue,  2 Apr 2019 16:58:33 +0530
> > Jagan Teki <jagan at amarulasolutions.com> wrote:
> >  
> > > This is revised version of previous i.MX6 clock management [1].
> > >
> > > The main difference between previous version is
> > > - Group the i.MX6 ccm clocks into gates and tree instead of
> > > handling the clocks in simple way using case statement.
> > > - use gate clocks for enable/disable management.
> > > - use tree clocks for get/set rate or parent traverse management.
> > > - parent clock handling via clock type.
> > > - traverse the parent clock using recursive functionlaity.
> > >
> > > The main motive behind this tree framework is to make the clock
> > > tree management simple and useful for U-Boot requirements instead
> > > of garbing Linux clock management code.
> > >
> > > We are trying to manage the Allwinner clocks with similar kind, so
> > > having this would really help i.MX6 as well.
> > >
> > > Added simple names for clock macros, but will update it in future
> > > version.
> > >
> > > I have skipped ENET clocks from previous series, will add it in
> > > future patches.
> > >
> > > Changes for v2:
> > > - changed framework patches.
> > > - add support for imx6qdl and imx6ul boards
> > > - add clock gates, tree.
> > >
> > > [1] https://patchwork.ozlabs.org/cover/950964/
> > >
> > > Any inputs?  
> >
> > Hmm.... It looks like we are doing some development in parallel.
> >
> > Please look into following commit [1]:
> > https://patchwork.ozlabs.org/patch/1034051/
> >
> > It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO in
> > the long term is a better approach.
> > The code is kept simple and resembles the code from Barebox.
> >
> > Please correct me if I'm wrong, but the code from your work is not
> > modeling muxes, gates and other components from Linux CCF.  
> 
> The U-Boot implementation of CLK would require as minimal and simple
> as possible due to requirement of U-Boot itself. Hope you agree this
> point? 

Now i.MX6 is using clock.c CLK implementation. If we decide to
replace it - we shall do it in a way, which would allow us to follow
Linux kernel. (the barebox implementation is a stripped CCF from
Linux, the same is in patch [1]).

> if yes having CCF stack code to handle all clock with
> respective separate drivers management is may not require as of now,
> IMHO.

I do have a gut feeling, that we will end up with the need to have the
CCF framework ported anyway. As for example imx7/8 can re-use muxes,
gates code.

However, those are only my "feelings" after a glimpse look - I will look
into your code more thoroughly and provide feedback.

> 
> This series is using recursive calls for handling parenting stuff to
> handle get or set rates, which is fine for handling clock tree
> management as far as U-Boot point-of-view. We have faced similar
> situation as I explained in commit message about Allwinner clocks [2]
> and we ended up going this way.

I'm not Allwinner expert - but if I may ask - how far away is this
implementation from mainline Linux kernel?

How difficult is it to port the new code (or update it)?

> 
> The patches where I get introduced clock tree is based on muxes, gates
> which were similar like Linux but I've managed to update according to
> U-Boot need.
> I have tried enet, enet_ref clocks as well and those are
> working out-of-box.
> 
> Feel free to comments, I have no intention to block anything. let's
> have a proper discussion.

Fabio, Stefano what do you think?

As we change the clock.c code, IMHO we shall do the new port properly.

> 
> [2] https://patchwork.ozlabs.org/patch/1019673/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190404/40973719/attachment.sig>