Hi Stefano, Fabio,
> Hi Lukasz,
>
> On 21/01/19 15:19, Lukasz Majewski wrote:
> > Hi Fabio,
> >
> >> Hi Lukasz,
> >>
> >> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski <lu...@denx.de>
> >> wrote:
> >>> +static ulong imx6q_clk_get_rate(struct clk *clk)
> >>> +{
> >>> + ulong rate = 0;
> >>> +
> >>> + debug("%s(#%lu)\n", __func__, clk->id);
> >>> +
> >>> + switch (clk->id) {
> >>> + case IMX6QDL_CLK_ECSPI1:
> >>> + case IMX6QDL_CLK_ECSPI2:
> >>> + case IMX6QDL_CLK_ECSPI3:
> >>> + case IMX6QDL_CLK_ECSPI4:
> >>> + return imx6_get_cspi_clk();
> >>> +
> >>> + case IMX6QDL_CLK_USDHC1:
> >>> + case IMX6QDL_CLK_USDHC2:
> >>> + case IMX6QDL_CLK_USDHC3:
> >>> + case IMX6QDL_CLK_USDHC4:
> >>> + return imx6_get_usdhc_clk(clk->id -
> >>> IMX6QDL_CLK_USDHC1);
> >>
> >> I don't think this scales well as this needs to grow for all other
> >> peripherals and for each port instance.
> >
>
> I am hiiting the same doubts as Fabio when I reviewed Peng's patches
> with clocks for i.MX8M. The current approach was introduced some years
> ago with i.MX5, but it does not fit well now and it does not scale.
>
>
> > The rationale regarding this approach:
> >
> > 1. Reuse the clock.c code for iMX6Q as much as possible.
> >
> > 2, This code is based on the clk-imx8q.c file - hence the question
> > why the Linux clock API was not ported for this new SoC?.
>
> Many reasons, first there was already a set of functions to get / set
> clocks coming from previos i.MX platforms, and this API was simply
> reused. And nobody was in charge to port the clock API.
>
> >
> >>
> >> If we are adding a clock driver for mx6, why don't we add it just
> >> like the kernel one?
> >
> > I can try to port the Linux code, but IMHO it would be feasible to
> > port only relevant (ECSPI, USDHC) parts of it (not all as I cannot
> > test it all properly).
>
> Fully agree. Further parts will be added on demand. Less is better. I
> disagree to add not tested code.
The work is in progress - I will add the same directory structure as
Linux's Common Clock Framework [CCF]. I shall finish in 2-3 days.
There are a few problems to tackle (when porting code from Linux):
1. As it is now - for IMX6Q we need a static table to store clock
pointers. It is around 1KiB of SRAM/SDRAM. This is _a_lot_ for SPL.
For u-boot proper this is not a huge problem.
2. The SPL shall use OF_PLATDATA, as we do need clock management mostly
in SPL. Moreover, I do think that SPL will be bigger (this is a _real_
problem, IMHO).
3. The CCF design needs to be fitted into U-Boot's Driver Model - this
is achievable. The most annoying problem is the lack of .get_rate()
method in the CCF's API.
4. The CCF driver for imx6q uses
clks: ccm@020c4000 {
}
Node as a "manager". In its probe we create other (proper) clocks
(hierarchy). Also, this driver is a starting point for getting access
to other clocks.
As said above - I will first post the CCF port very similar to
Barebox/Linux. Afterwards, we can decide if and how we optimise it.
>
> >
> >>
> >> Barebox imports the clock driver from the kernel and it is much
> >> cleaner:
> >> https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx6.c
> >
> > Yes, it has been trimmed (...a bit...) when compared to original
> > v4.20 :-) .
> >
> Best regards,
> Stefano
>
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
pgpTAU33mjyMR.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
