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

[Jagan Teki]

On Thu, Apr 4, 2019 at 3:31 PM Lukasz Majewski <lukma at denx.de> wrote:
>
> 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.

As per my experience the main the over-ahead to handle clocks in
U-Boot if we go with separate clock drivers is for Video and Ethernet
peripherals. these are key IP's which use more clocks from U-Boot
point-of-view, others can be handle pretty straight-forward unless if
they don't have too much tree chain.

On this series, the tree management is already supported ENET in
i.MX6, and Allwinner platforms.

As of now, I'm thinking I can handle reset of the clocks with similar way.

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

Please have a look, if possible check even the code size by adding USDHC clocks.

>
> >
> > 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)?

Allwinner clocks also has similar gates, muxs, and with other platform
stuff which has too much scope in Linux to use CCM.