On Thu, 4 Apr 2019 14:56:36 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski lukma@denx.de wrote:
On Tue, 2 Apr 2019 16:58:33 +0530 Jagan Teki jagan@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.
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@denx.de