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

[Jagan Teki]

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? if yes having CCF stack code to handle all clock with
respective separate drivers management is may not require as of now,
IMHO.

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.

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.

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