[EXT] Re: i.MX8MM Clock errors and caam failure on 5.10-rc4

[Andy Duan]

From: Adam Ford <aford173 at gmail.com> Sent: Monday, November 30, 2020 7:29 PM
> On Mon, Nov 30, 2020 at 2:32 AM Aisheng Dong <aisheng.dong at nxp.com>
> wrote:
> >
> > Hi Fugang & Horia,
> >
> > > From: Adam Ford <aford173 at gmail.com>
> > > Sent: Sunday, November 22, 2020 6:43 AM
> > >
> > > I have a board which uses Bluetooth on UART1 similar to the 8mm-evk.
> > > The serial port for the BT needs to run at 80MHz because I have the
> > > baud rate of the serial part set to 4M.
> > >
> > > I thought I'd give the 5.10-RC's a try.  I found some issues that
> > > concern me, but before I go back to bisect, I thought I'd ask if
> > > people are aware of it and/or have ideas.  The BT is failing to
> > > operate as is the caam engine, and it seems to be related to some clocking
> issues.
> > >
> > >      Failed to get clock for /timer at 306a0000
> > >      Failed to initialize '/timer at 306a0000': -22
> > >      clk: failed to reparent uart1 to sys_pll1_80m: -16
> > >      clk: failed to reparent uart3 to sys_pll1_80m: -16
> > >      caam 30900000.caam: Failed to get clk 'ipg': -2
> > >      caam 30900000.caam: Failed to request all necessary clocks
> > >      caam: probe of 30900000.caam failed with error -2
> > >
> 
> I upgraded my version of ATF to the imx_5.4.47_2.2.0 release and the latest
> upstream U-Boot.  With those updates, the timer and caam errors went away,
> however I am still seeing the following:
> 
>   clk: failed to reparent uart1 to sys_pll1_80m: -16
>   clk: failed to reparent uart3 to sys_pll1_80m: -16
> 
> Is there something else missing?

Adam, below patch prevent enabled leaf clock to be parented.
So you should keep uart clock is disabled during clock scan and init in of_clk_init().
You can refer to the fixes at imx/clk.c:
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0

commit 9461f7b33d11cbbf5ce79c3c03d0da9d42dfce92
Author: Jerome Brunet <jbrunet at baylibre.com>
Date:   Tue Jun 19 15:40:51 2018 +0200

    clk: fix CLK_SET_RATE_GATE with clock rate protection

    CLK_SET_RATE_GATE should prevent any operation which may result in a rate
    change or glitch while the clock is prepared/enabled.

    IOW, the following sequence is not allowed anymore with CLK_SET_RATE_GATE:
    * clk_get()
    * clk_prepare_enable()
    * clk_get_rate()
    * clk_set_rate()

    At the moment this is enforced on the leaf clock of the operation, not
    along the tree. This problematic because, if a PLL has the CLK_RATE_GATE,
    it won't be enforced if the clk_set_rate() is called on its child clocks.

    Using clock rate protection, we can now enforce CLK_SET_RATE_GATE along the
    clock tree

    Acked-by: Linus Walleij <linus.walleij at linaro.org>
    Tested-by: Quentin Schulz <quentin.schulz at free-electrons.com>
    Tested-by: Maxime Ripard <maxime.ripard at free-electrons.com>
    Signed-off-by: Jerome Brunet <jbrunet at baylibre.com>
    Signed-off-by: Michael Turquette <mturquette at baylibre.com>
    Link: lkml.kernel.org/r/20180619134051.16726-3-jbrunet at baylibre.com

> 
> > > I jumped ahead to linux-next to see if there were any upstream fixes
> > > implemented but it throws the same errors.
> > >
> > > If anyone has any ideas, I'd like to try them.  If not, I'll spend
> > > some time bisecting.
> >
> > Are you aware of this issue?
> > Any suggestions?
> >
> > Regards
> > Aisheng
> >
> > >
> > > adam