On Thu, 4 Apr 2019 14:56:36 +0530 Jagan Teki <ja...@amarulasolutions.com> wrote:
> On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski <lu...@denx.de> wrote: > > > > On Tue, 2 Apr 2019 16:58:33 +0530 > > Jagan Teki <ja...@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: lu...@denx.de
pgpkIZ6MgUre6.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
