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

Adam Ford aford173 at gmail.com
Tue Dec 1 08:22:48 EST 2020


On Mon, Nov 30, 2020 at 8:44 PM Andy Duan <fugang.duan at nxp.com> wrote:
>
> 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().

How do I do this?  I am selecting the clock parent in the device tree,
because I need an 80MHz clock in order to run the UART at 4Mbps.  Is
there some mechanism for the device tree to keep it disabled during
the clock scan and of_cl_init?  It seems to me like clock parent
selection should happen in the driver before the initialization of the
clock.

> 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



More information about the linux-arm-kernel mailing list